Artigo
08/17/2015

Este artigo foi traduzido por máquina.

CLR DE DENTRO PARA FORA

Explorando o modelo de segurança do .NET Framework 4

Andrew Dai

O .NET Framework 4 introduz muitas atualizações ao modelo de segurança do .NET que tornam muito mais fácil hospedar, proteger e fornecer serviços a código parcialmente confiável. Nós já overhauled o sistema de diretiva de CAS (segurança de acesso a código) complicado, que foi poderosa, mas difícil de usar e ainda mais difícil obter direito. Você também Aperfeiçoamos após o modelo Transparência da segurança, trazendo muito dos aperfeiçoamentos do Silverlight (qual falei sobre outubro último: MSDN.Microsoft.com/magazine/cc765416.aspx) na imposição de segurança para estrutura desktop. Finalmente, podemos introduziu alguns novos recursos que oferecem maior flexibilidade de host e biblioteca desenvolvedores sobre seus serviços expostos. Com essas alterações, o .NET Framework 4 boasts um modelo de segurança aprimorada, mais simples que torna fácil para hosts e bibliotecas de código seguro e bibliotecas para expor serviços com segurança.

Background no .NET Framework Security

Antes de mergulhar no qualquer recurso específico, ele ajuda a ter um pouco plano de fundo como funciona a segurança no .NET Framework. Código parcialmente confiável é restrito por permissões que possui e diferentes APIs exigirá permissões diferentes para ser chamado com êxito. O objetivo da CAS é certificar-se de que o código não confiável é executada com permissões apropriadas e não pode fazer nada além de suas permissões sem autorização.

Podemos imaginar o modelo de segurança do .NET como três partes que compõem. Aperfeiçoamentos específicos foram feitos em cada área e o restante deste artigo é organizado de acordo com essas três seções fundamentais:

Diretiva — Diretiva de segurança determina quais permissões para dar um determinado assembly não confiável ou aplicativo. Código gerenciado tem evidências objetos associados a ele, que pode descrever onde o código é carregado, quem publicou e assim por diante. Evidência pode ser usada para determinar quais permissões são apropriadas; o resultado é chamado de conjunto de conceder permissão. O .NET Framework tem usado tradicionalmente diretiva CAS como um mecanismo de máquina para regem isso. Como mencionado anteriormente, a diretiva CAS tem sido overhauled em favor de realizando hosts mais flexibilidade em seus próprios código unhosted paridade com código nativo e diretiva de segurança.
Modo seguro — Modo seguro é o processo real de restringir assemblies ou aplicativos para uma determinada permissão conceder o conjunto. A maneira preferencial seguro é criar um domínio de aplicativo de modo seguro que contém uma concessão de permissão definida para assemblies carregados e uma lista de isenção para assemblies específicos de biblioteca (esses são concedidas confiança total). Com o obsoletion diretiva CAS, código de confiança parcial sempre obtém no modo seguro dessa maneira no .NET Framework 4.
Imposição — Imposição refere-se o mecanismo que mantém o código não confiável restringido para seu seguro. Uso adequado de imposição APIs impede que um assembly não confiável de simplesmente chamando uma API em um assembly diferente, mais confiáveis e exercer maiores permissões dessa maneira. Ele também permite que os desenvolvedores de biblioteca e host para expor o acesso controlado, limitado a comportamento elevado e fornecer serviços significativos para código parcialmente confiável. O modelo Transparência de segurança do nível 2 torna muito mais fácil fazer isso com segurança.

O modelo de segurança do .NET sempre foi de importância específica para desenvolvedores de biblioteca e host (que geralmente vá mão em mão). Exemplos de modelo de segurança .NET são ASP.NET e SQL CLR, qual ambos hospedam código gerenciado dentro de ambientes controladas e contextos restritos. Quando um host como essas quer carregar um assembly parcialmente confiável, ele cria um domínio de aplicativo no modo seguro com o conjunto de conceder a permissão apropriada. Em seguida, o assembly é carregado neste domínio no modo seguro. O host também fornece a biblioteca de APIs que são totalmente confiáveis, mas podem ser chamados do código hospedado. As bibliotecas também são carregadas para o domínio no modo seguro, mas explicitamente são colocadas na lista de isenção mencionada anteriormente. Eles dependem de mecanismos de imposição do .NET Framework para garantir que o acesso a seus elevados capacidades é rigidamente controlado.

Para a maioria dos desenvolvedores de aplicativo gerenciado, isso é tudo mágico que está acontecendo no nível da estrutura — até mesmo os desenvolvedores escrever código que será executado em uma área não precisam saber todos os detalhes de como funciona o modelo de segurança. O framework garante o código no modo seguro é limitado a usar APIs e capacidades que fornece o host. O modelo de segurança do .NET e CAS longo foram território de host e biblioteca de desenvolvedores e administradores de empresa; para eles, fizemos coisas mais fácil do que nunca.

Diretiva

Foi fornecida diretiva CAS desde o início do .NET Framework para dar máquina e empresa administradores uma maneira para ajustar o que o runtime considerado confiável ou não confiáveis. Enquanto a diretiva CAS foi muito poderosa e permitido para controles muito granulares, era extremamente difícil obter direito e poderia impedir mais de Ajuda. Os administradores da máquina podem bloquear determinados aplicativos de permissões necessárias (descritos na próxima seção principal, modo seguro) e muitas pessoas se perguntou por que seus aplicativos repentinamente parou de funcionar depois que eles decidiram colocá-los em um compartilhamento de rede. Além disso, as configurações de diretiva de CAS não mover de uma versão do runtime para outro, portanto, a diretiva CAS personalizada elaborada que alguém configurada no .NET Framework 1.1 tinha que ser refeitas mão para .NET Framework 2.0.

Diretiva de segurança poderia ser dividida em dois cenários: diretiva de segurança para diretiva de código e segurança hospedada de máquina ou da empresa. Sobre diretiva de máquina, a equipe de segurança do Common Language Runtime decidiu o runtime foi o lugar errado para regem a ele, como código nativo obviamente não estava sujeito a suas restrições. Enquanto faz sentido para hosts ser capaz de determinar o que pode fazer seu código hospedado, unhosted executáveis que simplesmente clicados ou executar a partir da linha de comando devem se comportam como suas contrapartes nativos (especialmente porque eles aparência idênticos para usuários executando-los).

É o local correto para a diretiva de segurança global no nível do sistema operacional, onde uma diretiva aplicaria nativo e gerenciado código igualmente. Portanto, podemos está incentivando os administradores da máquina para examinar soluções como diretivas de restrição de software do Windows e resolução de diretiva de CAS máquina desabilitação por padrão. Outro cenário, diretiva de segurança para código hospedado, ainda é muito válido no mundo do código gerenciado. Diretiva de segurança do host agora é mais fácil regem, como não irá conflitar com uma diretiva de máquina arbitrário.

Isso significa para você

Para um, todas unhosted código gerenciado é executado como totalmente confiáveis por padrão. Se você executar um .exe do seu disco rígido ou um compartilhamento de rede, seu aplicativo terá todas as capacidades teria um aplicativo nativo executando o mesmo local. Código hospedado, no entanto, é ainda sujeitos às decisões de segurança do host. (Note que todas as formas de código pode chegar via Internet são hospedado cenários — aplicativos ClickOnce, por exemplo — portanto, isso não significa que o código executado pela Internet é totalmente confiável.)

Para muitos aplicativos, essas alterações são principalmente em segundo plano e não terá nenhum efeito percebido. Aqueles que são afetados pela alteração podem executar em dois problemas. A primeira é que determinados APIs relacionadas à diretiva de CAS são preteridas, muitos tendo fazer com cargas de assembly (isso ler em se fazer isso em todos os). Segundo e affecting menos pessoas (principalmente hosts), será o fato de domínios de aplicativo heterogêneos (que são descritos na seção de modo seguro) não estão disponíveis por padrão.

Mas não Estou fazendo qualquer isso! Como apenas fazer? ele funcionar

Talvez você tenha executado em uma mensagem de erro ou obsoletion parecia algo assim:

Este método usa [explicitamente/implicitamente] diretiva de CAS que tem sido ultrapassada pelo .NET Framework. Para ativar a diretiva de CAS por razões de compatibilidade, use a opção de configuração de NetFx40_LegacySecurityPolicy. Consulte [link a documentação MSDN] para obter mais informações.

Por razões de compatibilidade, fornecemos uma opção de configuração que permite que um processo ativar a resolução de diretiva de CAS nele. Você pode ativar a diretiva CAS colocando o seguinte no arquivo de app.config do projeto:

<configuration>
   <runtime>
      <!-- enables legacy CAS policy for this process -->
      <NetFx40_LegacySecurityPolicy enabled="true" />
   </runtime>
</configuration>

A seção a seguir descreve onde começar procurando migração, se a exceção está sendo lançada de seu próprio código. Se não estiver, em seguida, a opção de configuração é a maneira de ir e a seção a seguir não deve aplicar diretamente para você.

APIs afetadas

APIs afetadas pode ser divididas em dois grupos: aqueles que explicitamente usando diretiva de CAS e aqueles que implicitamente estão usando. Usos explícitos são óbvios — eles tendem a residem na classe System.Security.Policy.SecurityManager e aparência SecurityManager.ResolvePolicy. Essas APIs diretamente chamam ou modificar configurações de diretiva de CAS da máquina e eles têm todos foi preteridos.

Usos implícitos são menos óbvios — eles tendem a ser cargas de assembly ou criações de domínio de aplicativo levar evidências. Diretiva CAS é resolvida nessa evidência e o assembly é carregado com o conjunto resultante de conceder permissão. Desde que a diretiva CAS está desativado por padrão, não faz sentido para tentar resolver nessa evidência. Um exemplo de uma API é assembly.Load (assemblyRef AssemblyName, assemblySecurity Evidence).

Há algumas das razões por que seria chamada de uma API:

Modo seguro — Talvez você sabe que chamar a sobrecarga que assembly.Load com evidências de zona da Internet resultará em que o assembly carregado com a Internet chamado conjunto de permissão (a menos, isto é, um administrador alterado esse mapeamento de evidências para este usuário ou máquina específica!).
Outros parâmetros na sobrecarga — Talvez você simplesmente quisesse obter um parâmetro específico que existia somente nessa sobrecarga. Nesse caso, você talvez tenha simplesmente passado nulo ou Assembly.GetExecutingAssembly () .Evidence para o parâmetro de evidências.

Se você estiver tentando seguro, a seção de modo seguro descreve como criar um domínio de aplicativo no modo seguro restringido à Internet permissão conjunto nomeada Seu assembly pôde ser carregado no domínio e ser garantido ter as permissões pretendido (isto é, não sujeito a whims de um administrador).

O segundo cenário, adicionamos sobrecargas para cada uma dessas APIs que expor todos os parâmetros necessários, mas não expõem um parâmetro de evidências. Migração é uma simples questão de recortando fora o argumento de evidências para suas chamadas. (Observe que passar Evidence nulo em uma API obsoleta ainda funciona bem, como não resultar na avaliação da diretiva de CAS).

Uma coisa adicional a observar é que se você estiver fazendo uma carga de assembly de um local remoto (isto é, Assembly.LoadFrom(“http://...”)), inicialmente obterá uma FileLoadException a menos que a seguinte opção de configuração é definida. Isso foi feito porque esta chamada seria tiver em modo seguro o assembly no passado. Com a diretiva CAS desaparecida, é totalmente confiável!

<configuration>
   <runtime>
      <!-- WARNING: will load assemblies from remote locations as fully
         trusted! -->
      <loadFromRemoteSources enabled="true" />
   </runtime>
</configuration>

Outra maneira de fazer isso, sem ligar esta opção para todo o processo é usar a nova API Assembly.UnsafeLoadFrom, que atua como LoadFrom com a opção definida. Isso é útil se você deseja habilitar remotas cargas em determinados locais ou não possuir o aplicativo primário.

Com a diretiva de CAS máquina da imagem, todos os exame da evidência do assembly e decisões relacionadas a conjuntos de permissão apropriada é da esquerda para hosts de código gerenciado. Sem um sistema complicado de ele interferindo com suas decisões de segurança (além de qualquer diretiva de segurança do SO), um host está livre para atribuir suas próprias permissões. Agora é hora de atribuir essas permissões para assemblies de confiança parcial.

Modo seguro

Via diretiva de segurança do host, podemos determinar o conjunto de conceder a permissão correta para dar um assembly de confiança parcial. Agora precisamos de uma maneira simples e eficaz para carregar o assembly em um ambiente é restrito ao conjunto de conceder específico. Modo seguro, particularmente usando a sobrecarga de CreateDomain simples modo seguro, faz exatamente isso.

Modo seguro no passado

Com o antigo modelo de diretiva de CAS, foi possível criar um domínio de aplicativo heterogêneos, onde cada assembly no domínio tinha sua própria permissão definida. Carregar um assembly com evidências de zona de Internet pode resultar em dois ou mais assemblies em níveis de confiança parcial diferente que está sendo carregados no mesmo domínio que o assembly confiança total, fazendo o carregamento. Além disso, o domínio de aplicativo poderia ter sua própria evidência, dando seu próprio conjunto de permissão.

Há vários problemas com esse modelo:

O conjunto de permissões concedido a um assembly é dependente de diretiva de CAS, como vários níveis de diretiva são interseção para computar o conjunto final de permissão. Portanto, é possível acabar com menos permissões do que se destina.
Semelhante ao ponto anterior, avaliação de evidências em um assembly é feita pela diretiva CAS, que poderia diferem entre máquinas, usuários e até mesmo versões do runtime (diretiva de CAS configurações não movem para frente com novas versões do runtime). Portanto, não era sempre óbvio que conjunto de concessão de permissão foi Obtendo um assembly.
Assemblies de confiança parcial geralmente não são examinados para segurança de proteção, tornando “ confiança intermediária ” assemblies vulnerável “ menor confiar ” assemblies. Assemblies são livremente e facilmente capazes de chamar outros, portanto, ter muitas com diferentes capacidades torna-se problemático de uma perspectiva de segurança. Pode alguém estar certo de que cada combinação de chamadas de assemblies em níveis de confiança diferente é segura? É absolutamente seguro para informações de cache de uma camada intermediária confiança?

Devido a esses problemas, apresentamos o conceito de um domínio de aplicativo homogêneos, que contém somente dois conjuntos de concessão de permissão (confiança total e confiança parcial) e é extremamente simples para criar e motivo sobre. Domínios homogêneos e como criá-los, descrito posteriormente nesta seção.

Outro mecanismo popular para o modo seguro foi o uso de PermitOnly e negar, são pilha movimentar modificadores que permissões permitido específicas lista (e nada mais) e não permitir permissões específicas, respectivamente. Parecia útil digamos, “ quero apenas a chamadores com permissões x e y para poder chamar essa API ” ou “ como API, desejo Negar permissão a todos os meus chamadores. ” No entanto, esses modificadores foi na verdade não alterar o conjunto de conceder permissão de um determinado assembly , que significava que eles poderiam ser declarados fora porque todos eles fizeram foi demandas de intercepção . Um exemplo em ação é mostrado no do Figura 1.

Figura 1 uma chamada de pilha representando negar uma tentativa no modo seguro com

Sem Assert vermelho, a demanda acertos Negar e stack walk é encerrada. Quando o Assert vermelho está ativo, no entanto, Negar é nunca hit, como confiável tem declarada fora a demanda. (Anotações: Pilha de chamada está crescendo para baixo. APIs não representam APIs reais na estrutura.) Por esse motivo, Negar é preterido no .NET Framework 4, porque ele usar é sempre uma brecha de segurança (PermitOnly é ainda ao redor porque pode ser usado legitimamente em alguns casos de canto, mas é geralmente desencorajado). Observe que ele pode ser reativado usando a opção NetFx40_LegacySecurityPolicy, mencionada na seção diretiva acima.

Modo seguro hoje

Para o .NET Framework, a unidade de isolamento que usamos é o domínio de aplicativo. Cada domínio de aplicativo de confiança parcial tem um conjunto de concessão de permissão única obter todos os assemblies carregados nela, exceto para aqueles especificamente listado na lista de isenção confiança total ou carregados do cache de assembly global. Criar este domínio é muito simples — o .NET Framework fornece um modo seguro simples API que leva em tudo que você precisa criar o domínio:

AppDomain.CreateDomain( string friendlyName,
 
                        Evidence securityInfo,
                        
                        AppDomainSetup info,
                        
                        PermissionSet grantSet,
                        
                        params StrongName[] fullTrustAssemblies);

Onde os parâmetros são:

friendlyName — O nome amigável do domínio do aplicativo.
securityInfo — Evidências associado com o domínio do aplicativo. Isso não é usado para resolução de diretiva de CAS, obviamente, mas pode ser usado para armazenar coisas como informações do Editor.
info — Informações de inicialização de domínio de aplicativo. Isso deve incluir, no mínimo, um ApplicationBase, que representa o armazenamento onde residem os assemblies de confiança parcial.
grantSet — A permissão conceder o conjunto de assemblies carregados todos neste domínio, exceto para aqueles na lista de confiança total ou na global assembly cache.
fullTrustAssemblies — Uma lista de StrongNames dos assemblies recebem confiança total (isento de confiança parcial).

Depois que o domínio é criado, você pode chamar AppDomain.CreateInstanceAndUnwrap em um MarshalByRefObject no seu assembly de confiança parcial e chamar em seu método de ponto de entrada para dispará-lo, conforme mostrado no do Figura 2.

Figura 2 do seguro com código de confiança parcial Running Inside

PermissionSet permset = new PermissionSet(PermissionState.None);
ps.AddPermission(new SecurityPermission(
   SecurityPermissionFlag.Execution));
AppDomainSetup ptInfo = new AppDomainSetup();
ptInfo.ApplicationBase = ptAssemblyStore;
 
AppDomain sandboxedDomain = AppDomain.CreateDomain(
   "Sandbox",
   AppDomain.CurrentDomain.Evidence,
   ptInfo,
   permset);
 
// assume HarnessType is in the GAC and a MarshalByRef object

HarnessType ht = sandboxedDomain.CreateInstanceAndUnwrap(
   typeof(HarnessType).Assembly.FullName,
   typeof(HarnessType).FullName)
   as HarnessType;
 
ht.LoadPTEntryPoint();

E pronto! Com várias linhas de código, agora temos um modo seguro com confiança parcial código executado nele.

Essa API CreateDomain realmente foi adicionado no .NET Framework 2.0, portanto, não é novo. Entretanto, vale a pena mencionar como agora é a única maneira de realmente suportada código seguro. Como você pode ver, o conjunto de permissão é passado diretamente, portanto, nenhuma evidência tem ser avaliados em carregar assemblies neste domínio; saber exatamente qual cada assembly carregado vai ficar. Além disso, você está usando um limite de isolamento real para conter código de confiança parcial, que é extremamente útil fazendo Pressuposições de segurança. Com o modo seguro simples CreateDomain API, áreas de segurança se tornam mais óbvio, consistente e seguro — todas as coisas que ajudam a tornar não confiáveis a lidar com código mais fácil.

Imposição

Neste ponto, temos uma permissão apropriada conceder o conjunto para nosso assembly confiança parcial e ter carregado o assembly em uma proteção adequada. Ótimo! No entanto, e se quisermos realmente expor alguns elevados funcionalidade para código parcialmente confiável? Por exemplo, não pode quer dar acesso ao sistema de arquivo completo para um aplicativo de Internet, mas eu não mente se lê e gravar a partir de uma pasta temporária conhecida.

Aqueles que leia a coluna do ano passado na segurança do Silverlight (msdn.microsoft.com/magazine/cc765416.aspx ) sabem exatamente como esse problema é corrigido em que plataforma — por meio de transparência segurança modelo que organizadamente código divide em três compartimentos. Estou feliz dizer que avanço do Silverlight do modelo agora está em vigor no .NET Framework 4. Isso significa que os benefícios do modelo mais simples aproveitado pelas bibliotecas da plataforma Silverlight estão agora disponíveis para desenvolvedores de não-Microsoft de bibliotecas de confiança parcial. Antes de entrarei em que e outras melhorias no espaço de imposição, porém, discutirei nossos mecanismos de imposição primário de antes.

Imposição no passado

Mencionei último ano que transparência de segurança foi realmente introduzida no .NET Framework 2.0, mas servida principalmente como um mecanismo de auditoria em vez de uma imposição um (o novo modelo Transparência da segurança é ambos). No antigo modelo, ou transparência de segurança do nível 1, violações não se manifestam falhas como disco rígidas — muitas delas (como p/invocando em código nativo) resultaram em demandas de permissão. Se seu assembly transparente aconteceu ter UnmanagedCode no seu conjunto de concessão, pode ainda vá em frente e fazer o que estava fazendo (violando regras transparência no processo). Além disso, verificações de transparência interrompidas no limite do assembly, ainda mais reduzindo sua eficácia de imposição.

Imposição True no .NET Framework 2.0 veio na forma de LinkDemands — verificações de tempo JIT verificado se o conjunto de concessão de chamada assembly contido permissão especificada. Foi todas bem e boa, mas esse modelo essencialmente obrigatório biblioteca aos desenvolvedores usar dois mecanismos diferentes para auditoria e imposição, é redundante. O modelo do Silverlight, que consolidadas e simplificadas esses dois conceitos foi uma progressão desse estado natural e se tornou o que agora é nível 2 segurança transparência.

Transparência da segurança de nível 2

Transparência da segurança de nível 2 é um mecanismo de imposição que separa o código é seguro para execução em ambientes de baixa confiança e código que não é. Em poucas palavras, ele desenha uma barreira entre o código que pode fazer coisas sensíveis à segurança (críticas), como operações de arquivo e o código que não consigo (transparente).

O modelo Transparência da segurança separa código em três compartimentos: Transparente de segurança crítica e Critical O diagrama a seguir, de Figura 3, descreve essas classificações. (Observação: Setas verdes representam chamadas são permitidas; setas vermelhas representam aquelas que não estão. Self-loops são válidos também, mas não mostrado.)

Figura 3 do modelo de transparência da segurança

Para aplicativos de área de trabalho típicos, o modelo Transparência do nível 2 tem efeito perceptível — código que não tem quaisquer anotações de segurança e não está no modo seguro é assumido como crítica, portanto é irrestrita. No entanto, pois é crítica, é off-limits para chamadores de confiança parcial. Portanto, os desenvolvedores que não têm cenários de confiança parcial não precisam se preocupar expor nada para confiança parcial.

Para aplicativos em modo seguro, o oposto é verdadeiro — qualquer assembly carregado em um domínio de aplicativo no modo seguro é considerado completamente transparente (mesmo se ele tem anotações especificando o contrário). Isso garante que o código de confiança parcial não pode tentar elevar via declarar permissões ou chamar código nativo (uma ação equivalente confiança total).

Bibliotecas expostas a chamadores de confiança parcial, ao contrário de aplicativos de desktops ou no modo seguro, devem ser keenly ciente dos seus requisitos de segurança e ter muito mais flexibilidade sobre suas capacidades e elas expõem. Uma típica biblioteca callable confiança parcial deve ser código com um conjunto mínimo de segurança APIs Critical principalmente transparente e crítico. Código crítico enquanto irrestrito, é conhecido por ser inacessíveis a partir do código de confiança parcial. Código transparente é callable do código de confiança parcial, mas é seguro. Código Critical seguro é extremamente perigoso como ele fornece funcionalidade elevada e máxima devem ter cuidado para certificar-se de que seu chamador é validada antes de transição sobre código Critical.

Os atributos de transparência da segurança e seus comportamentos listados e descritos no do Figura 4. Tenha em mente que o atributo com escopo mais alto se aplica para todas as APIs introduzidas sob ele, independentemente dessas APIs terem suas próprias anotações. AllowPartiallyTrustedCallers é diferente, adia para e honra atributos de nível inferior. (Observação: Esta tabela descreve os atributos e seus comportamentos quando aplicada no nível do assembly, tipo ou membro. Aplicam os atributos somente para APIs introduzidas, que significa subclasses e substituições estão sujeitos a regras de herança e podem estar em diferentes níveis de transparência.)

Figura 4 seus comportamentos e atributos de transparência da segurança

Aqueles que se lembrar artigo do outubro último provavelmente irão notar que os atributos de trabalhar, mais ou menos, da mesma forma que eles fazem no Silverlight. Você também pode se lembrar que havia regras de herança específicos associadas com os diferentes tipos de código. Essas também são efeito na área de trabalho. Para obter mais detalhes sobre as regras de herança e outros aspectos de nível 2 transparência, olhada no artigo do ano passado, “ segurança no Silverlight 2 ” (msdn.microsoft.com/magazine/cc765416.aspx ).

AllowPartiallyTrustedCallers condicional

O atributo AllowPartiallyTrustedCallers (APTCA) indica que um assembly é uma biblioteca pode expor a funcionalidade sensível à segurança para confiança parcial. Assemblies de biblioteca APTCA freqüentemente são gravados em conjunto com hosts, desde que os hosts normalmente deseja expor a funcionalidade específica para seus ambientes de hospedagem. Um exemplo principal é ASP.NET, que expõe o namespace System.Web para o seu código hospedado, que pode estar em vários níveis de confiança.

No entanto, colocar APTCA em um meio de assembly está disponível para confiança parcial em qualquer host que decide carregá-lo, que pode ser um passivo se o autor do assembly não sabe como esse assembly comportará em hosts diferentes. Portanto, o host desenvolvedores às vezes desejam suas bibliotecas estejam disponíveis para confiança parcial somente quando carregado seus próprios domínios. O ASP.NET faz exatamente isso e versões anteriores teve usar LinkDemands para permissões especiais em suas APIs. Enquanto isso funciona, causa todos criação de eles têm que satisfazer que LinkDemand impedindo esses assemblies up pilha sendo transparente.

Para resolver isso, apresentamos o recurso de APTCA condicional que permite bibliotecas expor APIs para chamadores de confiança parcial somente em um host ativando (por meio de uma lista).

Funções específicas do host e biblioteca são:

A biblioteca simplesmente qualifica o atributo AllowPartiallyTrustedCallers com um parâmetro enum PartialTrustVisibilityLevel. Por exemplo:

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel= PartialTrustVisibilityLevel.NotVisibleByDefault)]

Este atributo basicamente diz que a biblioteca é callable de confiança parcial, a menos que o host o tem em sua lista Permitir, mencionado abaixo. Um valor de VisibleToAllHosts tornaria a biblioteca callable de confiança parcial em todos os hosts.
Host Especifica assemblies visível de confiança parcial, por domínio de aplicativo por meio de uma lista de permissões. Normalmente, esta lista é preenchida por meio de um arquivo de configuração fornecido para o host. Uma coisa importante ter em mente é que assemblies APTCA incondicional, como bibliotecas estrutura básica, não precisam ser adicionado a esta lista. (também é importante ter em mente é que, se você estiver ativando um assembly APTCA condicional, você deve habilitar seu fechamento transitivo de assemblies APTCA condicional dependentes também. Caso contrário, você pode terminar com comportamento ímpar, como seu assembly original tenta chamar APIs que supõe que são acessíveis, mas não são realmente.)

Mais fácil de seguros

Muito aconteceu no modelo de segurança do .NET Framework 4. Diretiva CAS foi desativada por padrão, deixando segurança todas as decisões de diretiva para o host e concedendo unhosted executáveis gerenciados comportamental paridade com executáveis nativos. Desativando a diretiva CAS também desabilitou domínios de aplicativo heterogêneos, tornando o simples-modo de seguro eficiente finalmente CreateDomain sobrecarregar o mecanismo de modo seguro com suporte primário para assemblies de confiança parcial. Aprimoramentos do Silverlight para o modelo Transparência de segurança, última outubro, descrito também tem vir para a área de trabalho, fornecendo aos desenvolvedores de biblioteca de confiança parcial com a mesma eficiência e cleanliness benefícios que foram fornecidos a plataforma Silverlight.

Nós já especialmente criado essas alterações no como uma maneira que a maioria dos aplicativos continuarão a funcionar como eles têm antes, mas os desenvolvedores host e biblioteca lá fora encontrará um modelo mais simples para trabalhar com — uma que é mais determinista, mais simples usar e, portanto, mais fácil proteger.

Andrew Dai é um gerente de programa na equipe de segurança do CLR. Para obter mais informações detalhadas sobre como usar os recursos mencionados neste artigo, visite o blog da equipe de CLR (blogs.msdn.com/clrteam ) e Shawn Farkas ’ .NET segurança blog (blogs.msdn.com/shawnfa ).