Чтение онлайн

ЖАНРЫ

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

Ватсон Карли

Шрифт:

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

□ 

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
.

Заявляемые полномочия

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

FileIOPermission
для сохранения данных на диске.

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

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

Приведенный ниже код содержит класс

AuditClass
, реализующий метод
Save
, который получает строку и сохраняет контрольные данные в
C:\audit.txt
. Метод AuditClass заявляет полномочия, которые ему нужны для добавления контрольных строк в файл. Чтобы протестировать это, метод приложения
Main
явно отвергает полномочие файла, которое требуется методу
Audit
:

using System;

using System.IO;

using System.Security;

using System.Security.Permissions;

namespace SecurityApp7 {

 class Class1 {

static void Main(string[] args) {

CodeAccessPermission permission =

new FileIOPermission(FileIOPermissionAccess.Append, @"C:\audit.txt");

permission.Deny;

AuditClass.Save("some data to audit");

CodeAccessPermission.RevertDeny;

}

 }

 class AuditClass {

public static void Save (string value) {

try {

FileIOPermission permission =

new FileIOPermission(FileIOPermissionAccess.Append, @"C:\audit.txt");

permission.Assert;

FileStream stream new FileStream(@"C:\audit.txt", FileMode.Append, FileAccess.Write);

Поделиться с друзьями: