Операционные системы. Управление ресурсами
Дополнительные возможности
Среди действий, которые может выполнять пользователь, есть и такие, которые не связаны с конкретным объектом, а относятся к большой группе объектов или даже ко всей системе в целом, например, выполнение тех или иных команд, создание объектов определенного типа и т.п. Возможность выполнять такие действия иногда называют полномочиями (authority), для присваивания и учета полномочий существуют специальные механизмы. Независимо от того, как представляется информация о правах доступа субъектов к объектам, список полномочий связывается обязательно с профилем пользователя, так как нет возможности связать его с объектом. Впрочем, в системах, последовательно реализующих объектно-ориентированный подход, полномочия, точнее - средства, через которые они реализуются (команды, системные вызовы) сами являются объектами, для доступа к ним назначаются права, как и для других объектов, поэтому здесь нет необходимости выделять их в отдельную категорию.
Для большинства задач управления доступом может оказаться удобной интеграция некоторого подмножества объектов и связанных с ними подмножеств возможностей в единый элемент, называемый доменом (domain). Если несколько субъектов имеют доступ к одному и тому же набору объектов, причем, с одинаковыми правами, то говорят, что субъекты работают в одном домене. Домены представляют собой удобное средство для сокращения представления информации о защите: в списке возможностей, например, перечисление ряда объектов может быть заменено идентификатором домена, который эти объекты составляют. Домены могут быть пересекающимися. Субъект может работать в нескольких доменах одновременно. Концепция доменов широко используется в современных ОС.
Различаются домены системные и специфицируемые. Системные домены являются предустановленными и неизменяемыми. С системными доменами связываются классы пользователей: принадлежность пользователя к тому или иному классу разрешает пользователю работать в том или ином домене. Обычно в системные домены входят объекты и соответствующие полномочия, позволяющие выполнять, например, управление системой.
Простейший пример пользовательских классов - обычный пользователь и привилегированный (суперпользователь). Домен привилегированного пользователя охватывает все объекты системы со всеми правами доступа к ним. Предустановленный домен обычного пользователя разрешает ему доступ к такому подмножеству объектов и возможностей, оперируя которыми он не может вывести из строя ОС или повредить другим пользователям. Дополнительные права обычного пользователя обеспечиваются специфицируемыми доменами и персональными разрешениями.
Специфицируемые домены могут создаваться и конфигурироваться динамически. Во всех ОС пользователи, разделяющие специфицированный домен, объединяются в группы. ОС поддерживает список групп и с каждой группой связывает отдельный домен. В примере раздела 7.7 мы видели, что Unix различает "группу, в которую входит владелец файла". В более развитых системах защиты пользователь может включаться в несколько групп, и домены групп могут пересекаться. Состав пользователей в группе, состав и возможности домена группы могут изменяться администратором или теми, пользователями, которые имеют на это право. Группам могут даваться также и полномочия. С точки зрения представления информации о безопасности группа выступает как один пользователь, и для каждой группы создается собственная запись в базе профилей. Вместо того, чтобы в список прав включать отдельные записи для всех членов какой-то группы, в список заносится единственная запись для всей группы. Имеются обычно также и системные, предустановленные группы - такие как системные администраторы, операторы и т.п., но состав системных групп может меняться динамически.
Объединение объектов составляет группу объектов, права доступа в которой ко всем объектам одинаковы. Права могут быть разные для разных пользователей и групп, но каждый пользователь имеет одни и те же привилегии в ко отношении всех объектов группы. Так же, как и группы пользователей, группы доступа позволяют сократить объем информации по безопасности, представляя всю группу доступа как один объект.
Еще одним средством сокращения объема такой информации являются интегрированные права, сформированные из нескольких элементарных прав, например, право данных - права читать и изменять данные.
Среди стандартных прав может быть также право Exclude, явный запрет на доступ к объекту. Записи о правах Exclude размещаются первыми в списках информации о безопасности, таким образом, при поиске они находятся в первую очередь.
В разделе 10.2 мы упоминали о возможности работы в системе "гостя". "Гость" не может иметь никаких индивидуальных или групповых прав, так как он не зарегистрирован в базе профилей, но некоторые объекты в системе могут быть для него доступны. Говоря шире, в системе могут быть объекты, доступные для всех. Права доступа "для всех" называются публичными (public), они реализуются либо в специальной группе пользователей PUBLIC (гости получают идентификатор безопасности этой группы), либо специальным разделом публичных прав в списках прав объектов и групп доступа.
С учетом перечисленных компонентов системы безопасности, процедуры авторизации выполняется в следующей последовательности:
- поиск в индивидуальных правах пользователя;
- поиск в групповых правах пользователя;
- поиск в публичных правах.
Поиск прекращается, если на любом из этапов будут найдены права, соответствующие запрошенному доступу, доступ разрешается. Поиск прекращается, если на любом из этапов будет найдено право Exclude, доступ не разрешается. Если права, соответствующие запрошенному доступу, не найдены, доступ не разрешается. Индивидуальные права, таким образом, имеют приоритет над групповыми, а групповые - над публичными.
В ряде случаев пользователю может понадобиться выполнить какую-либо корректную задачу, включающую в себя доступ к тем системным объектам, к которым процесс права доступа не имеет. Для выполнения этой задачи ОС предоставляет в распоряжение пользователя процесса программы-утилиты, которые гарантируют корректность манипуляций с защищенными объектами.
Но если такая утилита будет выполняться в контексте процесса пользователя, то есть, с его идентификатором безопасности, то в доступе ей будет отказано. Для решения этой проблемы применяется, так называемый, адаптивный доступ (adopted access). В дескрипторе исполняемого модуля - системной утилиты сохраняется признак, по которому ОС на время выполнения (только не время выполнения!) такого модуля предоставляет процессу, его вызвавшему, те же права, которые имеет создатель утилиты (привилегированный пользователь). Поскольку права предоставляются только на время выполнения утилиты, вызвавший ее пользователь этими правами воспользоваться не может.
Еще одно требование к системе безопасности - возможность контроля связанных с безопасностью событий, таких как вход в систему, попытки доступа к объектам (разрешенные или отклоненные), попытки использования полномочий и т.д. Контроль заключается в том, что информация о таких событиях сохраняется в системном журнале аудита и может быть впоследствии проанализирована системным администратором. Администратор имеет возможность задавать события и выбирать объекты, подлежащие контролю. Такой контроль обеспечивается списками контроля доступа, которые подобны спискам прав. Элемент такого списка для объекта содержит вид доступа, который подлежит протоколированию, и результат авторизации. После любого выполнении процедуры авторизации происходит поиск в списке контроля доступа, и, если найден элемент, в котором вид доступа и результат авторизации совпадают с произошедшим, в журнал аудита заносится отметка о событии (включая время и идентификатор пользователя).
Любые действия ОС по обеспечению безопасности (внутренние действия) не дадут желаемого эффекта, если они на будут поддержаны внешними действиями - системой организационных мероприятий, выполняемых администраторами системы, пользователями и их руководителями. Рассмотрение внешних действий по обеспечению безопасности не входит в наши задачи, упомянем только, что введение в эту область можно найти в [8, 20].
