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

Пусть имеется сборка, которая была установлена в системе пользователя с полномочиями 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);

// код для записи файла контроля здесь

CodeAccessPermission.RevertAssert();

Console.WriteLine("Data written to audit file");

} catch {

Console.WriteLine("Failed to write data to audit file");

}

}

}

}

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

Как и в случае RevertDeny(), RevertAssert(), являясь статическим методом, отменяет все заявления в текущей среде выполнения. Важно быть очень осторожным при использовании заявлений. Мы явно присваиваем полномочия методу, вызываемому кодом, который вполне может не иметь этих полномочий. Например, в коде с контролем, даже если политика безопасности диктует, что установленные приложения не могут делать записей на локальный диск, данное приложение выполнит это, если функции контроля были установлены с полномочиями Full Trust.

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

Вот два случая, когда может понадобиться создание своих собственных полномочий доступа к коду:

□ Защита ресурса, еще не защищенного с помощью Framework. Например, разработано приложение .NET для автоматизации, которое реализуется с помощью встроенного аппаратного устройства. Создавая свой собственный код полномочий доступа, можно получить достаточно развитый уровень управления доступом для данного устройства автоматизации.

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