Skip to main content
Código transparente de segurança, nível 2
 

System_CAPS_cautionCuidado

Segurança de Acesso do Código e Código Parcialmente Confiável

O .NET Framework fornece um mecanismo para a imposição de níveis variáveis de confiança em códigos diferentes em execução no mesmo aplicativo chamado CAS (Segurança de Acesso do Código).  O CAS no .NET Framework não deve ser usado como um mecanismo de imposição de limites de segurança com base na origem do código ou em outros aspectos da identidade. Estamos atualizando nossas diretrizes para refletir que o CAS e o Código Transparente de Segurança não terão suporte como um limite de segurança com código parcialmente confiável, especialmente o código de origem desconhecida. Não aconselhamos carregar e executar códigos de origens desconhecidas sem a adoção de medidas de segurança alternativas no local.

Essa política é aplicável à todas as versões do .NET Framework, mas não é aplicável ao .NET Framework incluído no Silverlight.

Transparência de nível 2 foi introduzida no .NET Framework 4. Os três princípios desse modelo são código transparent, código de segurança crítica segura e código de segurança crítica.  

  • Código Transparent, incluindo o código que está executando em confiança total, pode chamar outro código transparent ou código de segurança crítica segura somente. Ele só pode executar ações permitidas pela permissão de confiança parcial do domínio definir (se houver). O código Transparent não pode fazer o seguinte:

    • Executar um Assert ou elevação de privilégio.

    • Conter código não confiável ou.

    • Chame um código crítico diretamente.

    • Chamar código nativo ou código com o SuppressUnmanagedCodeSecurityAttribute atributo.

    • Chamar um membro que está protegido por um LinkDemand.

    • Herde de tipos critical.

    Além disso, os métodos transparentes não podem substituir métodos virtuais críticos ou implementar métodos de interface críticos.

  • Código crítico de segurança é totalmente confiável, mas pode ser chamado pelo código transparent. Ele expõe uma área de superfície limitada do código de confiança total; verificações de segurança e correção acontecem no código crítico de segurança.

  • Código de segurança crítica pode chamar qualquer código e é totalmente confiável, mas ele não pode ser chamado pelo código transparent.

Este tópico contém as seguintes seções:

  • Exemplos de Uso e Comportamentos

  • Substituir Padrões

  • Regras de Herança

  • Informações Adicionais e Regras

Para especificar .NET Framework 4 regras (transparência de nível 2), use a seguinte anotação para um assembly:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Para bloquear nas regras do .NET Framework 2.0 (transparência de nível 1), use a anotação a seguir:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Se você não anotar um assembly, o .NET Framework 4 regras são usadas por padrão. No entanto, a prática recomendada é usar o SecurityRulesAttribute de atributo, em vez de dependendo do padrão.

As seguintes regras se aplicam ao uso de atributos em nível de assembly:

  • Nenhum atributo: se você não especificar os atributos, o runtime interpreta todos os códigos como segurança crítica, exceto onde sendo crítico de segurança viola uma regra de herança (por exemplo, ao substituir ou implementando um transparente virtual ou método de interface). Nesses casos, os métodos são crítico de segurança. Não especificar nenhum atributo faz com que o common language runtime determinar as regras de transparência para você.

  • SecurityTransparent: Todo o código é transparente; todo o assembly não fará nada privilegiado ou não seguro.

  • SecurityCritical: Todo o código apresentado pelos tipos neste assembly é importante; todos os demais códigos é transparente. Esse cenário é semelhante ao não especificar nenhum atributo; No entanto, o common language runtime não determinar automaticamente as regras de transparência. Por exemplo, se você substituir um método virtual ou abstrato ou implementa um método de interface, por padrão, esse método é transparente. Você deve anotar explicitamente o método como SecurityCritical ou SecuritySafeCritical; caso contrário, um TypeLoadException será lançada em tempo de carregamento. Essa regra também se aplica quando a classe base e a classe derivada estão no mesmo assembly.

  • AllowPartiallyTrustedCallers (nível 2 somente): todas as código padrão é transparente. No entanto, membros e tipos individuais podem ter outros atributos.

A tabela a seguir compara o comportamento de nível de assembly para o nível 2 com o nível 1.

Atributo de assembly

Nível 2

Nível 1

Nenhum atributo em um assembly parcialmente confiável

Tipos e membros são por padrão transparente, mas podem ser crítico de segurança ou segurança crítica segura.

Todos os tipos e membros são transparentes.

Nenhum atributo

Não especificar nenhum atributo faz com que o common language runtime determinar as regras de transparência para você. Todos os tipos e membros são críticas para a segurança, exceto onde sendo crítico de segurança viola uma regra de herança.

Em um assembly totalmente confiável (no cache de assembly global ou identificado como confiança total no AppDomain) todos os tipos são transparentes e todos os membros são segurança crítica segura.

SecurityTransparent

Todos os tipos e membros são transparentes.

Todos os tipos e membros são transparentes.

SecurityCritical(SecurityCriticalScope.Everything)

Não aplicável.

Todos os tipos e membros são críticas de segurança.

SecurityCritical

Todo o código apresentado pelos tipos neste assembly é importante; todos os demais códigos é transparente. Se você substituir um método virtual ou abstrato ou implementa um método de interface, você deve anotar explicitamente o método como SecurityCritical ou SecuritySafeCritical.

Todos os códigos padrão é transparente. No entanto, membros e tipos individuais podem ter outros atributos.

Os atributos de segurança que são aplicados a um tipo também se aplicam aos membros que são introduzidos pelo tipo. No entanto, eles não se aplicam ao virtual ou abstrato substituições das implementações de interface ou classe base. As seguintes regras se aplicam ao uso de atributos em nível de tipo e membro:

  • SecurityCritical: O tipo ou membro é fundamental e pode ser chamado apenas pelo código de confiança total. Métodos que são introduzidos em um tipo crítico de segurança são essenciais.

    System_CAPS_importantImportante

    Métodos abstratos e virtuais que são introduzidos em interfaces ou classes base e substituídos ou implementados em uma classe de segurança crítica são transparentes por padrão. Eles devem ser identificados como SecuritySafeCritical ou SecurityCritical.

  • SecuritySafeCritical: O tipo ou membro é crítico de segurança. No entanto, o tipo ou membro pode ser chamado no código transparent de (parcialmente confiável) e é capaz de qualquer outro código crítico. O código deve ser auditado para segurança.

Voltar ao início

A tabela a seguir mostra as substituições de método permitidas para transparência de nível 2.

Membro base virtuais/interface

Substituição/interface

Transparent

Transparent

Transparent

SafeCritical

SafeCritical

Transparent

SafeCritical

SafeCritical

Critical

Critical

Voltar ao início

Nesta seção, a seguinte ordem é atribuído a Transparent, Critical, e SafeCritical código com base em recursos e acesso:

Transparent < SafeCritical < Critical

  • Regras para tipos: saindo da esquerda para a direita, o acesso se torna mais restritivo. Tipos derivados devam ser pelo menos tão restritivos quanto o tipo base.

  • Regras para métodos: métodos derivados não podem alterar a acessibilidade do método base. Para o comportamento padrão, todos os métodos derivados que são anotados não são Transparent. Derivados de tipos critical causam uma exceção seja lançada se o método substituído não é anotado explicitamente como SecurityCritical.

A tabela a seguir mostra o tipo permitido padrões de herança.

Classe base

Classe derivada pode ser

Transparent

Transparent

Transparent

SafeCritical

Transparent

Critical

SafeCritical

SafeCritical

SafeCritical

Critical

Critical

Critical

A tabela a seguir mostra o tipo não permitido padrões de herança.

Classe base

Classe derivada não pode ser

SafeCritical

Transparent

Critical

Transparent

Critical

SafeCritical

A tabela a seguir mostra o método permitido padrões de herança.

Método base

O método derivado pode ser

Transparent

Transparent

Transparent

SafeCritical

SafeCritical

Transparent

SafeCritical

SafeCritical

Critical

Critical

A tabela a seguir mostra o método não permitido padrões de herança.

Método base

O método derivado não pode ser

Transparent

Critical

SafeCritical

Critical

Critical

Transparent

Critical

SafeCritical

System_CAPS_noteObservação

Essas regras de herança se aplicam a membros e tipos de nível 2. Tipos em assemblies de nível 1 podem herdar de membros e tipos de segurança crítica de nível 2. Portanto, os membros e tipos de nível 2 devem ter demandas de herança separados para os herdeiros de nível 1.

Voltar ao início

O modelo de transparência de nível 2 substitui o LinkDemand com o SecurityCriticalAttribute atributo. No código herdado (nível 1), um LinkDemand é tratado automaticamente como um Demand.

Invocando um método crítico ou a leitura de um campo crítica aciona uma demanda de confiança total (como se você fosse chamando um método particular ou campo). Portanto, o código de confiança total pode invocar um método crítico, enquanto o código parcialmente confiável não pode.

As propriedades a seguir foram adicionadas para o System.Reflection namespace para determinar se o tipo, método ou campo é SecurityCritical, SecuritySafeCritical, ou SecurityTransparent: , , e . Use essas propriedades para determinar a transparência por meio de reflexão em vez de verificar a presença do atributo. As regras de transparência são complexas e verificando o atributo pode não ser suficiente.

System_CAPS_noteObservação

Um SafeCritical método retorna true para ambos e , pois SafeCritical é realmente fundamental (ele tem os mesmos recursos que o código critical, mas ele pode ser chamado no código transparent).

Métodos dinâmicos herdam a transparência dos módulos que estão conectados a; eles não herdam a transparência do tipo (se eles estão conectados a um tipo).

Você pode ignorar a verificação de assemblies transparentes totalmente confiáveis, definindo o propriedade true no SecurityRulesAttribute atributo:

[assembly: SecurityRules(SecurityRuleSet.Level2, SkipVerificationInFullTrust = true)]

O é de propriedade false por padrão, então a propriedade deve ser definida como true para ignorar a verificação. Isso deve ser feito apenas a fins de otimização. Você deve garantir que o código transparente no assembly seja verificável usando o transparent opção o ferramenta PEVerify.