Симон Робинсон - C# для профессионалов. Том II

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

□ Запрос всех необходимых полномочий в начале выполнения и постепенное снижение требований или выход, если эти полномочия не предоставлены.

□ Отказ от запроса полномочий в начале выполнения, но готовность обрабатывать исключения безопасности внутри приложения.

Если сборка была сконфигурирована для использования атрибутов полномочий таким образом, мы сможем использовать утилиту permview.exe для просмотра полномочий, нацеливая ее на файл сборки, содержащий манифест сборки:

permview.exe assembly.dll

Вывод для приложения, использующего три показанных атрибута, будет выглядеть так.

minimal permission set:

version="1" Unrestricted="true" />

optional permission set:

version="1"

Flags="UnmanegedCode" />

refused permission set:

version="1"

Read="C:\" />

В дополнение к запрашиваемым полномочиям можно также запросить целое множество прав сразу. Так как некоторые множества полномочий ( Internet, LocalIntranetи Everything) изменяются с помощью политики безопасности при выполнении сборки, то они запрашиваться не могут. Например, если сборка сообщила, что ей необходимо предоставить для выполнения все полномочия в множестве полномочий LocalIntranet, а администратор затем сузил множество прав LocalIntranetво время выполнения приложения, то может быть неизвестно, в каком множестве прав происходит работа.

Существует три множества полномочий, которые нельзя изменить во время выполнения приложения, эти множества могут запрашиваться с помощью атрибутов:

□ Nothing

□ Execution

□ FullTrust

Вот пример того, как запрашивается встроенное множество полномочий:

[assembly:PermissionSetAttribute(SecurityAction.RequestMinimum,

Name = "FullTrust")]

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

Часто, когда предоставлена некоторые полномочия, возникает неявное утверждение, что также даны и другие полномочия. Например, если присвоено полномочие FileIOPermissionдля C:\, то неявно предполагается, что также имеется доступ к его подкаталогам (допущение системы безопасности учетных записей Windows).

Если необходимо проверить, что данное полномочие неявно вносит другое полномочие в качестве подмножества, то можно сделать следующее.

// Пример из SecurityApp5

class Class1 {

static void Main(string[ ] args) {

CodeAccessPermission permissionA =

new FileIOPermission(FileIOPermissionAccess.AllAccess, @"C:\");

CodeAccessPermission permissionB =

new FileIOPermission(FileIOPermissionAccess.Read, @"C:\temp");

if (permissions.IsSubsetOf(permissionA) {

Console.WriteLine("PermissionB is a subset of PermissionA");

} else {

Console.WriteLine("PermissionB is NOT a subset of PermissionA");

}

}

}

Вывод будет выглядеть следующим образом:

PermissionB is a subset of PermissionA

Существуют ситуации, когда необходимо быть абсолютно уверенным, что вызываемый метод действует в защищенном окружении, где он не может сделать ничего неблагоприятного. Предположим, нужно сделать вызов класса независимого поставщика и при этом точно знать, что он не получит доступ к локальному диску.

Чтобы достичь этого, создается экземпляр полномочия, который не должен получить метод а затем перед вызовом класса вызывается метод Deny():

using System;

using System.IO;

using System.Security;

using System.Security.Permissions;

namespace SecurityApp6 {

class Class1 {

static void Main(string[] args) {

CodeAccessPermission permission =

new FileIOPermission(FileIOPermissionAccess.AllAccess, @"C:\");

permission.Deny();

UntruscworthyClass.Method();

CodeAccessPermission.RevertDeny();

}

}

class UntrustworthyClass {

public static void Method() {

try {

StreamReader din = File.OpenText(@"C:\textfile.txt");

}

catch {

console.WriteLine("Failed to open file");

}

}

}

}

Если выполнить этот код, то будет выведено сообщение Failed to open file, так как ненадежный класс не имеет доступа к локальному диску.

Отметим, что вызов Deny()делается на экземпляре класса полномочия, в то время как вызов RevertDeny()выполняется статически. Причина этого заключается в том, что вызов RevertDeny()возвращает в прежнее состояние все запросы Deny()в рамках текущего стека. Таким образом, если было сделано несколько вызовов Deny(), то необходимо сделать только один последующий вызов RevertDeny().