Что такое дескриптор безопасности windows

Обновлено: 08.07.2024

Атрибуты защиты объекта Windows описываются специальной структурой данных, называемой дескриптором защиты (security descriptor). Любой объект Windows может иметь дескриптор защиты. Дескриптор защиты содержит следующую информацию:

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

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

Флаги дескриптора защиты представляют собой 32-битную маску, отдельные биты которой имеют следующий смысл:

Биты 8 и 9 имеют смысл только для объектов-контейнеров (дисковые и объектовые директории, ключи реестра и т. п.).

Когда субъект доступа открывает объект, субъект должен сообщить операционной системе права, необходимые ему для работы с данным объектом. Эти права кодируются с помощью битовой маски, каждый бит которой соответствует некоторому праву доступа. Например, если пользователь открывает объект типа «файл», второй параметр системной функции CreateFile является битовой маской, описывающей запрашиваемые права доступа к объекту. Если субъект открывает файл для чтения и записи, эта маска доступа должна быть равна FILE.READJDATA FILE.WRITE.DATA [ FILE.APPEND.DATA (или GENERIC.READ | GENERIC.WRITE).

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

Элементы списка дискреционного управления доступом называются элементами управления доступом (access control entries, АСЕ). Каждый элемент управления доступом разрешает или запрещает некоторому субъекту определенные права на доступ к объекту. В состав элемента управления доступом могут входить следующие основные поля:

• тип элемента: разрешающий, запрещающий или регистрирующий;
• идентификатор субъекта;
• битовая маска прав доступа;
• флаги;
• GUID1 (необязательное поле);
• GUID2 (необязательное поле).

В DACL объекта могут присутствовать только разрешающие и запрещающие АСЕ, разрешающие АСЕ разрешают указанным субъектам доступ к объекту по указанным правам, запрещающие — запрещают. В SACL объекта могут присутствовать только регистрирующие АСЕ.

Начиная с Windows NT 4.0, дескрипторы защиты объектов, помимо обычных элементов контроля доступа, могут содержать так называемые compound АСЕ. В отличие от других АСЕ, compound АСЕ содержит два идентификатора субъектов, один из которых должен присутствовать в маркере доступа потока, обращающегося к объекту, а другой — в маркере доступа процесса, в контексте которого выполняется данный поток. Другими словами, compound АСЕ позволяет описать особые права доступа для любой заданной пары пользователь-клиент + пользователь-сервер. Этот механизм крайне неудобен для практического использования и, насколько известно автору, никогда никем не используется.

Поля GUID1 и GUID2 могут присутствовать только в АСЕ, относящихся к объектам активного каталога доменов Windows. Объекты активного каталога обычно представляют собой совокупности подобъектов [2] — небольших записей, содержащих текстовые строки, числовые значения или короткие бинарные данные. Поскольку подобъекты, как правило, занимают всего несколько байт памяти, отдельные дескрипторы защиты подобъектам не назначаются, вместо этого объекту, содержащему подобъекты, назначается один общий дескриптор защиты, регламентирующий доступ ко всем подобъектам объекта.

Подобъекты объекта активного каталога могут содержать в себе другие подобъекты, подобно тому, как дисковые и объектовые директории могут содержать в себе файлы и поддиректории. Для объекта поддерживается до 5 уровней вложенности подобъектов, идентифицируемых числовыми значениями от 0 до 4:

0 — сам объект;
1 — наборы свойств (property sets);
2 — свойства (properties);
3-4 — в современных версиях Windows не используются.

Для объектов активного каталога определены два специфичных права доступа:

• ADS.RIGHT.DS.READ.PROP — читать подобъект;
• ADS-RIGHT-DS-WRITE.PROP — изменять подобъект.

Также для отдельных типов объектов активного каталога могут вводиться расширенные (extended) права доступа, каждое такое право идентифицируется с помощью GUID. Например, для объекта DMD (directory management domain) определены следующие расширенные права:

• получить обновления базы данных с некоторого сервера;
• синхронизировать базу данных с некоторым сервером;
• поработать с топологией репликаций;
• обновить кэш схемы.

Обычные элементы управления доступом, примененные к объекту активного каталога, управляют доступом ко всему объекту в целом и, в частности, ко всем его подобъектам.

Для объектов активного каталога определены три особых типа элементов управления доступом, не поддерживаемых для других объектов операционной системы:

• объектно-специфический разрешающий;
• объектно-специфический запрещающий;
• объектно-специфический регистрирующий.

Элементы управления доступом, относящиеся к перечисленным типам, отличаются от других элементов управления доступом наличием полей GUID1 и GUID2. Поле GUID1 может содержать:

• тип подобъекта — в этом случае АСЕ регулирует доступ ко всем подобъектам данного объекта, принадлежащим к указанному типу;
• подобъект — АСЕ регулирует доступ к данному подобъекту и подобъектам, вложенным в него, если таковые имеются;
• расширенное право доступа — АСЕ регулирует доступ к объекту по данному праву, битовая маска с правами доступа игнорируется;

Поле GUID2 может присутствовать только в объектах-контейнерах активного каталога. Это поле содержит тип дочерних объектов, которые должны наследовать данный АСЕ. Если GUID2 не указан, АСЕ наследуется дочерними объектами любых типов.

Объекты, к которым могут получать доступ процессы, имеют специальный атрибут – дескриптор защиты (security descriptor), содержащий информацию обо всех пользователях, которым разрешен или запрещен доступ к объекту.

Структура данных SECURITY_DESCRIPTOR, представляющая дескриптор защиты, описана в файле public\sdk\inc\ntseapi.h (строка 1173) и включает следующие основные поля:

Owner – SID владельца;
Dacl – список управления избирательным доступом;
Sacl – системный список управления доступом.

Списки управления доступом (ACL, Access-Control List) в системе представлены заголовком (ACL Header) и последовательностью элементов списка (ACE, Access-Control Entry) (рис.13.3).

Рис. 13.3. Внутреннее представление списка управления доступом ACL

Заголовок списка описывается структурой ACL (файл public\sdk\inc\ntseapi.h, строка 658), в которой хранятся количество элементов списка ACL (поле AceCount) и общий размер списка без заголовка (поле AclSize).

Элементы ACE имеют заголовок (ACE Header), описываемый структурой ACE_HEADER (тот же файл, строка 687), маску доступа и идентификатор безопасности SID. В заголовке указывается тип ACE (поле AceType); множество значений этого поля приведены в строках 699–728. Основными являются ACCESS_ALLOWED_ACE_TYPE (доступ разрешен) и ACCESS_DENIED_ACE_TYPE (доступ запрещен).

Маска доступа (Access Mask) описывает разнообразные виды доступа к объектам (строки 72–166). В маске выделяются стандартные права доступа (Standard Access Rights), применимые к большинству объектов, и специфичные для объектов права доступа (Object-Specific Access Rights).

Стандартными являются следующие права доступа:

DELETE – право на удаление объекта;
READ_CONTROL – право на просмотр информации о дескрипторе защиты объекта;
SYNCHRONIZE – право на использование объекта для синхронизации;
WRITE_DAC – право на изменение списка DACL;
WRITE_OWNER – право на смену владельца объекта.

Списки управления доступом бывают двух видов: DACL и SACL. Список управления избирательным доступом (DACL, Discretionary Access-Control List) определяет пользователей, которые могут получать доступ к объекту, а также указывает тип доступа. В системном списке управления доступом (SACL, System Access-control List) перечислены пользователи и операции, которые должны учитываться в журнале аудита безопасности (security audit log).

Схема получения доступа процесса к объекту показана на рис.13.4.

Рис. 13.4. Схема получения доступа процесса к объекту

За проверку возможности доступа процесса к объекту отвечает функция SeAccessCheck (файл base\ntos\se\accessck.c, строка 3391). На вход функции поступают следующие параметры:

дескриптор защиты объекта ( SecurityDescriptor );
маркер доступа процесса (элемент структуры SubjectSecurityContext );
маска запрашиваемого доступа ( DesiredAccess );
маска ранее предоставленного доступа ( PreviouslyGrantedAccess );
режим работы процессора ( AccessMode );

Функция возвращает TRUE , если процессу возможно предоставить доступ к объекту, а также маску предоставленного доступа (GrantedAccess). Если доступ запрещен, функция возвращает FALSE.

Функция SeAccessCheck осуществляет следующие действия:

Сначала анализируется режим работы процессора – если это режим ядра, доступ предоставляется без дальнейшего анализа (строки 3396–3416).
В случае пользовательского режима проверяется дескриптор защиты: если он отсутствует ( SecurityDescriptor == NULL ), в доступе отказывается (строки 3423–3428).
Если маска запрашиваемого доступа равна нулю ( DesiredAccess == 0 ), возвращается маска ранее предоставленного доступа (строки 3442–3454).
Если запрашивается доступ на изменение списка DACL (WRITE_DAC) или на чтение информации в дескрипторе защиты ( READ_CONTROL ), то при помощи функции SepTokenIsOwner проверяется, не является ли процесс владельцем объекта, к которому требуется получить доступ (строки 3477–3483). Если является, то ему предоставляются указанные права (3485–3492), а если запрашиваются только эти права, то функция успешно возвращает требуемую маску доступа (строки 3498–3506).
Вызывается функция SepAccessCheck (определенная в том же файле, строка 1809), которая просматривает список DACL объекта в поисках соответствия идентификаторов безопасности SID в маркере доступа процесса. В том случае, если список DACL пустой, процессу предоставляется доступ (строка 3510–3527).

Права и привилегии

Кроме операций с объектами система должна контролировать множество других действий пользователей, например, вход в систему, включение/выключение компьютера, изменение системного времени, загрузка драйверов и т.д.

Для управления такими действиями, не связанными с доступом к конкретным объектам, система использует два механизма – права учетных записей и привилегии.

Право учетной записи ( account right ) – разрешение или запрет на определенный вид входа в систему.

Различают следующие виды входа:

интерактивный (локальный) вход;
вход из сети;
вход через службу удаленных рабочих столов (ранее называлось – "через службу терминалов");
вход в качестве службы;
вход в качестве пакетного задания.

Проверка прав учетных записей осуществляется не в ядре, а в процессах Winlogon.exe и Lsass.exe.

Привилегия (privilege) – разрешение или запрет определенных действий в системе, например, включение/выключение компьютера или загрузка драйверов. Привилегии хранятся в поле Privileges структуры маркера доступа TOKEN (см. выше).

Список всех привилегий в системе можно посмотреть в оснастке MMC "Локальная политика безопасности " ( Local Security Policy ), раздел "Локальные политики" – "Назначение прав пользователей" ( Local Policies – User Rights Assignment ) (см. рис.13.5). Вызывается оснастка через Панель управления – Администрирование . ( Control Panel – Administrative Tools ).

Рис. 13.5. Оснастка "Локальная политика безопасности"

Резюме

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

Следующая лекция посвящена вопросам взаимодействия Windows с внешними устройствами.

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

Владелец и основная группа.

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

Основная группа содержится в дескрипторе безопасности лишь для обеспечения совместимости с подсистемой POSIX . Система Windows не использует эту часть дескриптора безопасности, если не применяются утилиты, которые оперируют с POSIX . По умолчанию принципал безопасности, создавший объект, записывает в дескриптор безопасности свою основную группу. Основной группой Windows по умолчанию является группа Domain Users .

Основная группа подразумевает членство в группе. При входе пользователя операционная система вставляет SID этой группы в маркер пользователя. Атрибут memberOf не перечисляет основную группу, а лишь включает явно назначенное членство в группах.

Дискреционные и системные списки контроля доступа.

Списки контроля доступа ACL состоят из двух частей. Первая часть списка контроля доступа представляет именованные контрольные флаги. Эти параметры контролируют применение разрешений в списке ACL и правил наследования. Вторая часть списка контроля доступа представляет собственно сам список. Этот список контроля доступа содержит одну или несколько записей управления доступом АСЕ. Флаги управления доступом определяют, каким образом Windows применяет записи управления доступом внутри списка ACL . Изначально Windows использует защищенные и автоматические флаги. Защищенные флаги запрещают модификацию списка контроля доступа путем наследования. Этот флаг является эквивалентом флажка Allow inheritable permissions from parent to propagate to this object (Разрешение наследуемых разрешений доступа). Флаг автоматически разрешает записям управления доступом в списках ACL наследовать разрешения доступа от родительских объектов дочерним.

Записи управления доступом.

Списки управления доступом содержат одну или несколько записей контроля доступа. В Windows записи управления доступом разбиты на два типа: Allow (Разрешить) и Deny (Запретить). Каждый тип АСЕ располагает объектом подтипа и необъектными подтипами. Записи управления доступом Allow и Deny назначают уровень доступа, обеспечиваемый подсистемой авторизации на основе права, запрашиваемого принципалом безопасности. Записи управления доступом к объектам являются исключающими для объектов в AD DS , поскольку они обеспечивают дополнительные поля для наследования объектов. Для большинства остальных ресурсов, как, например, ресурсов файловой системы и реестра, Windows использует необъектные записи управления доступом. Необъектные записи АСЕ обеспечивают наследование контейнеров, то есть объект в контейнере наследует запись контроля доступом контейнера. Этот принцип аналогичен наследованию разрешений доступа файлами от родительских папок. Каждый тип записи управления доступом располагает полем Rights и полем Trustee . Поля с правами обычно заполняются предварительно определенными числами, представляющими действия, которые может выполнять принципал безопасности. Рассмотрим пример с пользователем, запрашивающим чтение или запись файла. В этом случае чтение и запись являются двумя отдельными правами доступа. Поле доверия Trustee представляет идентификатор безопасности, разрешающий или запрещающий указанное право. В качестве примера можно привести пользователя или группу, которой разрешено либо запрещено выполнять действие, указанное в поле Right .

Маркеры доступа.

Связующим звеном между SID -идентификатором принципала безопасности и списком ACL является маркер доступа. Когда Windows выполняет проверку подлинности пользователя с помощью Kerberos , пользователю в процессе входа на локальном компьютере присваивается маркер доступа. Этот маркер включает основной SID пользователя, SID -идентификаторы всех групп, которым принадлежит пользователь, а также привилегии и права пользователя.

Примечание. Маркер доступа также может включать в атрибуте SIDHistory дополнительные SID -идентификаторы. Эти SID -идентификаторы могут заполняться при перемещении учетных записей пользователей из одного домена в другой.Маркер доступа используется подсистемой безопасности каждый раз при попытке пользователя получить доступ к ресурсу. Когда пользователь пытается получить доступ к локальному ресурсу, этот маркер предоставляется клиентской рабочей станцией всем потокам и приложениям, которые запрашивают данные безопасности перед разрешением доступа к ресурсу. Этот маркер доступа никогда не передается по сети на другие компьютеры. Вместо этого на каждом сервере, где пользователь пытается получить доступ к ресурсу, создается локальный маркер доступа. Например, когда пользователь пытается получить доступ к почтовому ящику на сервере, то на этом сервере создается маркер доступа. В данном случае подсистема безопасности на сервере будет сравнивать SID -идентификаторы в маркере доступа с разрешениями, предоставленными в ACL -списке почтового ящика. Если предоставленные для SID разрешения позволяют доступ, пользователь сможет открыть почтовый ящик.

Проверка подлинности.

Для работы процессов подсистемы безопасности, включая использование SID и ACL , нужно обеспечить способ получения пользователями доступа к сети. По сути, пользователи должны иметь возможность указывать свои данные для извлечения маркера доступа из контроллера домена. Этот процесс называется проверкой подлинности.

Проверка подлинности выполняется в исходном клиентском входе на компьютер, являющийся членом домена AD DS . Шаги проверки подлинности зависят от операционной системы, с помощью которой клиент входит в сеть.

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

Какие же механизмы включаются, когда мы выбираем пункт меню «Безопасность» из диалогового окна свойств файла? В данной статье я постараюсь ответить на этот вопрос. В качестве примера возьмем технологии получения списка логических дисковых разделов, локальных разделяемых ресурсов, а также рассмотрим две удобные утилиты, одна из которых входит в поставку NT, а вторая - в Resource Kit.

В операционной системe NT существует понятие «защищенный объект» (securable object). Это объект, доступ к которому контролируется и ограничивается операционной системой. В семействе операционных систем производства Microsoft лишь NT и Windows 2000 обеспечивают подобный сервис. К таким объектам относятся: файлы и каталоги файловой системы NTFS; каналы (pipes); процессы и потоки (Process and threads); файлы, спроецированные в память (mapped files); маркеры доступа (access tokens); объекты управления окнами (Window-management objects); разделы реестра (registry keys); службы Win32 (services); принтеры (Printers); разделенные сетевые ресурсы (Network shares); объекты синхронизации процессов (Interprocess synchronization objects - events, mutexes, semaphores, waitable timers); задачи (Job objects).

В модели ограничения доступа Win32 существует два базовых понятия:

Access tokens - маркеры доступа (МД), содержащие информацию о пользователе;

Security descriptors - описатели защиты, содержащие информацию о правах тех или иных учетных записей на доступ к объекту.

При регистрации пользователя в системе после успешной проверки имени и пароля создается маркер доступа. Для каждого процесса, выполняемого далее в контексте этого пользователя, создается копия МД. Маркер доступа содержит множество идентификаторов защиты (security identifiers, SID), определяющих учетные записи пользователя и тех групп, в которые он входит. Кроме того, МД содержит список привилегий (privilege) - прав на доступ к тем или иным объектам, предоставляемых той или иной учетной записи. С помощью этой информации операционная система определяет возможности доступа пользователя к ресурсам.

При создании защищенного объекта ОС присваивает ему описатель защиты (security descriptor, SD) - той защиты, которая имеется у пользователя, создающего объект, или же той, что задана по умолчанию. Приложения Win32 могут использовать функции API как для получения, так и для изменения информации о доступе к объектам.

Security descriptor содержит информацию о владельце объекта, а также может включать следующие списки контроля доступа Access-Contol List (ACL):

Discretionary access-control list (DACL) - разграничительные списки контроля доступа, в которых содержатся пользователи и группы с соответствующими правами на доступ к объекту;

System access-control list (SACL) - системные списки контроля доступа, которые определяют, как осуществляется аудит попыток доступа к объекту.

Список контроля доступа содержит список записей контроля доступа (access-control entries, ACEs). Каждая запись содержит набор битовых флагов и идентификатор SID попечителя (trustee) - пользователя или группы, к которой эти права применены.

Остановимся на упомянутых объектах более подробно.

Security Descriptor

Эти объекты содержат информацию о безопасности, соотнесенную с тем или иным защищенным объектом. Физически этот объект представляет собой структуру SECURITY_DESCRIPTOR, описанную в файле Windows.h:

Структура SECURITY_DESCRIPTOR используется для доступа к информации о безопасности объектов. Но изменять поля непосредственно в данной структуре невозможно. Для этого необходимо использовать специальные функции (например, SetSecurityDescriptorOwner(…)). Кроме того, Win32 API предоставляет интерфейс для создания и инициализации описателя SD для новых объектов.

Access token

Access token (маркер доступа) - это объект операционной системы, который описывает контекст ограничения доступа к процессу или потоку. Он содержит привилегии, соответствующие учетной записи пользователя, ассоциированного с процессом или потоком. Маркер доступа создается после успешной идентификации пользователя в системе. После этого каждый процесс, который так или иначе запускается данным пользователем, сопровождается копией его маркера.

Идентификатор защиты SID

Уникальный параметр переменной длины, определяющий учетную запись (account) и хранящийся в базе данных системы безопасности Windows NT, - вот что такое SID. В начале каждого сеанса, как только пользователь идентифицирован в системе, его SID извлекается из БД и помещается в маркер доступа. Далее это значение используется операционной системой при всех действиях пользователя с защищенными объектами.

Существует несколько стандартных SID, применяемых для учетных записей:

NULL - S-1-0-0 - SID группы, в которую не входят пользователи. Используется лишь тогда, когда SID неизвестен;

World - S-1-1-0 - группа, включающая в себя всех пользователей;

Local - S-1-2-0 - пользователи, имеющие непосредственный, физический доступ к системе;

Creator Owner ID - S-1-3-0 - SID, которым заменяется SID пользователя, создавшего объект. Этот SID используется для унаследованных записей ACE (см. ниже);

Creator Group ID - S-1-3-1 - значение, заменяющее SID основной группы, к которой принадлежит пользователь, создавший объект. Этот SID, как и предыдущий, используется для унаследованных записей ACE.

Список управления доступом ACL

ACL представлен структурой, описанной в Windows.h:

Для Windows NT версий 3.5, 3.51, 4.0 определено максимальное число записей управления доступом, задаваемых списком управления доступом (см. статью Q166348 в базе знаний Microsoft). Оно равно 1820.

Запись управления доступом ACE

Система ограничения доступа Windows NT/2000 использует несколько типов записей ACE, которые перечислены в Таблице 1, содержащей, кроме того, и названия соответствующих этим типам структур данных.

Вполне вероятно, что в следующих версиях операционной системы появятся новые типы ACE, да и из приведенных в Таблице 1 некоторые поддерживаются только Windows 2000. Для того чтобы унифицировать процедуру анализа структур ACE, разработчики включили во все структуры _ACE одинаковую последовательность полей, которая отображается в структуре ACE_HEADER:

Первое поле AceType определяет тип структуры. Очевидно, что указатель на любую структуру _ACE можно преобразовать в указатель на ACE_HEAER, получить тип ACE, после чего этот указатель преобразовать в указатель на соответствующую полученному типу структуру данных. Замечу, что такой прием широко используется в различных API продуктов Microsoft.

На Листинге 1 показано, как получить список логических дисков. Для этого используется функция Win-API NetServerDiskEnum. Ее первый параметр определяет сетевое имя компьютера, список накопителей которого нас интересует. Если этот параметр NULL, то берется локальный компьютер. Список дисковых накопителей возвращается в параметре lpBuf. Он имеет вид последовательности из 3 байт. Каждая последовательность содержит букву - символ диска, двоеточие и разделитель NULL. Количество прочитанных накопителей возвращается в параметре dwReded, а общее количество дисков - в dwTotal. После обработки буфер lpBuf необходимо освободить вызовом функции NetApi-BufferFree(lpBuf).

В коде Листинга 1 вызывается написанная мной функция GetParti-tionTypeEx. Она получает параметры дискового накопителя, возвращает наименование файловой системы, на нем установленной, и проверяет, поддерживает ли файловая система контроль ограничения доступа (cм. Листинг 2).

В Win32 API для получения информации о дисковом разделе используется функция

Ее параметры описаны в Таблице 2. Чуть подробнее рассмотрим параметр lpFileSystemFlags. Это набор битовых флагов. Среди прочих определен флаг FS_PERSISTENT_ACLS. Наличие этого флага означает, что папки и файлы раздела являются охраняемыми объектами. Перед тем как получать списки ACE для того или иного объекта, неплохо убедиться, что файловая система их поддерживает. Теперь мы знаем, как это делается.

Список записей управления доступом для защищенных объектов

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

Чтобы получить структуру ACL для именованного объекта, нужно задействовать функцию GetNmedSe-curityInfo. Среди прочих значений она возвращает указатели на DACL и SACL. Нас интересует первый из них. Теперь у нас есть вся информация для создания списка ACE. Функция GetAce позволяет пройти по всему списку заголовков ACE_HEADER, соответствующих ACL. Этой функции передаются три параметра. Первый - указатель на ACL, второй - порядковый номер ACE, указатель на который возвращается в третьем параметре (cм. Листинг 3).

Список разделяемых ресурсов и прав для них

Последний вопрос, который я хочу подробно рассмотреть, касается получения списка локальных ресурсов общего доступа (shares) и прав доступа к ним. Процедура получения прав на объекты идентична описанной процедуре получения прав на доступ к файловым объектам. Поэтому реализующий ее код включен в код процедуры, представленной в Листинге 4, и отдельно не обсуждается. Это характерно для API системы безопасности, которая предоставляет обобщенный интерфейс ко всем защищенным объектам. Действительно, с точки зрения системы ограничения доступа Windows разделяемый ресурс - такой же именованный объект, как, например, и файл. Поэтому алгоритмы работы с ними одни и те же.

Список разделяемых ресурсов предоставляется функцией

Для получения SD ресурса используется функция

Для получения списка ACE используется поле shi502_security_descriptor, содержащее необходимый Security Descriptor.

Восстановление параметров безопасности

Результатом работы утилиты, которую можно загрузить по указанному адресу, является командный файл. Прекрасно, скажете вы, а что дальше? Вообще говоря, наш файл состоит из двух частей: в первой создаются и устанавливаются права доступа к разделяемым файлам и каталогам, а во второй выясняются параметры безопасности для объектов файловой системы. Для работы с разделяемыми ресурсами из командной строки в Microsoft WindowsNT (R) Resource Kit есть небольшая программа - RMTSHARE.EXE. Сценарий создан с использованием этой программы.

Параметры команды такие:

Для просмотра и установки параметров доступа к объектам NTFS используется утилита cacls.exe, входящая в WinNT.

Filename - без других параметров выводит на экран список пользователей и их прав на доступ к объекту Filename.

/T - изменяет список записей управления доступом к объекту, а если это папка, то ко всем вложенным папкам.

/E - заменяет список записей управления доступом.

/C - позволяет продолжить работу в случае ошибки отказа в доступе.

/G user:perm - устанавливает для пользователя, определяемого параметром user, права на доступ к объекту, определяемые параметром perm:

N - нет; R - чтение; W - запись; C - изменение; F - полный контроль.

/R user - удаляет для указанного пользователя права на доступ к объекту.

/P user:perm - изменяет для указанного в параметре user пользователя права на доступ к объекту, которые описываются параметром perm и могут быть следующими:

N - нет; R - чтение; W - запись; C - изменение; F - полный контроль.

/D user - запрещает применять пользователю доступ к указанному объекту.

Утилита позволяет применять маски, например *.*, в именах файлов и папок, а также указывать в одной команде несколько пользователей. В Knowledge Base описан метод использования утилиты cacls.exe для изменения прав доступа не только пользователей, но и групп к объектам файловой системы. В этом случае синтаксис сохраняется, но имена групп берутся в кавычки (Q162786).

Active Directory и доступ к информации о безопасности

В Windows 2000 реализована новая служба качественно меняющая, кроме всего прочего, и механизмы работы с объектами файловой системы. Это Active Directory. Программный интерфейс к ней называется Active Directory Service Interfaces (ADSI). ADSI представляет собой набор COM-объектов, обеспечивающий программный интерфейс к функциям службы Active Directory. Базовые объекты системы безопасности (ACL, SID, ACE и т. д.) в ADSI те же, что и описанные выше. Существенные изменения коснулись лишь механизмов манипуляции с ними. Подробнее об ADSI я планирую рассказать в следующей статье.

Читайте также: