Организация разграничения доступа к объектам

Сущность модели защиты, реализованной в SRM, отражает математическое выражение с тремя входными параметрами: идентификационными данными защиты потока, запросившего доступ; запрошенным типом доступа и информацией о защите объекта, к которому осуществляется попытка доступа. Его результат — значения "да" или "нет", которые определяют, предоставит ли модель защиты ОС Windows запрошенный тип доступа.

Для идентификации субъектов, выполняющих в системе различные действия, ОС Windows использует не имена (которые могут не быть уникальными), а идентификаторы защиты (идентификаторы безопасности) (security identifiers, SID). Такие идентификаторы имеются у пользователей, локальных и доменных групп, компьютеров, доменов и членов доменов. Например, после ввода имени и пароля пользователя процесс Winlogon передает их подсистеме LSASS, которая, задействуя пакет аутентификации, сопоставляет имя и пароль пользователя с теми записями, что хранятся в базе данных LSASS. Если соответствие найдено, то диспетчер SAM (или в случае использования Active Directory — служба каталога Active Directory) возвращает уникальный идентификатор защиты пользователя и идентификаторы защиты групп, к которым принадлежит данный пользователь. Пакет аутентификации по окончании своей работы создает сессию пользователя и возвращает управление LSASS. После этого подсистема LSASS создает маркер доступа (access token), содержащий идентификатор защиты пользователя и его права. Таким образом, в рамках сессии любой процесс, запускаемый от имени пользователя, получает данный маркер доступа, и может быть однозначно сопоставлен с данным пользователем. Системные процессы также имеют маркеры доступа, создаваемые при старте системы. При проверке возможности доступа к ресурсу-объекту маркер выполняет функцию "пропуска".

Все алгоритмы принятия решений о предоставлении доступа к информационным ресурсам реализованы в мониторе обращений. Защищаемые объекты ОС Windows включают: файлы, процессы, потоки, разделы реестра, рабочие столы, сервисы, объекты Active Directory и т.д. Поскольку системные ресурсы, экспортируемые в пользовательский режим (и поэтому требующие проверки защиты), реализуются как объекты режима ядра, диспетчер объектов также играет ключевую роль в их защите. Для контроля за операциями над объектами система должна быть уверена в правильности идентификации каждого пользователя. Именно по этой причине ОС Windows требует от пользователя входа с аутентификацией, прежде чем ему будет разрешено обращаться к системным ресурсам. Когда какой-нибудь объект запрашивает описатель объекта, диспетчер объектов совместно с подсистемой защиты на основе идентификационных данных вызывающего процесса определяют, можно ли предоставить ему описатель.

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

Возможность осуществления того или иного вида доступа к защищаемым ресурсам в ОС Windows определяется монитором обращений на базе дискреционных списков контроля доступа (discretionary access control lists, DACL). Список DACL состоит из набора записей контроля доступа (access control entry, ACE). Каждая запись ACE представляет собой набор (рис. 5.2) следующих данных:

· структура ACE_HEADER — заголовок записи ACE, содержащий служебную информацию;

Рис. 5.2. Структура записи ACE защищаемого объекта

· структура ACCESS_MASK — маска прав доступа, которая содержит список прав, предоставляемых пользователям (группам) к конкретному объекту;

· идентификатор защиты пользователя или группы, к которому относится данная запись ACE и для которого указана маска прав доступа к объекту.

Таким образом, список DACL можно представить в виде множества пар "идентификатор зашиты ¾ права доступа", соотнесенных данному объекту. В заголовке (структура ACE_HEDER) описаны тип записи ACE, специальные флаги и размер записи ACE. Тип записи ACE позволяет разделять разрешающие (ACCESS_ALLOWED_ACE) и запрещающие (ACCESS_DENIED_ACE) записи ACE. Если тип записи разрешающий, то права доступа в маске прав, трактуются как разрешения на доступ. Если тип записи запрещающий, то в маске указаны запрещения на осуществление указанных видов доступа. Для каждого разрешения в системе определен запрет, который может его отменить.

Операционная система Windows поддерживает списки DACL для всех защищаемых объектов системы. С каждой парой "пользователь (группа)-объект" связано множество прав доступа, регламентирующих доступ пользователей (групп) к объекту. В общем случае права доступа представлены в виде 32-битного числа — маски доступа, каждый разряд которой ассоциирован с определенным разрешением для разрешающего ACE или запретом для запрещающего (рис. 5.3).

Если какой-либо бит установлен в единицу (включен), то ассоциированное с ним разрешение/запрет присутствует в соответствующей записи ACE.

Рис. 5.3. Структура маски доступа в записи ACE объекта защиты

Биты 0…15 представляют права доступа, характерные для каждого типа защищаемого объекта, т.е. некоторый бит соответствует разным правам доступа для разных объектов. Например, для файлов установка бита 0 влияет на чтение данных, а для процессов — на прерывание выполнения.

Биты 16…20 несут смысловую нагрузку, общую для большинства защищаемых объектов, т.е. для разных объектов установка такого бита соответствует одному и тому же праву доступа. Например, и для файлов, и для процессов бит 19 отвечает за возможность смены владельца объекта. Бит 16 (DELETE) предоставляет право на удаление объекта; бит 17 (READ_CONTROL) — право на чтение информации, содержащейся в дескрипторе защиты, исключая информацию SACL; бит 18 (WRITE_DAC) — право на модификацию списка DACL объекта; бит 19 (WRITE_OWNER) — право на смену пользователя (группы), являющегося владельцем объекта; бит 20 (SYNCHRONIZE) — право на использование объекта для синхронизации (позволяет потоку ждать, пока объект находится в сигнальном состоянии).

Бит 24 (AS — от словосочетания "Access SACL") — бит права доступа к системному ACL (system access control list), т.е. к записям системного аудита. Данный бит выполняет единую функцию для всех типов защищаемых объектов, но он не играет никакой роли при организации доступа к объекту.

Биты 21…23 и 25…27 не используются в настоящее время при организации доступа, они зарезервированы для расширения ОС.

Биты 28…31 выполняют общие функции, не зависящие от типа защищаемого объекта. Они носят название общие биты. Бит 28 (GA, Generic All) — общее право полного доступа. Бит 29 (GE, Generic Execute) — общее право исполнения. Бит 30 (GW, Generic Write) — общее право записи. Бит 31 (GR, Generic Read) — общее право чтения.

В том случае, если в списке DACL разрешающая запись AСЕ предшествует запрещающей, то пользователь получает соответствующий доступ к объекту. Встроенные в ОС Windows средства редактирования прав доступа всегда формируют список DACL, в котором разрешающие записи ACE следуют за запрещающими; таким образом, запреты всегда перекрывают разрешения. Такой список DACL называется каноническим. Однако в ОС Windows запрещающие записи ACE реализованы исключительно ради удобства. Допустим, требуется предоставить некоторой группе пользователей доступ к объекту, но блокировать доступ для одного из пользователей этой группы. В данном случае гораздо удобнее разрешить доступ всей группе и запретить доступ одному пользователю, чем устанавливать разрешения отдельно для каждого члена группы. Тем не менее, можно установить любые настройки безопасности, пользуясь исключительно разрешениями.

Таким образом, в результате рассмотрения архитектуры и особенностей подсистемы защиты ОС Windows можно сделать выводы:

· в ОС Windows реализована подсистема защиты информационных ресурсов, основанная на применении объектной модели, которая позволяет унифицировать представление и управление ресурсами;

· участники безопасности (т.е. пользователи и группы) ОС Windows могут быть однозначно идентифицированы в системе посредством идентификаторов защиты;

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

· согласно объектной модели, реализованной в ОС Windows, с каждым типом ресурсов сопоставлен унифицированный атрибут — список прав доступа DACL. Этот список позволяет организовать контроль и управление доступом субъектов к объектам. Биты, составляющие маску доступа для данного типа объектов, могут либо разрешать, либо запрещать доступ. В маске доступа существует набор битов, специфичный для каждого типа объектов;

· организация контроля и управления доступом возложена на компонент ОС Windows — монитор обращений, — который реализует модель безопасности ОС и выполняет сопоставление запрошенных пользователем видов доступа, привилегий, предоставленных пользователю и множества прав, указанных в списке DACL;

· объекты Active Directory не отличаются от остальных системных объектов в плане защиты: при этом используются списки DACL и идентификация процессов аналогично локальной версии ОС. Уникальность использования Active Directory заключается в специальных настройках безопасности, появляющихся в серверной ОС, и расширении множества параметров, влияющих на доступ к защищаемым объектам.

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