Código transparente para a segurança de nível 1
Transparência ajuda os desenvolvedores a escrever mais seguro.NET Framework, bibliotecas que expõem a funcionalidade do código parcialmente confiável. Transparência de nível 1 foi introduzida na.NET Framework versão 2.0 e foi usada principalmente dentro de Microsoft. Começando com o .NET Framework versão 4, você pode usar a transparência de nível 2. No entanto, a transparência de nível 1 foram mantida para que você possa identificar o código herdado que deve ser executado com as regras de segurança anteriores.
.gif "Observação importante") Importante |
|---|
Você deve especificar a transparência de nível 1 somente para compatibilidade; Isto é, especifique o nível 1 para o código que foi desenvolvido com o.NET Framework 3.5 ou anterior que usa o AllowPartiallyTrustedCallersAttribute ou não usar o modelo de transparência.Por exemplo, use a transparência de nível 1 para.NET Framework 2.0 assemblies que permitem que chamadas de chamadores parcialmente confiáveis (APTCA).Para o código que é desenvolvido para o .NET Framework 4, use sempre transparência de nível 2. |
Este tópico contém as seções a seguir:
O modelo de transparência de nível 1
Atributos de transparência
Exemplos de transparência da segurança
O modelo de transparência de nível 1
Quando você usa a transparência de nível 1, você está usando um modelo de segurança que separa o código em métodos transparentes de segurança, segurança safe críticos e críticos de segurança.
Você pode marcar um assembly inteiro, algumas classes em um assembly, ou alguns métodos em uma classe como transparente de segurança. Código transparent de segurança não pode elevar os privilégios. Essa restrição tem três conseqüências:
Não é possível executar o código transparent de segurança Assert Ações.
Qualquer demanda de link seria atendida pelo código transparent de segurança se torna uma demanda completa.
Código não seguro (não verificado) que deve ser executado no código transparente de segurança faz com que uma demanda completa para o UnmanagedCode permissão de segurança.
Essas regras são aplicadas durante a execução pelo common language runtime (CLR). Código de segurança transparente passa todos os requisitos de segurança do código, que ele chama de volta para os chamadores. As demandas que fluem através do código de segurança-transparente não é possível elevar privilégios. Se um aplicativo de baixa confiança chama código transparente de segurança e faz com que uma demanda de alto privilégio, a demanda fluir com o código de baixa confiança e falhar. O código de segurança-transparente não é possível parar a demanda porque ele não pode realizar ações de declaração. O mesmo código transparente de segurança chamado a partir de resultados do código de confiança total em uma demanda bem-sucedidas.
Crítica de segurança é o oposto do security transparent. Código de segurança crítica será executado com confiança total e pode realizar todas as operações privilegiadas. Código de segurança safe crítica é código privilegiado que passou por uma auditoria de segurança abrangentes para confirmar que não permite chamadores parcialmente confiáveis usar recursos que eles não têm permissão para acessar.
Você precisa aplicar transparência explicitamente. A maioria do código que manipula a lógica e a manipulação de dados normalmente pode ser marcada como segurança transparente, enquanto a menor quantidade de código que executa as elevações de privilégios estiver marcada como crítica de segurança ou segurança safe-crítica.
| Importante |
|---|
Transparência de nível 1 é limitada ao escopo do assembly; ela não será aplicada entre assemblies.Transparência de nível 1 foi usada principalmente dentro da Microsoft para fins de auditoria de segurança.Tipos de segurança crítica e membros dentro de um assembly de nível 1 podem ser acessados pelo código transparente para a segurança em outros assemblies.É importante que você realize as demandas de link de confiança total em todos os tipos de segurança crítica de nível 1 e os membros.Membros e tipos importantes de segurança de segurança também devem confirmar que os chamadores têm permissões para recursos protegidos que são acessados pelo tipo ou membro. |
Para compatibilidade com versões anteriores do.NET Framework, todos os membros que não são anotados com atributos de transparência são considerados críticos seguro segurança. Todos os tipos que não são comentados são considerados como transparente. Não há nenhuma regra de análise estática para validar a transparência. Portanto, talvez você precise depurar erros de transparência em tempo de execução.
Atributos de transparência
A tabela a seguir descreve os três atributos que você pode usar para anotar o seu código para transparência.
Atributo |
Descrição |
|---|---|
Permitido somente no nível do assembly. Identifica todos os tipos e membros no assembly como transparente de segurança. O assembly não pode conter qualquer código de segurança crítico. |
|
Quando usado no nível do conjunto, sem a Scope propriedade, identifica todo o código no assembly como transparente de segurança por padrão, mas indica que o assembly pode conter código de segurança crítica. Quando usado no nível de classe, identifica a classe ou método como crítica de segurança, mas não os membros da classe. Para fazer com que todos os membros essenciais de segurança, defina a Scope propriedade para Everything. Quando usado no nível do membro, o atributo se aplica somente a esse membro. A classe ou membro identificado como crítico de segurança pode executar as elevações de privilégio. Observação Em transparência de nível 1, membros e tipos de segurança críticos são tratados como segurança safe críticos quando eles são chamados de fora do assembly.Você deve proteger tipos de segurança críticos e membros com uma demanda de link de confiança total para evitar não autorizada de elevação de privilégio. |
|
Identifica o código de segurança crítico que pode ser acessado pelo código transparente de segurança no assembly. Caso contrário, o código transparent de segurança não pode acessar privados ou internos de segurança críticos membros no mesmo assembly. Isso seria influenciar o código de segurança crítico e possibilitar elevações inesperadas de privilégio. Código critical seguro segurança deve passar por uma auditoria de segurança rigorosas. Observação Membros e tipos de segurança safe crítica devem validar as permissões de chamadores para determinar se o chamador tem autoridade para acessar recursos protegidos. |
O SecuritySafeCriticalAttribute atributo permite que o código transparente de segurança acessar membros de segurança crítica no mesmo assembly. Considere o código de segurança transparente e crítico de segurança no seu assembly como separadas em dois assemblies. O código de segurança-transparente não poderá ver os membros privados ou internos do código de segurança crítico. Além disso, o código de segurança crítico geralmente é auditado para acesso à sua interface pública. Você não esperaria de um estado particular ou interno seja acessível fora do assembly; Você gostaria de manter o estado isolado. O SecuritySafeCriticalAttribute atributo mantém o isolamento do estado entre o código de segurança transparente e críticas de segurança fornecendo a capacidade de substituir o isolamento quando for necessário. Código transparent de segurança só pode acessar código de segurança crítico private ou internal esses membros foram marcados com SecuritySafeCriticalAttribute. Antes de aplicar o SecuritySafeCriticalAttribute, esse membro de auditoria, como se foram exposto.
Anotação de assembly
A tabela a seguir descreve os efeitos do uso de atributos de segurança no nível do assembly.
Atributo de assembly |
Estado do assembly |
|---|---|
Nenhum atributo de um assembly parcialmente confiável |
Todos os tipos e membros são transparentes. |
Nenhum atributo de 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. |
SecurityCritical(SecurityCriticalScope.Everything) |
Todos os tipos e membros são essenciais para a segurança. |
SecurityCritical |
Todos os padrões para transparente de código. No entanto, os membros e tipos individuais podem ter outros atributos. |
Exemplos de transparência da segurança
Para usar o.NET Framework 2.0 regras de transparency (transparência de nível 1), use a seguinte anotação de assembly:
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Se você quiser fazer um assembly inteiro transparente para indicar que o assembly não contém qualquer código crítico e não eleva os privilégios de qualquer maneira, você pode adicionar explicitamente transparência para o assembly com o seguinte atributo:
[assembly: SecurityTransparent]
Se você deseja mixar código transparente e importante no mesmo assembly, iniciar, marcando o assembly com o SecurityCriticalAttribute atributo para indicar que o assembly pode conter código critical, da seguinte maneira:
[assembly: SecurityCritical]
Se você quiser executar ações de segurança críticas, você deve marcar explicitamente o código que executará a ação crítica com outra SecurityCriticalAttribute de atributo, como mostrado no exemplo de código a seguir:
[assembly: SecurityCritical]
Public class A
{
[SecurityCritical]
private void Critical()
{
// critical
}
public int SomeProperty
{
get {/* transparent */ }
set {/* transparent */ }
}
}
public class B
{
internal string SomeOtherProperty
{
get { /* transparent */ }
set { /* transparent */ }
}
}
O código anterior é transparente, exceto o Critical método, que é explicitamente marcado como crítico de segurança. A transparência é a configuração padrão, mesmo com o nível de conjunto SecurityCriticalAttribute atributo.