Usando o método de negar
.gif "Observação importante") Importante |
|---|
No .NET Framework versão 4, o suporte de tempo de execução foi removido para impor a Deny, RequestMinimum, RequestOptional, e RequestRefuse as solicitações de permissão.Essas solicitações não devem ser usadas no código que se baseia em .NET Framework 4 ou posterior.Para obter mais informações sobre esta e outras alterações, consulte Alterações de segurança na.NET Framework 4. |
Chamando Deny impede o acesso ao recurso especificado pela permissão negada. Se seu código chama Negar e um chamador downstream subseqüentemente exige a permissão negada, a verificação de segurança falhará, mesmo se todos os chamadores têm permissão para acessar o recurso. As permissões exigidas e sendo negada não precisam coincidir exatamente para o Negar tenham efeito e a permissão exigida não precisa ser um subconjunto da permissão negada. No entanto, se a interseção de duas permissões está vazia (isto é, se eles têm nada em comum), a chamada para Negar não terá efeito. Observe que Negar não é possível substituir o código mais profundo na pilha de chamadas que realiza uma Assert. Se o código mais profundo na pilha de chamadas executa um Assert, o código mais profundo pode acessar o recurso que nega a mais alto na pilha de chamadas de código.
Você pode usar chamadas para Negar em seu código para se proteger contra responsabilidade porque Negar torna impossível para o seu código a ser usado para acessar o recurso negado. No entanto, a chamada para Negar não bloqueia declarações de segurança futuras por chamadores downstream.
A ilustração a seguir mostra o que acontece quando você usa Negar. Considere que as seguintes instruções são verdadeiras sobre assemblies A, B, C, D e e e permissão P1:
P1 representa o direito de ler todos os arquivos na unidade C.
Os assemblies A, B, C, D e e foram concedidos P1.
Método f coloca uma demanda de permissão P1.
Método c cria uma instância da classe P1 e chama P1 Negar método.
Método a está contido no assembly A, B do método está contido no assembly b e assim por diante.
Usando negar.
.gif "Demanda e negação de permissão")
A chamada do método c para Negar pode afetar o resultado das demandas de P1. Por exemplo, suponha que chamadas de um método B, B chama C, C chamadas de chamadas e e e f. Porque o método f acessa diretamente o recurso que P1 protege, o método f invoca uma verificação de segurança para P1 chamando P1 demanda método (ou usando uma demanda declarativa). Essa demanda faz com que o tempo de execução verificar as permissões de todos os chamadores na pilha de chamadas, começando com o assembly e. Porque o assembly e concedeu permissão de P1, o tempo de execução passa para examinar as permissões do conjunto c. Mas porque o método c negou P1, a verificação de segurança chamada pelo método e falhará nesse ponto e um SecurityException é lançada. Não importa se o assembly c e seus chamadores (os assemblies a e B) foram concedidas P1; a verificação de segurança ainda falhar. Porque o método c chamado Negar, código de módulos (assemblies) A e b não pode acessar o recurso protegido pelo P1.
O código a seguir mostra a sintaxe declarativa para verificações de segurança de substituição usando o Negar método. Neste exemplo, o ReflectionPermission sintaxe especifica dois valores: um SecurityAction enumeração e a configuração para o TypeInformation propriedade. TypeInformation é definida como true para especificar que essa permissão representa o direito Exibir membros particulares através de reflexão e SecurityAction.Deny é passado para negar essa permissão. Consulte a descrição do ReflectionPermission para obter uma lista completa de valores, você pode especificar. Com essa declaração de segurança, o método não pode ler membros privados de um tipo por meio de reflexão.
Option Strict
Option Explicit
Imports System
Imports System.Security.Permissions
<ReflectionPermissionAttribute(SecurityAction.Deny, TypeInformation = true ")> Public Class
MyClass1
Public Sub New()
End Sub
Public Sub GetPublicMembers ()
' Access public members through reflection.
End Sub
End Class
using System;
using System.Security.Permissions;
[ReflectionPermissionAttribute(SecurityAction.Deny, TypeInformation = true)]
public class MyClass
{
public MyClass()
{
}
public void GetPublicMembers()
{
//Access public members through reflection.
}
}
O código a seguir mostra a sintaxe imperativa para verificações de segurança de substituição usando o Negar método. Neste exemplo, o ReflectionPermission objeto for declarado e seu construtor é passado ReflectionPermissionFlag.TypeInformation para inicializar a permissão atual. Quando o Negar método é chamado, o código e chamadores nunca podem ser usados para ler campos particulares através de reflexão.
Option Explicit
Option Strict
Imports System
Imports System.Security.Permissions
Public Class MyClass1
Public Sub New()
End Sub
Public Sub ReadRegistry()
Dim MyPermission As New ReflectionPermission (ReflectionPermissionFlag.TypeInformation)
MyPermission.Deny()
' Access public members through reflection.
End Sub
End Class
using System;
using System.Security.Permissions;
public class MyClass {
public MyClass() {
}
public void ReadRegistry() {
ReflectionPermission MyPermission = new ReflectionPermission (ReflectionPermissionFlag.TypeInformation);
MyPermission.Deny();
// Access public members through reflection.
}
}
Problemas de canonização usando negar
Você deve ser extremamente cuidadoso ao negando FileIOPermission, RegistryPermission, WebPermission, UrlIdentityPermission, SiteIdentityPermission, e EnvironmentPermission porque os arquivos individuais, as entradas do registro, URLs e os caminhos de sistema podem ser descritos usando vários nomes. Por exemplo, um único arquivo, MyFile.log, pode ser referenciada várias maneiras, incluindo "c:\MyFile.log" e "\\MyMachineName\c$\MyFile.log". Se você criar uma permissão que representa o acesso para "c:\MyFile.log" e, em seguida, negar essa permissão ao seu código, seu código ainda poderão acessar o arquivo usando o caminho alternativo "\\MyMachineName\c$\MyFile.log".
Você pode usar uma combinação de PermitOnly e Negar para evitar problemas de canonização. PermitOnly permite que você especificar apenas um dos possíveis vários nomes para um recurso e tem o efeito colateral de negar acesso a esse recurso usando qualquer outro nome. Depois de usar PermitOnly para especificar o nome permitido um para um recurso, você deve usar Negar para impedir o acesso ao recurso usando esse nome.
O código a seguir usa uma combinação de Negar e PermitOnly para impedir que o seu código acessar um recurso chamado MyLog.log. Esse código também bloqueia o acesso ao recurso usando todos os caminhos ou nomes alternativos.
<FileIOPermissionAttribute(SecurityAction.PermitOnly, All := "C:\ "), FileIOPermissionAttribute(SecurityAction.Deny, All := "C:\MyLog.log")>
[FileIOPermissionAttribute(SecurityAction.PermitOnly, All = @"C:\ ")]
[FileIOPermissionAttribute(SecurityAction.Deny, All = @"C:\MyLog.log")]
Consulte também
Referência
Conceitos
Estendendo metadados usando atributos