Дескрипторы безопасности в 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 разрешения позволяют доступ, пользователь сможет открыть почтовый ящик.

Читайте также: Tcpblock mac os x

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

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

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

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

Безопасность в Windows

Дескриптор защиты

Объекты, к которым могут получать доступ процессы, имеют специальный атрибут – дескриптор защиты (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).

Заголовок списка описывается структурой 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.

За проверку возможности доступа процесса к объекту отвечает функция 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 ).

Следует отметить, что в оснастке не различаются права учетных записей и привилегии, но это легко можно сделать самостоятельно: право учетной записи всегда содержит слово «вход» (например, «Вход в качестве пакетного задания»).

Резюме

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

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