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

 

На практике разрешения доступа редко хранятся в виде матрицы, пока­занной в табл. 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-списки.