Хотя это и не отражено в данном примере, один и тот же объект может иметь в различных доменах разные разрешения.

Домен 1 Домен 2 Домен 3

Рис. 5.20. Три домена защиты

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

Чтобы идея домена защиты выглядела более конкретно, рассмотрим пример из системы UNIX. В UNIX домен процесса определяется идентификаторами UID и GID процесса. По заданной комбинации (UID, GID) можно составить полный список всех объектов (файлов, включая устройства ввода/вывода, представленные в виде специальных файлов и т. д.), к которым процесс может получить доступ с указанием типа доступа (чтение, запись, исполнение). Два процесса с одной и той же комбинацией (UID, GID) будут иметь абсолютно одинаковый доступ к одинаковому набору объектов.

Более того, каждый процесс в UNIX состоит из двух частей: пользовательской и системной. Когда процесс обращается к системному вызову, он переключается из пользовательской части в системную. Пользовательская и системная части процесса различаются по уровню доступа к различным множествам объектов. Например, системная составляющая может иметь доступ ко всем страницам в физической памяти, ко всему диску и ко всем другим защищенным ресурсам. Таким образом, системный вызов осуществляет переключение доменов защиты.

Когда процесс выполняет системный вызов exec с файлом, у которого установлен бит SETUID или SETGID, процесс может получить новые идентификаторы UID и GID. При новой комбинации UID и GID процесс получает новый набор доступных файлов и операций. Запуск профаммы с установленным битом SETUID или SETGID также представляет собой переключение домена, так как права доступа при этом изменяются.

Важным вопросом является то, как система отслеживает, какой объект какому домену принадлежит. Можно себе представить большую матрицу, в которой рядами являются домены, а колонками - объекты. На пересечении располагаются ячейки, содержащие права доступа для данного домена к данному объекту. Матрица для рис. 5.20 показана на рис. 5.21. При наличии подобной матрицы

операционная система может для каждого домена определить разрешения к любому заданному объекту.

Переключение между доменами также легко реализуется при помощи все той же матрицы, если считать домены объектами, над которыми разрешена операция enter (вход). На рис. 5.22 снова изображена та же матрица, что и на предыдущем рисунке, но с тремя доменами, выступающими и в роли объектов. Процессы в состоянии переключаться с домена 1 на домен 2, но обратно вернуться уже не могут. Эта ситуация моделирует выполнение программы с установленным битом SETUID в UNIX. Другие переключения доменов в данном примере не разрешены.

Домен

Объект

Рис. 5.21. Матрица защиты Объект

Домен Плоттер 2 Домен 2

Файл 1 Файл 2 Файл 3 Файл 4 Файл 5 Файл 6 Принтер 1 Домен 1 Домен 3

Рис. 5.22. Матрица защиты с доменами в роли объектов

5.5.2. Списки управления доступом

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

Согласно первому методу, с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки называются ACL-списками (Access Control List - список управления доступом. Если бы данный способ управления доступом реализовывался в UNIX, проще всего было бы для каждого файла завести отдельный дисковый блок, хранящий список, и включить номер этого блока в г-узел файла. Так как здесь хранятся только заполненные ячейки матрицы доступа, места потребуется гораздо меньше, чем для хранения всей матрицы.

Как работают списки управления доступом, мы рассмотрим на примере UNIX, где домен определяется парой (UID, GID). Действительно, в системе MULTIX, по образу которой строилась UNIX, ACL работали примерно так же, поэтому пример не столь уж гипотетический.

Предположим, имеется четыре пользователя (то есть четыре UID): Jan, Els, Jelle и Maarike, которые входят соответственно в фуппы system, staff, student, student. Далее, предположим, что имеются файлы со следующими ACL:

FileO: (Jan, *, RWX) Filel: (Jan, system, RWX)

File2: (Jan, *, RW-), (Els, staff, RW-), (Maarike, *, RW-)

File3: (*, student, R-)

File4: (Jelle, *,---), (*, student, R-)

Каждая из записей ACL состоит из трех частей: UID, GID и разрешенные способы доступа: Read (чтение). Write (запись), eXecute (исполнение). Звездочка означает любую группу пользователей или любого пользователя. Тогда файл FileO могут читать, записывать и исполнять те процессы, у которых UID = Jan и с любым GID. Доступ к файлу Filel могут получить только процессы с UID = Jan и GID = system. Процесс, у которого UID = Jan и GID = staff, может обращаться к файлу FileO, а к файлу Filel - нет. Файл File2 вправе читать и изменять процессы с UID = Jan, независимо от GID, кроме того, его разрешено читать процессам с UID = Els и GID = staff, или с UID = Maarike и любым GID. Файл File3 могут читать любые студенты (группа student). Особенно интересен файл File4. ACL этого файла гласит, что любой процесс с UID = ЕИе, независимо от GID, не имеет к файлу никакого доступа, а всем остальным студентам он доступен. Благодаря ACL можно запретить доступ к объекту для отдельных пользователей или групп, в то же время разрешая доступ остальным представителям того же класса.

Итак, достаточно говорить о том, чего нет в UNIX. Давайте теперь изучим то, что есть. В UNIX выделяются группы из трех битов для владельца файла, группы владельцев и для остальных. Эта схема, опять же, является ACL, но, на этот раз, ужатым до 9 бит. Это ассоциированный с файлом список, описывающий, кому и что разрешено делать с файлом. Хотя принятая в UNIX 9-битная схема, очевидно, имеет меньше возможностей, чем полноценная система с ACL, на практике она вполне адекватна, а ее реализация намного проще и дешевле.

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