На практике разрешения доступа редко хранятся в виде матрицы, показанной в табл. 2, поскольку такая матрица была бы очень большой и практически пустой. Поэтому, как правило, такие матрицы хранятся по рядам или столбцам, причем хранятся только непустые элементы. Эти два подхода различаются между собой. Рассмотрим хранение матрицы защиты по столбцам, далее познакомимся с методом ее хранения по рядам.
В первом методе с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки, называемые ACL-списками (Access Control List — список управления доступом) показаны на рис. 2. Здесь мы видим три процесса, принадлежащих различным доменам А, В и С, а также три файла, F1, F2 и F3. Для простоты будем предполагать, что каждому домену соответствует один пользователь,
в данном случае А, В и С.
Рис. 2. Использование ACL-списков для управления
доступом к файлам
С каждым файлом связан ACL-список. У файла F1 в его ACL-списке есть три записи (разделенные символом точка с запятой). В первой записи утверждается, что любой процесс, которым владеет пользователь А, может читать и писать этот файл. Во второй записи говорится, что любой процесс, которым владеет пользователь В, может читать этот файл. Все остальные типы доступа для данных пользователей запрещаются. Всем остальным пользователям запрещен любой доступ к этому файлу. Обратите внимание, что права предоставляются не процессу,
а пользователю. Таким образом, любой процесс, которым владеет пользователь А, может читать и писать файл F1. Не имеет значения, один такой процесс или их 100. Значение имеет идентификатор владельца, а не процесса.
У файла F2 в его ACL-списке есть три записи: пользователи А, В и С могут читать файл, а пользователь В также может писать в него. Другие типы доступа не разрешаются. Файл F3, по-видимому, представляет собой исполняемую программу, так как пользователи А и В могут как читать, так и исполнять его. Пользователю В также разрешается писать в этот файл.
Этот пример иллюстрирует самую общую форму защиты при помощи ACL-списков. Часто на практике используются более сложные системы. Начнем с того, что мы здесь показали только три типа доступа: чтение, запись и исполнение. Кроме них может быть еще много других типов доступа. Некоторые типы доступа могут быть применимы ко всем объектам, например уничтожение или копирование объекта, а некоторые могут быть специфическими для определенных объектов. Примеры подобных разрешений: добавить сообщение для объекта почтовый ящик и сортировать в алфавитном порядке для объекта каталог.
Многими системами поддерживается концепция групп пользо-вателей. У групп есть имена, и они также могут включаться в ACL-списки.
Иногда бывает так, что у какого-либо пользователя или группы есть определенные разрешения доступа к файлу, которые владелец файла хотел бы у них отнять. С помощью списков управления доступом аннулировать предоставленные ранее права доступа довольно просто. Все, что для этого нужно, — это отредактировать ACL-список, чтобы внести соответствующие изменения. Однако если ACL-список проверяется только при открытии файла, вероятнее всего, эти изменения затронут только последующие системные вызовы open. Любой уже открытый файл будет сохранять права на этот файл, полученные при его открытии, даже если пользователю вообще запретили любой доступ к этому файлу, но уже после того, как он открыл файл.
Перечни возможностей
Матрица, показанная в табл. 2, может также храниться по рядам. При использовании этого метода с каждым процессом ассоциирован список объектов, к которым может быть получен доступ, вместе с информацией о том, какие операции разрешены с каждым объектом, другими словами, доменом защиты объекта. Такой список называется перечнем возможностей, а его элементы называются возможностями. Пример трех процессов и их перечней возможностей показан на рис. 3.
Рис. 3. Использование ACL-списков для управления
доступом к файлам
Каждый элемент перечня возможностей предоставляет владельцу определенные права по отношению к определенному объекту. Например, на рис. 3 процесс, которым владеет пользователь А, может читать файлы F1 и F2. Обычно элемент перечня возможностей состоит из идентификатора файла (или, в более общем случае, объекта) и битового массива для различных разрешений. В операционных системах типа UNIX в качестве идентификатора файла может использоваться номер его i-узла. Перечни возможностей сами являются объектами и на них могут указывать другие перечни возможностей.
Очевидно, что перечни возможностей должны быть защищены от искажения их пользователями. Известны три способа их защиты. Для первого способа требуется теговая архитектура, т.е. аппаратно реализованная структура памяти, в которой у каждого слова памяти есть дополнительный (теговый) бит, сообщающий, содержит ли данное слово памяти элемент перечня возможностей или нет. Теговый бит не используется в обычных командах процессора, таких как арифметические или команды сравнения. Изменен он может быть только программой, работающей в режиме ядра (т.е. операционной системой). Машины с подобной архитектурой были построены и хорошо себя показали. В качестве популярного примера такой машины можно называть компьютер IBM AS/400.
Второй способ состоит в том, что перечень возможностей хранится внутри операционной системы. При этом к элементам перечня возможностей можно обращаться по их позиции в перечне. Процесс может запросить, например, прочитать 1 кбайт из файла, на который указывает элемент перечня возможностей номер 2. Такая форма адресации напоминает использование дескрипторов файла в UNIX.
Третий способ заключается в хранении перечня возможностей
в пространстве пользователя, но в зашифрованном виде, так чтобы пользователь не смог изменить эту информацию. Этот метод хорошо подходит для распределенных систем и работает следующим образом. Когда клиентский процесс отправляет сообщение удаленному серверу, например файловому серверу, чтобы создать объект для него, сервер создает объект, а также формирует большое случайное число, используемое как контрольное поле. В таблице файлового сервера для объекта резервируется запись, в которой также хранится контрольное поле, адреса дисковых блоков и т.д. В терминах системы UNIX контрольное поле хранится на сервере в i-узле. Оно не посылается пользователю и вообще никогда не попадает в сеть. Затем сервер формирует и передает пользователю элемент перечня возможностей, формат которого показан на рис. 4.
Рис. 4. Элемент перечня возможностей, защищенный
с помощью шифрования
Возвращаемый пользователю элемент перечня возможностей содержит идентификатор сервера, номер объекта (индекс в таблицах сервера, по сути, i-узел), а также права доступа, хранящиеся в виде битового массива. У только что созданного объекта все биты разрешений установлены в единицу. Последнее поле представляет собой результат функции f от конкатенации объекта, прав и контрольного поля.
Когда пользователь желает получить доступ к объекту, он отправляет в запросе серверу элемент перечня возможностей. Сервер извлекает из него номер объекта и использует его в качестве индекса для поиска объекта в своих таблицах. Затем он вычисляет f(Objects, Rights, Check), причем первые два параметра для этой функции он берет из присланного ему пользователем элемента перечня возможностей, а третий параметр из своих таблиц. Если результат совпадает с четвертым полем элемента перечня возможностей, запрос удовлетворяется, в противном случае он отвергается. Если пользователь пытается получить доступ к чужому объекту, он не сможет подделать четвертое поле, так как не знает значения контрольного поля.
Пользователь может попросить сервер создать элемент перечня возможностей с меньшими правами, например позволяющий только читать объект. Сначала сервер проверяет действительность элемента перечня возможностей. Если подпись совпадает, он вычисляет f(Objects, New_rights, Check) для нового разрешения и создает новый элемент перечня возможностей, помещая это значение в четвертое поле. Обратите внимание, что при этом используется оригинальное значение контрольного поля Check, так как от него зависят другие элементы перечня возможностей.
Этот новый элемент перечня возможностей посылается обратно запрашивающему процессу. Теперь пользователь может передать его, скажем, отправив по электронной почте своему другу. Если друг попытается установить в единицу какой-либо бит разрешения, сервер тут же обнаружит это, так как значение функции изменится. Поскольку другу не известно значение контрольного поля, он не сможет подделать элемент перечня возможностей так, чтобы тот соответствовал фальшивым битам разрешений. Эта схема была разработана для распределенной операционной системы Amoeba и активно в ней применялась.
Помимо специфических разрешений, зависящих от конкретного объекта, например чтение и исполнение, элементы перечня возможностей (как системные, так и защищенные шифрованием) содержат, как правило, общие права, т.е. разрешения выполнения действий, применимых ко всем объектам. Примерами таких действий являются:
1. Копирование элемента перечня возможностей: создание нового элемента перечня возможностей для того же объекта.
2. Копирование объекта: создание дубликата объекта с новым элементом перечня возможностей.
3. Удаление элемента перечня возможностей: удаление записи в перечне возможностей; объект при этом не затрагивается.
4. Удаление объекта: удаление объекта и элемента перечня возможностей.
Таким образом, ACL-списки и перечни возможностей обладают взаимодополняющими свойствами. Перечни возможностей очень эффективны, так как если процесс выдает запрос вида «Откройте файл, на который указывает элемент перечня возможностей 3», то не требуется никакой дополнительной проверки. При использовании ACL-списков для открытия файлов может потребоваться процесс поиска (возможно, долгий). Если группы не поддерживаются системой, тогда чтобы предоставить доступ чтения файла всем пользователям системы, потребуется перечислить всех пользователей в ACL-списке. Кроме того, перечни возможностей позволяют легко инкапсулировать процесс, чего не могут ACL-списки. С другой стороны, ACL-списки обеспечивают выборочное аннулирование разрешений, тогда как при использовании перечней возможностей это нереально. Наконец, если объект удаляется, а элемент перечня возможностей нет, или наоборот, возникают проблемы, которых лишены ACL-списки.
