Сообщений 5 Оценка 395 Оценить |
Идентификаторы безопасности Управление доступом Язык SDDL Флаги DACL и SACL ЗаключениеФормат ACE Стандартные SID Примеры SDDL-выражений Использование SDDL в .NET Framework 2 Ссылки |
Архитектуре безопасности в NET Framework 1.x не хватало объектной модели программирования контроля доступа к файлам, реестру, системным службам. Проще говоря, до 2-й версии .NET не поддерживал списки контроля доступа (ACL – Access Control List).
Раньше для реализации поддержки ACL надо было использовать Authorization Manager API. В .NET 2.0 это можно сделать с помощью пространства имён System.Security.AccessControl. Эта статья посвящена описанию использования данного пространства имён для реализации контроля доступа средствами .NET Framework 2.0 BETA.
Чтобы ввести читателя в курс дела, начнём с теоретического введения и опишем основные понятия, на которых построена политика управления доступом.
Для идентификации пользователей Windows использует не их имена, которые могут оказаться и не уникальными, а идентификаторы безопасности (Security Identifier – SID). Идентификатор безопасности – это уникальное значение переменной длины, которое присваивается пользователям, доменам и членам доменов. Каждый идентификатор безопасности состоит из версии SID, 48-битного кода агента идентификатора и переменного числа 32-битных субагентов, или, как их ещё называют, относительных идентификаторов (Relative Identifier – RID). Код агента идентификатора выдаётся операционной системой: для NT-систем его значение – 5. Субагенты определяют информацию о домене, а последний RID – код пользователя. Таким образом, RID – это средство создания уникального SID на основе базового SID. Поскольку длина SID достаточно велика, Windows старается генерировать истинно случайное значение.
В текстовом представлении формат SID выглядит следующим образом:
S-R-I-S-S… |
В текстовой форме все SID начинаются с префикса “S”, далее следует номер версии (R), код агента идентификатора (I) и группа RID (S).
Чтобы узнать SID пользователя, можно воспользоваться утилитой GetSID, входящей в состав набора ресурсов Windows 2000. Её можно загрузить по адресу http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/getsid-o.asp. Эта утилита была, в первую очередь, создана для сравнения SID разных пользователей, но может быть с тем же успехом использована для получения SID конкретного пользователя. Ниже приведён синтаксис её использования:
C:\>getsid Usage: getsid \\server1 account \\server2 account |
Как видно, для её работы нужно указать 2 домена и соответствующие учётные записи в этих доменах. Рассмотрим пример:
C:\>getsid \\bigdragon B@K$ \\bigdragon AlBa The SID for account BIGDRAGON\B@K$ does not match account BIGDRAGON\AlBa The SID for account BIGDRAGON\B@K$ is S-1-5-21-220523388-854245398-1343024091-1003 The SID for account BIGDRAGON\AlBa is S-1-5-21-220523388-854245398-1343024091-1004 |
Таким образом, SID пользователя B@k$ на машине автора представлен строкой S-1-5-21-220523388-854245398-1343024091-1003, а SID AlBa – S-1-5-21-220523388-854245398-1343024091-1004. Оба идентификатора начинаются с префикса “S”, затем следует версия SID – 1, код агента идентификатора – 5 (этот код характерен для всех NT-систем), далее идут коды 4-х субагентов, а в конце – RID, которые и отличаются у пользователей B@k$ и AlBa (в коде они выделены).
Все RID пользователей начинаются с 1000, увеличиваясь на 1 для каждой новой учётной записи. Таким образом, если запросить SID пользователя HelpAssistant, то его RID будет 1000:
C:\>getsid \\bigdragon HelpAssistant \\bigdragon HelpAssistant The SID for account BIGDRAGON\HelpAssistant matches account BIGDRAGON\HelpAssist ant The SID for account BIGDRAGON\HelpAssistant is S-1-5-21-220523388-854245398-1343024091-1000 The SID for account BIGDRAGON\HelpAssistant is S-1-5-21-220523388-854245398-1343024091-1000 |
Система также поддерживает стандартные RID для некоторых учётных записей, например, RID для администратора – 500, а для гостя – 501:
C:\>getsid \\bigdragon Administrator \\bigdragon Guest The SID for account BIGDRAGON\Administrator does not match account BIGDRAGON\Gue st The SID for account BIGDRAGON\Administrator is S-1-5-21-220523388-854245398-1343024091-500 The SID for account BIGDRAGON\Guest is S-1-5-21-220523388-854245398-1343024091-501 |
Ниже приведена таблица универсальных SID, которые не зависят от системы и всегда имеют одно и то же значение (они будут необходимы при настройке ACL):
Универсальный SID | Описание |
---|---|
Null SID (S-1-0-0) | Пустая группа. Часто используется, если SID не известен. |
World (S-1-1-0) | Все пользователи. |
Local (S-1-2-0) | Пользователи, прошедшие локальную аутентификацию. |
Creator Owner ID (S-1-3-0) | SID создателя объекта. |
Creator Group ID (S-1-3-1) | SID группы создателя объекта. |
Для работы с SID .NET Framework 2.0 предоставляет класс SecurityIdentifier пространства имён System.Security.Principal. Конструкторы этого класса позволяют задать SID в виде строки, массива байтов или комбинации перечисления WellKnownSidType и SID домена. С помощью этого класса можно узнать SID домена, которому принадлежит указанный идентификатор безопасности; является ли SID универсальным; является ли он идентификатором учётной записи и т.п.
Чтобы узнать SID учётной записи, от имени которой запущено приложение, нужно дополнительно воспользоваться классом WindowsIdentity того же пространства имён, как показано в листинге 1:
Листинг 1. GetSID – получение SID пользователя, от имени которого запущено приложение.using System; using System.Security.Principal; namespace GetSID { class Program { staticvoid Main(string[] args) { WindowsIdentity wid = WindowsIdentity.GetCurrent(); Console.WriteLine(wid.Name + " SID is {0}", wid.User.Value); Console.Read(); } } } |
Статический метод GetCurrent класса WindowsIdentity возвращает описатель идентификатора аутентифицированного пользователя, от имени которого запущено приложение. Свойство User возвращает ссылку на класс SecurityIdentifier, идентифицирующий пользователя.
Запуск приложения от имени пользователя B@K$ вернёт следующий результат:
BIGDRAGON\B@k$ SID is S-1-5-21-220523388-854245398-1343024091-1003 |
Если запустить его от имени администратора, то будет выведено соответствующее сообщение:
BIGDRAGON\Administrator SID is S-1-5-21-220523388-854245398-1343024091-500 |
Управление политикой доступа к ресурсам осуществляется с помощью списков контроля доступа (ACL – Access Control List). Списки контроля доступа делятся на 2 группы:
ACL управляют доступом к самым разным объектам: файлам и папкам, локальным и удалённым принтерам, разделам реестра, именованным каналам, сетевым ресурсам, объектам синхронизации (семафоры, мьютексы, события, таймеры), объектам-заданиям, общей памяти, объектам каталога Active Directory, системным службам. Все эти возможности поддерживаются лишь в NT системах (Windows NT, 2000, XP, 2003).
Всякий ACL – это набор записей контроля доступа (ACE – Access Control Entry), каждая из которых состоит из SID (учётной записи, пользовательской группы или машины), маски доступа, определяющей права доступа, флагов, описывающих тип ACE (таблица 2), и набора флагов, указывающих на способность объектов или контейнеров-потомков наследовать политику безопасности данной ACL.
Тип ACE | Описание |
---|---|
Запрещающий ACE | Используется в DACL для запрета доступа к ресурсу. |
Разрешающий ACE | Используется в DACL для разрешения доступа к ресурсу. |
Системный ACE аудита | Используется в SACL для создания записей аудита. |
Все ресурсы, поддерживающие политику ACL, делятся на 2 группы: объекты и контейнеры. Объекты – это объекты службы каталогов (Directory Service), они идентифицируются по GUID, а контейнеры – это все остальные ресурсы, опознать которые можно по имени.
Все списки контроля доступа поддерживают наследование от родителей, которые, как уже было сказано, могут быть представлены в форме объектов или контейнеров, соответственно, объекты относятся к ресурсам служб каталогов, а контейнеры – ко всем остальным типам ресурсов. В таблице 3 представлены флаги наследования.
Флаг наследования | Описание |
---|---|
OBJECT_INHERIT_ACE | Потомки будут наследовать ACE только у объектов. |
CONTAINER_INHERIT_ACE | Потомки будут наследовать ACE только у контейнеров. |
CONTAINER_INHERIT_ACE и OBJECT_INHERIT_ACE | Потомки будут наследовать оба типа ACE. |
Пустое значение | Потомки не будут наследовать ACE. |
ПРЕДУПРЕЖДЕНИЕ Если DACL не содержит никаких ACE, значит, доступ закрыт для всех пользователей, а если DACL = NULL, то доступ полностью открыт, поэтому важно не использовать не определённые DACL. |
Очень важно соблюдать порядок ACE в избирательных списках: запрещающая ACE всегда должна стоять перед разрешающей. Если пренебречь этим правилом, то некоторым учётным записям будет разрешено то, что им должно быть запрещено.
Программирование ACL в .NET Framework 2 осуществляется с помощью классов пространства имён System.Security.AccessControl. Это пространство имён содержит целую иерархию наследуемых классов, таким образом, контроль доступа ко всем видам ресурсов осуществляется по одинаковой схеме с незначительными отличиями, характерными для соответствующих ресурсов.
System.Object System.Security.AccessControl.ObjectSecurity System.Security.AccessControl.DirectoryObjectSecurity System.DirectoryServices.ActiveDirectorySecurity System.Security.AccessControl.CommonObjectSecurity Microsoft.Iis.Metabase.MetaKeySecurity System.Security.AccessControl.NativeObjectSecurity System.Security.AccessControl.EventWaitHandleSecurity System.Security.AccessControl.FileSystemSecurity System.Security.AccessControl.DirectorySecurity System.Security.AccessControl.FileSecurity System.Security.AccessControl.MutexSecurity System.Security.AccessControl.RegistrySecurity System.Security.AccessControl.SemaphoreSecurity |
Предположим, что нужно установить на файл C:\Temp\acl.txt DACL следующего формата:
Рисунок 1. Схема DACL.
Для демонстрации создадим новый проект консольного приложения и воспользуемся кодом из листинга 2:
Листинг 2. FileACL – установка DACL для файла.using System; using System.Security.AccessControl; using System.Security.Principal;using System.IO; namespace FileACL { class Program { staticvoid Main(string[] args) { conststring FILE_NAME = @"C:\Temp\acl.txt"; FileInfo fi = new FileInfo(FILE_NAME); FileSecurity fs = new FileSecurity(FILE_NAME, AccessControlSections.All); fs.SetAccessRule(new FileSystemAccessRule("BIGDRAGON\\AlBa", FileSystemRights.FullControl, AccessControlType.Deny)); fs.SetAccessRule(new FileSystemAccessRule("BUILTIN\\Administrators", FileSystemRights.FullControl, AccessControlType.Allow)); fs.SetAccessRule(new FileSystemAccessRule("BIGDRAGON\\HelpAssistant", FileSystemRights.ReadData | FileSystemRights.WriteData | FileSystemRights.AppendData, AccessControlType.Allow)); fs.SetAccessRule(new FileSystemAccessRule("BUILTIN\\Guests", FileSystemRights.ReadData, AccessControlType.Allow)); fi.SetAccessControl(fs); } } } |
ПРЕДУПРЕЖДЕНИЕ У читателя вряд ли окажется на машине учётная запись AlBa, поэтому некоторые учётные записи лучше заменить теми, которые есть на вашей машине. При этом нужно будет заменить и имя компьютера, если, конечно, ваша машина не называется BIGDRAGON. |
Управление политикой доступа к файлу производится с помощью класса System.Security.AccessControl.FileSecurity. С его помощью можно добавлять, удалять, изменять права доступа и аудита к заданному файлу.
Во второй строке обработчика главной функции создаётся экземпляр класса System.IO.FileInfo, который ссылается на заданный файл и устанавливает политику безопасности. В следующей строке создаётся экземпляр класса FileSecurity: в качестве аргумента он принимает имя обрабатываемого файла и разделы, с которыми будет вестись работа (как правило, оставляют значение All). Далее добавляются правила доступа путём вызова метода SetAccessRule класса FileSecurity. Этот метод принимает один единственный аргумент типа FileSystemAccessRule, который и описывает правило доступа. После формирования объекта типа FileSecurity его передают в качестве аргумента методу SetAccessControl класса FileInfo.
Чтобы проверить результат, сперва выполните программу, а затем найдите обрабатываемый файл (в примере это был C:\Temp\acl.txt), откройте окно свойств и перейдите на закладку безопасности. Далее щёлкните кнопку Дополнительно и в появившемся окне (рисунок 2) увидите информацию по правам каждого пользователя.
Рисунок 2. Права доступа для HelpAssistant.
В листинге 1 DACL определён таким образом, что пользователь AlBa не имеет никаких прав на доступ к файлу. Чтобы проверить результат, выполните следующую команду:
C:\>runas /user:Alba "notepad C:\Temp\acl.txt" |
В результате должно появиться сообщение об отказе в доступе.
Если права пользователя уже определены, но нужно добавить ещё одно, необходимо вызвать метод AddAccessRule. К примеру, добавим HelpAssistant’у возможность просматривать значения атрибутов файла:
fs.AddAccessRule(new FileSystemAccessRule("BIGDRAGON\\HelpAssistant", FileSystemRights.ReadAttributes, AccessControlType.Allow)); |
ПРИМЕЧАНИЕ Таким образом, метод SetAccessRule заменяет ACE, а AddAccessRule – добавляет новый. |
Для удаления какого-то одного разрешения (ACE) предназначен метод RemoveAccessRule:
fs.RemoveAccessRule(new FileSystemAccessRule("BIGDRAGON\\HelpAssistant", FileSystemRights.ReadAttributes, AccessControlType.Allow)); |
Если нужно удалить сразу все правила для какой-то конкретной учётной записи (т. е. полностью вычеркнуть учётную запись из ACL), то необходимо вызвать метод PurgeAccessRules. Прототип этого метода выглядит так:
public void PurgeAccessRules(System.Security.Principal.IdentityReference identity); |
Как видно, он принимает ссылку на объект IdentityReference. IdentityReference – это абстрактный класс, который наследуется классами NTAccount и SecurityIdentifier (все три класса находятся в пространстве имён System.Security.Principal). Соответственно с помощью класса NTAccount можно указать имя учётной записи, а через SecurityIdentifier – SID:
fs.PurgeAccessRules(new NTAccount("BIGDRAGON\\HelpAssistant")); |
или
fs.PurgeAccessRules( new SecurityIdentifier("S-1-5-21-220523388-854245398-1343024091-1000")); |
ПРЕДУПРЕЖДЕНИЕ Для работы всех примеров, в которых используются SID, нужно переопределить SID в соответствии с SID вашей машины, поскольку они уникальны для каждого компьютера. |
После выполнения этого кода все записи, описывающие правила для HelpAssistant’а будут удалены (см. рисунок 3).
Рисунок 3. HelpAssistant’а больше нет в списке.
С помощью методов SetOwner и SetGroup можно установить владельца и основную группу соответственно. Эти методы так же, как и PurgeAccessRule, принимают в качестве аргумента SID или имя учётной записи:
public void SetOwner(System.Security.Principal.IdentityReference identity); publicvoid SetGroup(System.Security.Principal.IdentityReference identity); |
Аудит настраивается аналогичным образом, с тем лишь отличием, что в именах соответствующих методов вместо Access пишется Audit. Например, конфигурирование SACL для того, чтобы при чтении данных HelpAssistant’ом в журнал добавлялась запись аудита, будет выглядеть следующим образом:
fs.AddAuditRule(new FileSystemAuditRule("BIGDRAGON\\HelpAssistant", FileSystemRights.ReadData, AuditFlags.Success)); |
Чтобы убедиться в том, что аудит чтения данных HelpAssistant’ом действительно установлен, нужно открыть окно свойств файла, перейти на закладку Безопасность, нажать кнопку Дополнительно и в появившемся окне выбрать закладку Аудит (рисунок 4).
Рисунок 4. – Окно параметров аудита.
Чтобы увидеть результат аудита, нужно открыть файл под учётной записью HelpAssistant. Это можно сделать следующей командой:
C:\>runas /user:HelpAssistant "notepad C:\temp\acl.txt" |
После открытия файла его можно закрыть, а затем нужно открыть консоль просмотра событий и перейти в журнал Безопасность (рисунок 5)
Рисунок 5. Результат аудита.
СОВЕТ Если журнал аудита пуст, значит, на машине отключен аудит обращения к объектам. Для его активации нужно открыть консоль локальной политики, перейти в раздел Конфигурация компьютера|Конфигурация Windows|Параметры безопасности|Локальные политики|Политика аудита. В этом разделе необходимо задать параметру Аудит доступа к объектам значение Успех (рисунок 6). |
Рисунок 6. Активация аудита успешного доступа к объектам.
Защита реестра осуществляется так же, как и защита файлов, но с тем отличием, что используются объекты RegistrySecurity (описатель безопасности реестра) и RegistryKey (класс для работы с разделами реестра).
К примеру, нужно создать новый раздел реестра и назначить такие права доступа, чтобы HelpAssistant мог читать и изменять данные, AlBa не имел доступа, а администраторам был предоставлен полный доступ. Листинг 3 содержит код выполняющий эти действия.
Листинг 3. RegistryACL – создание DACL для раздела реестра.using System; using Microsoft.Win32; // Содержит классы для работы с реестромusing System.Security.AccessControl; namespace RegistryACL { class Program { staticvoid Main(string[] args) { RegistryKey reg = Registry.LocalMachine.CreateSubKey("Software"); RegistrySecurity rs = new RegistrySecurity(); rs.SetAccessRule(new RegistryAccessRule("BIGDRAGON\\AlBa", RegistryRights.FullControl, AccessControlType.Deny)); rs.SetAccessRule(new RegistryAccessRule("BUILTIN\\Administrators", RegistryRights.FullControl, AccessControlType.Allow)); rs.SetAccessRule(new RegistryAccessRule("BIGDRAGON\\HelpAssistant", RegistryRights.ReadKey | RegistryRights.WriteKey, AccessControlType.Allow)); // Отменяет наследование параметров от родителя, но передаёт свои значения потомкам rs.SetAccessRuleProtection(true, true); reg = reg.CreateSubKey("ACLtest"); reg.SetAccessControl(rs); reg.Close(); } } } |
В листинге 3 сначала открывается раздел реестра HKLM\Software, затем создаётся новый экземпляр описателя безопасности раздела реестра. После этого следуют 3 конструкции, устанавливающие соответствующие права доступа для 3-х учётных записей. Следующая строка:
rs.SetAccessRuleProtection(true, true); |
является необязательной, но удобна тем, что после её выполнения в DACL не попадут записи от родителя, т. е. от раздела HKLM\Software. Первый параметр метода SetAccessRuleProtection активирует/деактивирует наследование параметров от родителя, а второй – разрешает/запрещает передавать параметры потомкам.
В следующих 2-х строках:
reg = reg.CreateSubKey("ACLtest");
reg.SetAccessControl(rs);
|
открывается (или создаётся, если он ещё не существует) раздел реестра HKLM\Software\ACLtest и устанавливается DACL для него путём вызова метода SetAccessControl. Эти 2 строки можно заменить одной:
reg.CreateSubKey("ACLtest", rs);
|
но в этом случае код будет действовать только при создании раздела, но не при изменении существующего.
Чтобы убедиться в успешности выполнения кода из листинга 3, просмотрите разрешения на раздел реестра HKLM\Software\ACLtest (рисунок 7) или выполните следующую команду:
runas /user:AlBa regedit |
и перейдите к разделу HKLM\Software\ACLtest. Если всё было выполнено правильно, то система вас не пропустит.
Рисунок 7. Разрешения доступа к разделу реестра HKLM\Software\ACLtest.
Давным-давно, в далёкой-далёкой галактике под названием NT 4 разработчикам жилось тяжело, потому что процесс программирования ACL был весьма трудоёмкой задачей. Тогда повстанческие силы под предводительством атамана Билла Гейтса решили облегчить им эту задачу, разработав язык определения дескриптора безопасности SDDL – Security Descriptor Definition Language.
SDDL – это язык, представляющий дескриптор безопасности в текстовой, понятной человеку форме. С помощью SDDL можно описать владельца объекта, основную группу, DACL и SACL. Синтаксис SDDL имеет следующую форму:
O:sid_владельца G:sid_основной_группы D:флаги_DACL(ACE 1)(ACE 2)…(ACE n) S:флаги_SACL(ACE 1)(ACE 2)…(ACE n) |
Эти четыре конструкции могут существовать вместе или по отдельности, и различаются по префиксам:
DACL- и SACL-флаги используют одни и те же значения и применяются для управления наследованием параметров. Список допустимых значений приведен в таблице 4.
Обозначение | Название флага | Описание |
---|---|---|
P | SE_DACL_PROTECTEDSE_SACL_PROTECTED | Запрещает наследование параметров от родителя. |
AR | SE_DACL_AUTO_INHERIT_REQSE_SACL_AUTO_INHERIT_REQ | Запрашивает у поставщика объекта наследование ACL всеми дочерними объектами и устанавливает флаг SE_DACL_AUTO_INHERITED (SE_SACL_AUTO_INHERITED) у объекта и его потомков. |
AI | SE_DACL_AUTO_INHERITEDSE_SACL_AUTO_INHERITED | Активирует автоматическое наследование всех ACE-потомками. |
ACE записи содержат всю информацию, описывающую права доступа и аудита для каждой учётной записи. В языке SDDL они имеют следующий формат:
(тип_ACE;флаги_ACE;права;GUID_объекта;GUID_наследуемого_объекта;SID) |
Поддерживаемые типы ACE перечислены в таблице 5.
Обозначение | Название типа | Описание |
---|---|---|
A | ACCESS_ALLOWED_ACE_TYPE | Доступ к контейнеру разрешён |
D | ACCESS_DENIED_ACE_TYPE | Доступ к контейнеру запрещён |
OA | OBJECT_ACCESS_ALLOWED_ACE_TYPE | Доступ к объекту разрешен |
OD | OBJECT_ACCESS_DENIED_ACE_TYPE | Доступ к объекту запрещён |
AU | AUDIT_ACE_TYPE | ACE аудита контейнера |
AL | ALARM_ACE_TYPE | ACE тревоги контейнера |
OU | OBJECT_AUDIT_ACE_TYPE | ACE аудита объекта |
OL | OBJECT_ALARM_ACE_TYPE | ACE тревоги объекта |
Обозначение | Название флага | Описание |
---|---|---|
CI | CONTAINER_INHERIT_ACE | Потомки-контейнеры будут наследовать эту ACE |
OI | OBJECT_INHERIT_ACE | Потомки-объекты будут наследовать эту ACE |
NP | NO_PROPAGATE_ACE | Запрещает ACE быть наследуемым |
IO | INHERIT_ONLY_ACE | Сам ACE бездействует и хранит значения для потомков, которые их наследуют и реализуют |
ID | INHERITED_ACE | ACE наследует параметры у родителя (не зависимо от общих установок ACL) |
SA | AUDIT_SUCCESS_ACE | Добавлять запись в журнал при успехе операции (используется в SACL) |
FA | AUDIT_FAILED | Добавлять запись в журнал при провале операции (используется в SACL) |
Обозначение | Название права | Описание |
---|---|---|
Основные права доступа, поддерживаемые всеми объектами | ||
GA | GENERIC_ALL | Полный доступ |
GR | GENERIC_READ | Чтение |
GW | GENERIC_WRITE | Запись |
GX | GENERIC_EXECUTE | Выполнение |
Стандартные права доступа | ||
RC | READ_CONTROL | Чтение данных ACL |
SD | DELETE | Удаление объекта |
WD | WRITE_DAC | Изменение DACL |
WO | WRITE_OWNER | Установка владельца |
Права доступа к объектам Active Directory | ||
RP | ADS_RIGHT_DS_ READ_PROP | Чтение свойств объекта AD |
WP | ADS_RIGHT_DS_ WRITE_PROP | Запись свойств объекта AD |
CC | ADS_RIGHT_DS_ CREATE_CHILD | Создание дочернего объекта AD |
DC | ADS_RIGHT_DS_ DELETE_CHILD | Удаление дочернего объекта AD |
LC | ADS_RIGHT_DS_ LIST | Просмотр списка дочерних объектов AD |
SW | ADS_RIGHT_DS_ SELF | Контролируемая запись |
LO | ADS_RIGHT_DS_ LIST_OBJECT | Просмотр информации об объекте |
DT | ADS_RIGHT_DS_ DELETE_TREE | Удаление целого дерева объектов AD |
CR | ADS_RIGHT_DS_ CONTROL_ACCESS | Выполнение операций, требующих расширенного контроля |
Права доступа к файлам | ||
FA | FILE_ALL_ACCESS | Полный доступ к файлу |
FR | FILE_GENERIC_READ | Чтение файла |
FW | FILE_ GENERIC_WRITE | Запись файла |
FX | FILE_ GENERIC_EXECUTE | Выполнение файла |
Права доступа к реестру | ||
KA | KEY_ALL_ACCESS | Полный доступ к реестру |
KR | KEY_READ | Чтение реестра |
KW | KEY_WRITE | Запись в реестр |
KX | KEY_EXECUTE | Выполнение реестра |
В поле GUID_объекта при необходимости (в случае работы с объектами Active Directory) подставляется GUID соответствующего объекта. Поле GUID_наследуемого_объекта содержит GUID типа объекта, которому должны отвечать все объекты-потомки.
Поля SID в строках SDDL, описывающих владельца или основную группу, могут содержать либо SID учётной записи, либо одно из стандартных значений, которые перечислены в таблице 8.
Псевдоним | Описание |
---|---|
AO | Account operators – операторы учётных записей |
AN | Anonymous – анонимные пользователи |
AU | Authenticated Users – пользователи, прошедшие аутентификацию |
BA | Builtin Administrators – встроенная группа администраторов |
BG | Builtin Guests – встроенная группа гостей |
BO | Backup Operators – операторы архивации |
BU | Builtin Users – встроенная группа пользователей |
CA | Certificate Server Administrators – администраторы сервера сертификатов |
CG | Creator Group – группа, в которой находится создатель ресурса |
CO | Creator Owner – создатель-владелец |
DA | Domain Administrators – администраторы домена |
DC | Domain Computers – компьютеры домена |
DD | Domain Controllers – контроллеры домена |
DG | Domain Guests – гости домена |
DU | Domain Users – пользователи домена |
EA | Enterprise Administrators – администраторы предприятия |
ED | Enterprise Domain Controllers – контроллеры домена предприятия |
WD | World (Everyone) – все |
PA | Group Policy Administrators – администраторы групповой политики |
IU | Interactive Users – интерактивные пользователи, т. е. все пользователи, вошедшие в систему |
LA | Local Administrator – администратор локального компьютера |
LG | Local Guest – гость локального компьютера |
LS | Local Service Account – локальная учётная запись системных служб |
SY | Local System – локальная учётная запись системы |
NU | Network Users – сетевые пользователи |
NO | Network Configuration Operators – операторы конфигурации сети |
NS | Network Service Account – учётная запись сетевой службы |
PO | Printer Operators – операторы печати |
PS | Principal Self |
PU | Power Users – опытные пользователи |
RS | RAS Servers Group – группа, представляющая серверы RAS (Remote Authentication Service) и IAS (Internet Authentication Service) |
RD | Remote Desktop – удалённый рабочий стол |
RE | Replicator – репликатор (копирование базы данных безопасности с основного домена на аварийный) |
RC | Restricted Code – учётная запись, работающая с ограниченным маркером доступа |
SA | Schema Administrators – администраторы схем |
SO | Server Operators – операторы серверов |
SU | Service Logon User – пользователи, вошедшие в систему от имени системной службы |
ПРЕДУПРЕЖДЕНИЕ Все перечисленные псевдонимы SID применимы только в языке SDDL |
Теперь самое время увидеть, на что похожи строки SDDL в деле. Вернемся к первому примеру статьи. SDDL строка для этого DACL будет иметь следующий вид:
D:P(D;OICI;GA;;;S-1-5-21-220523388-854245398-1343024091-1004)(A;OICI;GA;;;BA)(A;OICI;GRGW;;;S-1-5-21-220523388-854245398-1343024091-1000)(A;OICI;GR;;;BG) |
Рассмотрим эту запись:
ПРИМЕЧАНИЕ Параметры доступа GR, GW и GA можно заменить параметрами, характерными только для файлов (FR, FW и FA), но никаких отличий в работе это не повлечет. |
Во всех ACE использовались флаги OICI, активирующие наследование потомками параметров объектов и контейнеров.
Если к этой конструкции нужно добавить аудит успешного чтения данных HelpAssistant’ом, то в конец строки можно подставить следующее выражение:
S:P(AU;SA;GR;;;S-1-5-21-220523388-854245398-1343024091-1000) |
Ниже приведены отличия кода SACL от кода DACL:
Для демонстрации работы SDDL создадим новый проект и воспользуемся кодом из листинга 4:
Листинг 4. SDDL – Настройка DACL и SACL файла с помощью SDDL выражения.using System; using System.IO; using System.Security.AccessControl; namespace SDDL { class Program { staticvoid Main(string[] args) { conststring FILE_NAME = @"C:\Temp\acl.txt"; FileInfo fi = new FileInfo(FILE_NAME); FileSecurity fs = new FileSecurity( FILE_NAME, AccessControlSections.All); fs.SetSecurityDescriptorSddlForm("D:P" + "(D;OICI;GA;;;S-1-5-21-220523388-854245398-1343024091-1004)" + "(A;OICI;GA;;;BA)" + + "(A;OICI;GRGW;;;S-1-5-21-220523388-854245398-1343024091-1000)" + "(A;OICI;GR;;;BG)" + "S:P" + "(AU;SA;GR;;;S-1-5-21-220523388-854245398-1343024091-1000)"); fi.SetAccessControl(fs); } } } |
Если сравнить листинги 1 и 4, то очевидно, что последний значительно короче, но его использование требует знание языка SDDL.
Для получения из дескриптора безопасности строки SDDL нужно вызвать метод GetSecurityDescriptorSddlForm, который доступен для всех объектов, поддерживающих ACL. В листинге 5 показано, как получить SDDL-строку с параметрами ACL для файла C:\Temp\acl.txt.
Листинг 5. GetSDDL – Получение строки SDDL с параметрами ACL файла C:\Temp\acl.txt.using System; using System.IO; using System.Security.AccessControl; namespace SDDL { class Program { staticvoid Main(string[] args) { FileInfo fi = new FileInfo(@"C:\Temp\acl.txt"); Console.WriteLine(fi.GetAccessControl().GetSecurityDescriptorSddlForm( AccessControlSections.All)); } } } |
Если выполнить этот код сразу после кода из листинга 4, то будет очевидно, что система перестроила ACL под свой формат:
O:S-1-5-21-220523388-854245398-1343024091-1003G:S-1-5-21-220523388-854245398-1343024091-513D:PAI(D;;FA;;;S-1-5-21-220523388-854245398-1343024091-1004)(A;;FA;;;BA)(A;;FR;;;BG)(A;;0x12019f;;;S-1-5-21-220523388-854245398-1343024091-1000) |
Как видно, в строке SDDL появилась информация о владельце, основной группе, изменилась форма записи ACE, исчезли списки SACL.
На этом завершается обзор возможностей контроля доступа в .NET Framework 2. В следующей части статьи вы узнаете о новшествах в криптографии.
Сообщений 5 Оценка 395 Оценить |