Código transparente para a segurança de nível 2

Transparência de nível 2 foi introduzida na .NET Framework versão 4. Os três princípios deste modelo são o código transparent, o código critical seguro para segurança e código de segurança crítico.

  • O código Transparent, incluindo o código está sendo executado em confiança total, pode chamar outro código transparent ou somente o código critical seguro para segurança. Ele só pode executar as ações permitidas pela permissão de confiança parcial do domínio definido (se houver). Código Transparent não pode fazer o seguinte:

    • Realizar uma Assert ou a elevação de privilégio.

    • Conter código não seguro ou não verificado.

    • Chame diretamente o código critical.

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

    • Chamar um membro que é protegido por um LinkDemand.

    • Herde de tipos critical.

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

  • Código de segurança crítico é totalmente confiável mas podem 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 correção e segurança acontecem no código seguro-crítico.

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

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

  • Exemplos de uso e comportamentos

  • Substituir padrões

  • Regras de herança

  • Informações adicionais e regras

Exemplos de uso e comportamentos

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 travar na.NET Framework 2.0 regras (transparência de nível 1), use a seguinte anotação:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

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

Anotação de Assemblywide

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

  • Sem atributos: Se você não especificar os atributos, o runtime interpreta todo o código como críticas para a segurança, exceto onde sendo crítica de segurança viola uma regra de herança (por exemplo, quando substituindo ou implementando um transparente virtual ou o método de interface). Nesses casos, os métodos são críticos de seguros. 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; toda a montagem não fará nada privilegiado ou não seguro.

  • SecurityCritical: Todo o código é introduzido pelos tipos neste assembly é importante; todos os outros códigos é transparente. Este cenário é semelhante sem especificar quaisquer atributos; 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 abstract 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 no tempo de carga. Esta regra também se aplica quando a classe base e derivados da classe estiverem no mesmo assembly.

  • AllowPartiallyTrustedCallers(nível 2 somente): Todos os padrões para transparente de código. No entanto, os 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 de um assembly parcialmente confiável

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

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 de segurança críticos, exceto onde sendo crítica de segurança viola uma regra de herança.

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

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 essenciais para a segurança.

SecurityCritical

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

Todos os padrões para transparente de código. No entanto, os membros e tipos individuais podem ter outros atributos.

Tipo e anotação de membro

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

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

    Observação

    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 seguro. No entanto, o tipo ou membro pode ser chamado no código transparent de (parcialmente confiável) e é tão capaz quanto qualquer outro código crítico. O código deve ser auditado para segurança.

Voltar ao topo

Substituir padrões

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

Membro de base virtual/interface

Substituição/interface

Transparent

Transparent

Transparent

SafeCritical

SafeCritical

Transparent

SafeCritical

SafeCritical

Critical

Critical

Voltar ao topo

Regras de herança

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

Transparent < SafeCritical < Critical

  • Regras de tipos: Vai da esquerda para a direita, acesso se torna mais restritivo. Tipos derivados devem 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 não são comentados são Transparent. Derivados de tipos critical causam uma exceção ser acionada se o método substituído não será 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 são permitido os 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

Pode ser o método derivado

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

Método derivado não é possível.

Transparent

Critical

SafeCritical

Critical

Critical

Transparent

Critical

SafeCritical

Observação

Essas regras de herança se aplicam aos membros e tipos de nível 2.Tipos de módulos (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 as demandas de herança separados para os herdeiros de nível 1.

Voltar ao topo

Informações adicionais e regras

Suporte de LinkDemand

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 automaticamente é tratada como uma Demand.

Reflexão

Invocando um método crítico ou a leitura de um campo crítica aciona uma demanda de confiança total (como se você foram invocando um método particular ou do 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 o namespace para determinar se o tipo de método, campo ou é SecurityCritical, SecuritySafeCritical, ou SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical, and IsSecurityTransparent. Utilize 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.

Observação

A SafeCritical método retorna true para ambos IsSecurityCriticale IsSecuritySafeCritical, pois SafeCritical é realmente fundamental (ela 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 eles estão conectados elas não herdam a transparência do tipo (se eles estão conectados a um tipo).

Ignorar a verificação em confiança total

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

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

O SkipVerificationInFullTrust é a propriedade false por padrão, portanto, 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 transparent no assembly é verificável usando o transparent opção na ferramenta de PEVerify.

Voltar ao topo

Consulte também

Conceitos

Código transparente para a segurança de nível 1

Alterações de segurança na.NET Framework 4