Разработка микропроцессорного устройства управления

Идентификатор SID может  показаться слишком сложным, но важно понять, что одна его часть уникальна для инсталляции или домена, а другая – общая для всех инсталляций и ваменов (относительный идентификатор R1D). После установки Windows Server 2003 локальный компьютер случайным образом выбирает SID. То же самое происходит и при создании домена под Windows Server 2003 – он также получает уникальный идентификатор SID. Таким образом, для любого компьютера или домена под управлением Windows Server 2003 значения под полномочий всегда будут уникальными (если только их не подделывали и не дублировали, как это происходит при некоторых видах низкоуровневого копирования дисков).

В любом случае, значение R1D является постоянным для всех компьютеров  и доменов. Например, идентификатор SID, у которого значение RiD равно 500, всегда принадлежит учетной записи Administrator локальной машины. RID 501 используется для учетной записи Guest. Для домена RID начинается со значения 1001 и показывает количество учетных записей пользователей (например, RID 1015 получит пятнадцатый пользователь домена). Достаточно сказать, что переименование учетной записи никак не влияет на соответствующий ей S1D, поэтому учетная запись всегда будет идентифицирована.

Переименовав учетную  запись Administrator, вы лишь измените ее имя, система Windows Server 2003 (или злоумышленник, использующий специальные средства) всегда определит се по значению R1D 500. На Рисунке 2.1 показана схема идентификатора SID.

Рисунок 2.1– Схема идентификатора SID

SID – Security Identifier (идентификатор безопасности) – это структура данных в двоичном формате переменной длины, использующаяся, для однозначной идентификации пользователя, группы или компьютера. Структура SID используется Windows в следующих элементах безопасности:

• дескриптор безопасности (SD) – для идентификации владельца объекта и его первичной группы;
• запись управления доступом (АСЕ) – для идентификации субъектов, которым разрешён или запрещён доступ к объекту;
• маркер доступа  для идентификации пользователя и групп, к которым он принадлежит. 

Во время аутентификации для пользователя создаётся маркер доступа (маркер безопасности), который  хранит информацию о коде SID пользователя и обо всех кодах SID групп, к которым он принадлежит.                   
3 Маркер доступа (access token) 

Маркер доступа (англ. Access token) – программный объект операционных систем класса Microsoft Windows, содержит информацию по безопасности сеанса и идентифицирует пользователя, группу пользователей и пользовательские привилегии.

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

Маркер доступа генерируется сервисом входа в систему, когда  пользователь регистрируется, и его подлинность успешно установлена, определяя права пользователя в дескрипторе безопасности, заключенном в маркер. Маркер прилагается к каждому процессу, созданному сессией пользователя (процессы, собственником которых является пользователь). Когда бы такой процесс ни запрашивал любой ресурс, доступ к которому контролируется, Windows смотрит в дескрипторе безопасности в маркере доступа, имеет ли пользователь, владелец данного процесса, право доступа к данным, и, если да, какие операции (чтение, запись/изменение) ему дозволены. Если операция дозволена в контексте данного пользователя, Windows позволяет процессу её продолжать, если нет, то отказывает в доступе.

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

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

Запрос согласия. Запрос согласия отображается в том случае, когда пользователь пытается выполнить задачу, которая требует права администратора. Пользователь дает согласие или отказывается, нажимая на кнопку «Да» или «Нет».

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

3.1 Типы маркеров

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

• первичные маркеры доступа могут быть ассоциированы только с процессом и представляют собой субъект безопасности процесса. Создание первичных маркеров и их ассоциация с процессом являются привилегированными операциями, нуждающимися в двух различных привилегиях (для разделения привилегий) – типичный сценарий видит создающий маркер доступа сервис идентификации и сервис входа в систему, ассоциирующий его с оболочкой операционной системы. Процесс изначально наследует копию первичного маркера родительского процесса. Имперсонализирующие маркеры доступа могут быть ассоциированы только с потоками и представляют собой субъекты безопасности клиентского процесса;
• имперсонализация – это концепт безопасности присущий только Windows NT, что позволяет серверному приложению временно «быть» клиентом для доступа к охраняемому объекту. Имперсонализация состоит из трёх возможных уровней: идентификация, позволяющий серверу проверять подлинность клиента, имперсонализация, позволяющая серверу работать от имени клиента, и делегация, то же, что и имперсонализация, только расширена на работу с удалёнными системами, с которыми связывается сервер. Клиент может выбрать максимально возможный уровень имперсонализации на сервере в параметре подключения. Делегация и имперсонализация – привилегированные операции.

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

• идентификатор;
• идентификатор ассоциированной сессии входа в систему. Сессия обслуживается сервисом идентификации и заполняется идентификационными пакетами с коллекцией всей информации (мандат), сообщенной пользователем во время входа в систему. Мандат используется для доступа к удаленным системам без необходимости переидентифицировать клиента, предусматривающий, что все вовлеченные системы делятся информацией по идентификации;
• идентификатор пользователя. Это поле наиболее важное и защищено от записи;
• идеитификатор групп, частью который является пользователь (или, точнее, субъект). Идентификаторы групп не могут быть удалены, но могут быть отключены. Как максимум, одна из групп назначается идентификатором сессии, произвольная группа, представляющая собой сессию входа в систему, позволяющая получить доступ к различным объектам, ассоциированным с сессией;
• ограничивающие идентификаторы группы (поле не обязательно). Это дополнительное множество групп не дающее дополнительного доступа, но ограничивающее его: доступ к объекту открыт только если он также открыт для одной из этих групп. Данный вид групп не может быть ни удалён, ни отключён;
• привилегии, то есть специальные возможности пользователя.

Большинство привилегий по умолчанию отключены, чтобы исключить возможные повреждения от плохо защищённых программ. Начиная с Windows XP Service Pack 2 и Windows Server 2003, привилегии могут быть удалены из маркера доступа вызовом AdjustTokenPrivileges() ас атрибутом SE_PRIVILEGE_REMOVE. 

4 DACL/ SACL

Список управления доступом (access-control list, ACL) состоит из заголовка и может содержать элементы (access-control entries, АСЕ). Существует два типа ACL: DACL и SACL. B DACL каждый ACE содержит SID и маску доступа (а также набор флагов), причем ACE могут быть четырех типов: «доступ разрешен» (access allowed), «доступ отклонен» (access denied), «разрешенный объект» (allowed-object) и «запрещенный объект» (denied-object). Как вы, наверное, и подумали, первый тип ACE разрешает пользователю доступ к объекту, а второй – отказывает в предоставлении прав, указанных в маске доступа. 

SACL – это традиционный  механизм логирования событий,  который определяет, как проверяется  доступ к файлам и папкам. В  отличие от DACL, SACL не может ограничивать доступ к файлам и папкам. Но он может отследить событие, которое будет записано в журнал событий безопасности(security event log), когда пользователь обратится к файлу или папке. Это отслеживание может быть полезно при решении проблем доступа или при определении запрещенного проникновения.

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

Разница между ACE типа «разрешенный объект» и «доступ разрешен», а также между ACE типа «запрещенный объект» и «доступ отклонен» заключается в том, что эти типы используются только в Active Directory. ACE этих типов имеют поле глобально уникального идентификатора (globally unique identifier, GUID), которое сообщает, что данный ACE применим только к определенным объектам или под объектам (с GUID-идентификаторами). Кроме того, необязательный GUID указывает, что тип дочернего объекта наследует ACE при его (объекта) создании в контейнере Active Directory, к которому применен АСЕ. (GUID – это гарантированно уникальный 128-битный идентификатор.) 

За счет аккумуляции  прав доступа, сопоставленных с индивидуальными  АСЕ, формируется набор прав, предоставляемых ACL-списком. Если в дескрипторе защиты нет DACL (DACL = null), любой пользователь получает полный доступ к объекту. Если DACL пуст (т. е. в нем нет АСЕ), доступа к объекту не получает никто.  
АСЕ, используемые в DACL, также имеют набор флагов, контролирующих и определяющих характеристики АСЕ, связанные с наследованием. Некоторые пространства имен объектов содержат объекты-контейнеры и объекты-листы (leaf objects). Контейнер может включать другие контейнеры и листы, которые являются его дочерними объектами. Примеры контейнеров — каталоги в пространстве имен файловой системы и разделы в пространстве имен реестра. Отдельные флаги контролируют, как ACE применяется к дочерним объектам контейнера, сопоставленного с этим АСЕ. Часть правил наследования ACE представлена в таблице 8–3 (полный список см. в Platform SDK).

SACL состоит из ACE двух  типов: системного аудита (system audit ACE) и объекта системного аудита (system audit-object АСЕ). Эти ACE определяют, какие операции, выполняемые над объектами конкретными пользователями или группами, подлежат аудиту. Информация аудита хранится в системном журнале аудита. Аудиту могут подлежать как успешные, так и неудачные операции. Как и специфические для объектов ACE из DACL, ACE объектов системного аудита содержат GUID, указывающий типы объектов или под-объектов, к которым применим данный АСЕ, и необязательный GUID, контролирующий передачу ACE дочерним объектам конкретных типов. При SACL, равном null, аудит объекта не ведется.

4.1 Алгоритмы

От общей теории перейдем к рассмотрению алгоритмов работы ACL:

• если DACL не существует (null), то все имеют полный доступ (именно с этой точки зрения можно смотреть на FAT);
• если DACL пустой, то никто не имеет доступа;
• если вызываемый процесс (точнее, поток, но это нам не важно) имеет право на захват объекта во владение, то он может стать владельцем объекта и изменить DACL;
• если вызываемый процесс является владельцем, то он может изменить DACL;
• из маски прав доступа удаляется маска доступа каждого ACE типа «доступ отклонен», если SID совпадает с SID маркера доступа процесса;
• к полученной маске прав доступа добавляется маска доступа каждого ACE типа «доступ разрешен», если SID совпадает с SID маркера доступа процесса (не считая тех прав, в которых уже отказано);
• полученная маска доступа и определяет права доступа, которые имеет программа, их запрашивающая (точнее, пользователь, ее запустивший – SID-то его).

Это общая схема, тем  не менее, дающая нам возможность  понять, как все это работает.

Теперь подобьем наши знания и добавим новые:

• владелец объекта (по умолчанию его создатель) способен делать с ним все что угодно, так как может изменить DACL (да и SACL тоже);
• пользователь, который имеет права на вступление во владение (администратор, например), способен стать его владельцем со всеми вытекающими;
• если права для пользователя или группы не указаны, то они не имеют доступа к объекту;
• права имеют кумулятивный характер, т.е. наследуются пользователями конкретной группы. Если, скажем, группа Все имеет полный доступ к какому-либо объекту, то и все члены этой группы тоже имеют полный доступ;
• запрет имеет большие привилегии, чем разрешение. Кажется, зачем это надо, ведь можно просто не указать разрешение? А если мне нужно, чтобы конкретный пользователь группы не имел доступа к объекту, а вся группа имела? Не удалять же его из группы:-);
• по умолчанию созданный (или скопированный) объект наследует права доступа (DACL, а также SACL) от родительского контейнера, но это можно изменить. При наследовании ACE удалить невозможно, но можно добавить;
• при необходимости можно распространить DACL (и SACL) на все вложенные контейнеры и объекты, тем самым заменив их права.