Как отрицать Assert с CAS?

Question

В этом коде я хотел бы, чтобы метод ReadFileSystem был запрещен для подтверждения разрешения на файловую систему.

Я ожидал, что это будет выбрано fileIo.Assert(), но это не так. Зачем?

using System.Security.Permissions; 
static void Main(string[] args) 
{ 
    var fileIo = new FileIOPermission(PermissionState.Unrestricted); 
    var secuPerm = new SecurityPermission(SecurityPermissionFlag.Assertion); 
    PermissionSet set = new PermissionSet(PermissionState.Unrestricted); 
    set.AddPermission(fileIo); 
    set.AddPermission(secuPerm); 
    set.Deny(); 
    ReadFileSystem(); 
    Console.Read(); 
} 

private static void ReadFileSystem() 
{ 
    var fileIo = newFileIOPermission(PermissionState.Unrestricted); 
    fileIo.Assert(); 

    DirectoryInfo dir = new DirectoryInfo("C:/"); 
    dir.GetDirectories(); 
} 

Update

Великая ссылка здесь на CAS: http://blogs.msdn.com/shawnfa/archive/2004/08/25/220458.aspx

Answer 1

Последующее Assert отрицает эффекты Deny.

Способность утверждать FileIOPermission в основном зависит от того, доверяет ли ваша сборка. На него не влияет предыдущий отказ от FileIOPermission. Оказывается, на него также не повлиял предыдущий отказ в утверждении SecurityPermission. Это потому, что SecurityPermissionFlag.Assertion проверяется как требование времени соединения. Это явно не задокументировано; Я нашел его here.

Чтобы заставить CLR не доверять вашей сборке для FileIOPermission, вы можете использовать следующее в верхней части файла после операторов using. Когда вы добавите это в свой файл, утверждение не вступит в силу. Это влияет на всю сборку. Нет более тонкой детализации.

[assembly:FileIOPermission(SecurityAction.RequestRefuse, Unrestricted=true)] 

Answer 2

Хороший вопрос наверняка. Я запустил код и немного озадачен. Я просто провожу час или 2, изучая документы и поиск в Интернете, но безрезультатно. Обратите внимание, что MSDN завершает работу, выполняя запрос «Спрос на утверждение».

Редактировать: ответ binarycoder указал мне в правильном направлении.

Права на защиту просто недействительны в сборке с полным ходом. Только если вы добавите следующее в верхнюю часть файла:

[assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse, Assertion = true)] 

вызов файлаIo.Assert() не удастся.

Но в противном случае попытка Запретить() разрешение утверждения и следующий атрибут полностью неэффективны (если только вы явно не задаете() права утверждения).

[SecurityPermissionAttribute(SecurityAction.Deny, Assertion = true)] 
private static void ReadFileSystem() {} 

Документация заявляет что Assert() «имеет некоторые проблемы безопасности» и рекомендация всегда Требуйте-Before-Утверждай:

fileIo.Demand(); 
fileIo.Assert(); 

, но я до сих пор перенастраивать свой образ мышления о применении принципа наименьших привилегий.

Answer 3

Я думаю, вы можете неправильно понять цель утверждения разрешений. Когда вы утверждаете набор разрешений в CAS, вы фактически говорите: «Я знаю, что я делаю ... Мне все равно, какие разрешения глубже в стеке». Это почти никогда что вы хотите. Обычно вы хотите потребовать набор разрешений. Это вызывает прохождение стека, в результате которого в стеке обнаружен Deny, а затем возникнет исключение безопасности.

Однако, поскольку.NET имеет практически все необходимые Demands встроенные, редко требуется на самом деле требовать что-либо, если вы не выполняете Asserts (опять же, это редко), или вы написали свой собственный класс Permission.