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

Теперь используем эту команду для той же сборки, но через 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, чтобы приложение ухудшалось постепенно, если ему придется выполняться с ограниченными полномочиями. Конструкция приложения должна определять, как приложение будет действовать в такой ситуации, не стоит предполагать, что оно начнет выполняться с такой же политикой системы безопасности, с которой оно разрабатывалось. Например, если приложение не может обратиться к локальному диску, закончится ли оно или должно действовать другим способом?