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