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

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

Основным содержанием атрибутов защиты является другая структура – дескриптор защиты. Этот дескриптор содержит следующие данные:

· идентификатор защиты (SID) владельца объекта;

· идентификатор защиты первичной группы владельца объекта;

· пользовательский («дискреционный», «разграничительный») список управления доступом (DACL, Discretionary Access Control List);

· системный список управления доступом (SACL, System Access Control List).

Пользовательский список управляет разрешениями и запретами доступа к данному объекту. Изменять этот список может только владелец объекта.

Системный список управляет только аудитом доступа данному объекту, т.е. задает, какие действия пользователей по отношению к данному объекту должны быть запротоколированы в системном журнале. Изменять этот список может только пользователь, имеющий права администратора системы.

В Windows, в отличие от многих других ОС, администратор не всесилен. Он не может запретить или разрешить кому бы то ни было, даже самому себе, доступ к чужому файлу. Другое дело, что администратор имеет право объявить себя владельцем любого файла, но потом он не сможет вернуть файл прежнему хозяину. Подобные ограничения вытекают из понимания, что администратор тоже не всегда ангел и, хотя он должен иметь в системе большие права, его действия следует хоть как-то контролировать.

Оба списка управления доступом имеют одинаковую структуру, их основной частью является массив записей управления доступом (ACE, Access Control Entity).

Рассмотрим структуру записи ACE. Она содержит:

· тип ACE, который может быть одним из следующих: разрешение, запрет, аудит;

· флаги, уточняющие особенности действия данной ACE;

· битовая маска видов доступа, указывающая, какие именно действия следует разрешить, запретить или подвергнуть аудиту;

· идентификатор (SID) пользователя или группы, чьи права определяет данная ACE.

Более интересен пользовательский список. Он может содержать только записи разрешения и запрета. В начале списка всегда идут запрещающие записи, затем разрешающие.

Когда пользователь запрашивает доступ к объекту (т.е., например, программа, запущенная этим пользователем, вызывает функцию открытия файла), происходит проверка прав доступа. Она выполняется на основе сравнения маркера доступа пользователя со списком DACL. Система просматривает по порядку все записи ACE из DACL, для каждой ACE определяет записанный в ней SID и сверяет, не является ли он идентификатором текущего пользователя или одной из групп, куда входит этот пользователь. Если нет, то данная ACE не имеет к нему отношения и не учитывается. Если да, то выполняется сравнение прав, необходимых пользователю для выполнения запрошенной операции с маской видов доступа из ACE. При этом права анализируются весьма детально: например, открытие файла на чтение подразумевает наличие прав на чтение данных, на чтение атрибутов (в том числе владельца и атрибутов защиты), на использование файла как объекта синхронизации (см. п. 4.5.5.2).

Если в запрещающей ACE найдется хотя бы один единичный бит в позиции, соответствующей одному из запрошенных видов доступа, то вся операция, начатая пользователем, считается запрещенной и дальнейшие проверки не производятся.

Если такие биты будут найдены в разрешающей ACE, то проверка следующих ACE выполняется до тех пор, пока не будут разрешены и все остальные запрошенные виды доступа.

Как выдумаете, почему в списке DACL сначала идут запрещающие ACE, а только потом разрешающие?

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

В годы перестройки много писалось о двух противоположных принципах: «запрещено все, что не разрешено» или «разрешено все, что не запрещено». В Windows все гораздо строже: запрещено все, что запрещено, и все, что не разрешено.

Список DACL со всеми необходимыми разрешениями и запретами может быть установлен программно при создании файла, а впоследствии программно же может быть изменен владельцем. Можно также изменять разрешения в диалоге, воспользовавшись окном свойств файла.

Имеются также два крайних случая. Список DACL может совсем отсутствовать (для этого достаточно, например, при создании файла указать NULL вместо атрибутов защиты), при этом права доступа не проверяются, все действия разрешены всем пользователям. Список DACL может присутствовать, но иметь нулевую длину (нет ни одной ACE). Как следует из общих правил, в этом случае в доступе будет отказано всем, в том числе и хозяину файла.








Дата добавления: 2015-09-07; просмотров: 846;


Поиск по сайту:

При помощи поиска вы сможете найти нужную вам информацию.

Поделитесь с друзьями:

Если вам перенёс пользу информационный материал, или помог в учебе – поделитесь этим сайтом с друзьями и знакомыми.
helpiks.org - Хелпикс.Орг - 2014-2024 год. Материал сайта представляется для ознакомительного и учебного использования. | Поддержка
Генерация страницы за: 0.009 сек.