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

Когда код разбит на группы, можно управлять системой безопасности на более детальном уровне и применять full trust (полное доверие) к значительно меньшей части кода. Отметим, что каждая группа имеет свою метку (такую, как "1.2"). Эти метки генерируются автоматически .NET и могут различаться на разных машинах. Обычно безопасность не контролируется для каждой сборки, она применяется на уровне группы кода.

Представляет интерес вопрос, как действует caspol.exe, когда машина имеет несколько установок .NET. При таких обстоятельствах выполняемая копия caspol.exeбудет изменять политику безопасности только для связанной с ней установкой .NET. Чтобы сохранить простым управление политикой безопасности, вполне можно удалить предыдущие копии .NET при установке последующих версий.

Сборки соответствуют группам кода в зависимости от условий членства. Если вернуться к примеру групп кода и загрузить сборку с web-сайта https://intranet/, она будет соответствовать группам кода таким образом:

Сборка является членом корневой группы кода (All Code); так как она приходит из локальной сети, то она является также членом группы кода Intranet, но вследствие того, что она была загружена со специального сайта https://intranet, то ей также предоставляется FullTrust, что соответствует выполнению без ограничений.

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

caspol.exe -resolvegroup assembly.dll

Выполнение этой команды для сборки на локальном диске создает вывод:

Microsoft (R) .NET Framework CasPol 1.0.2728.0

Copyright (с) Microsoft Corp 1999-2001. All rights reserved.

Level = Enterprise

Code Groups:

1. All code: FullTrust

Level = Machine

Code Groups:

1. All code: Nothing

1.1. Zone — MyComputer: FullTrust

Level = User

Code Groups:

1. All code: FullTrust

Success

Можно заметить, что группы кода перечислены на трех уровнях — Enterprise, Machineи User(Предприятие, Машина и Пользователь). В данный момент сосредоточимся только на уровне Machine, два других более подробно рассмотрим позже. Если вы желаете знать об отношениях между тремя уровнями, то эффективные полномочия, предоставляемые сборке, являются пересечением полномочий из трех уровней. Например, если удалить полномочие FullTrustиз зоны Internet политики на уровне Enterprise, то все полномочия отменяются для кода из зоны Internet и настройки двух других уровней становятся неподходящими.

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

caspol.exe -resolvegroup http://server/assemply.dll

Microsoft (R) .NET Framework CasPol 1.0.2728.0

Copyright (с) Microsoft Corp 1999-2001. All rights reserved.

Level = Enterprise

Code Groups:

1. All code: FullTrust

Level = Machine

Code Groups:

1. All code: Nothing

1.1. Zone — Internet: Internet

1.1.1. All code: Same site Socket and Web.

Level = User

Code Groups:

1. All code: FullTrust

Success

Для сборки в этот раз можно видеть, что пересечение полномочий оставляет полномочия Internetи Same site Socket.

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

После того как сборка сопоставлена с группами кода, CLR просматривает политику системы безопасности для определения предоставляемых сборке полномочий. Это на самом деле похоже на систему безопасности учетных записей пользователей в Windows 2000. Полномочия обычно применяются не к пользователям, а к группам. То же самое справедливо для сборок: полномочия применяются к группам кода, а не к отдельным сборкам, что делает управление политикой системы безопасности в .NET гораздо более простой задачей.

Политика безопасности определяет, какие действия разрешается выполнять сборками в группе кода. Давайте обсудим полномочия доступа к коду, предоставляемые CLR. Нижеследующий список показывает, какие возможности предоставляют полномочия доступа к коду:

□ DirectoryServicesPermission— получение доступа к активному каталогу (Active Directory) с помощью классов System.DirectoryServices.

□ DnsPermission— использование системы имен доменов TCP/IP (DNS).

□ EnvironmentPermission— чтение и запись переменных окружения.

□ EventLogPermission— чтение и запись в журнал событий.

□ FileDialogPermission— доступ к файлам, которые были выбраны пользователем в диалоговом окне Open.

□ FileIOPermission— работа с файлами (чтение, запись и добавление в файл, а также создание и изменение папок).

□ IsolatedStorageFilePermission— доступ к закрытым виртуальным файловым системам.

□ IsolatedStoragePermission— доступ к изолированной памяти; памяти, которая ассоциируется с отдельным пользователем и с некоторыми аспектами идентичности кода, такими как его web-сайт, сигнатура или издатель.

□ MessageQueuePermission— использование очереди сообщений с помощью Microsoft Message Queue.

□ OleDbPermission— доступ к базам данных с помощью OLE DB.

□ PerformanceCounterPermission— использование показателей производительности.

□ PrintingPermission— доступ к печати.

□ ReflectionPermission— доступ к информации о типе с помощью System.Reflection.

□ RegistryPermission— чтение, запись, создание или удаление ключей и значений в реестре.

□ SecurityPermission— выполнение, объявление полномочий, обращение к неуправляемому коду, пропуск проверки, и другие полномочия.

□ ServiceControllerPermission— получение доступа (для выполнения или остановки) к службам Windows.

□ SocketPermission— создание или принятие соединения TCP/IP на транспортном адресе.

□ SQLClientPermission— доступ к базам данных SQL.

□ UIPermission— доступ к интерфейсу пользователя.

□ WebPermission— осуществление или принятие соединения с/из Web.

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

С практической точки зрения настоятельно рекомендуется все попытки использования ресурсов, связанных с полномочиями в этом списке, помещать внутри блоков обработки ошибок try-catch, чтобы приложение ухудшалось постепенно, если ему придется выполняться с ограниченными полномочиями. Конструкция приложения должна определять, как приложение будет действовать в такой ситуации, не стоит предполагать, что оно начнет выполняться с такой же политикой системы безопасности, с которой оно разрабатывалось. Например, если приложение не может обратиться к локальному диску, закончится ли оно или должно действовать другим способом?