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

В общем случае совокупность всех списков контроля доступа (ACL) в системе представляет собой трёхмерную матрицу, строки которой соответствуют пользователям, столбцы — операциям над объектами, а слои — самим объектам. С ростом количества объектов и пользователей в системе объём этой матрицы быстро растёт. Поэтому разработчики реальных систем контроля доступа предпринимают различные меры для более компактного представления матрицы.

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

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

Рис. 12.9. Список контроля доступа

Есть три основных подхода, используемых для сокращения ACL:

• Использование прав по умолчанию
• Группирование пользователей и/или объектов
• Ограничение комбинаций прав, которыми пользователи и группы могут реально обладать

Права по умолчанию дают наибольший эффект тогда, когда большая часть прав большинства пользователей на большинство объектов одинакова. Чаще всего рекомендуют при установлении прав исходить из принципа "запрещено всё, что не разрешено [явным образом]". При последовательном его применении должно получаться, что большинство пользователей не имеет прав на подавляющую часть объектов в системе. В большинстве систем пользователи, явно или неявно не перечисленные в ACL объекта, не имеют на объект никаких прав. Многие системы также предоставляют специальную запись в ACL, соответствующую пользователям, которые не перечислены явно.

Объединение пользователей в группы представляет собой более универсальное средство, которое полезно не только для сокращения ACL, но и для других целей. Группа вводит дополнительный уровень косвенности (ACL ссылается на пользователя не прямо, а косвенно, через группу). Это даёт дополнительную гибкость, полезную во многих практических случаях (рис. 12.10).

Рис. 12.10. Группы пользователей

Так, в большинстве случаев полномочиями наделяют человека не за то, что он такой хороший, а потому, что они нужны ему для выполнения служебных обязанностей. Изменение служебных обязанностей (постоянное, при переходе на другую должность, или временное, например, при замене заболевшего или ушедшего в отпуск сотрудника) сопровождается изменением прав, которыми пользователь должен обладать.

В этой ситуации целесообразно создать группу, соответствующую той или иной должности, и выдавать права на объекты этой группе. Назначение человека на должность сопровождается включением его в соответствующую группу, а снятие — исключением из неё. Без использования групп эти операции потребовали бы явной модификации ACL всех объектов, права на которые изменяются, что во многих случаях является совершенно нерациональным.

Группы являются практически обязательным элементом систем управления правами на основе списков. Большинство систем предоставляет возможность создания вложенных групп (рис. 12.11). Ряд современных систем (например, Novell Netware, Windows 2000, Solaris 6) также предлагают иерархические структуры баз данных учётных записей, называемые службами каталогов (NDS - Netware Directory Service в Netware, Active Directory в Windows, NIS+ - Network Information Service в Solaris). Впервые служба каталогов была реализована в сетевой операционной системе VINES фирмы Banyan Systems в конце 80-х годов.

Рис. 12.11. Вложенные группы и структура организации

Иерархическая структура особенно удобна для больших организаций, потому что она не только обеспечивает "естественную" структуру вложенных групп, но и облегчает просмотр учётных записей и управление ими.

При активном использовании групп пользователей может возникнуть специфическая проблема: пользователь может состоять в нескольких группах и иметь собственную запись в ACL, и таким образом, получать права на объект несколькими путями (рис. 12.12). Строго говоря, это не является проблемой, важно лишь описать, что будет происходить с правами в этом случае. В различных системах используются почти все мыслимые варианты поведения.

Рис. 12.12. Получение прав из нескольких групп

Чаще всего права, полученные разными путями, просто складываются. Бывают системы, в которых отдельные права тем или иным образом ранжируются, и пользователь получает список прав, соответствующий той записи в ACL, которая содержит наивысшее право. Очень часто некоторые записи в ACL обладают особым статусом. Так, если человек имеет явную запись в ACL (соответствующую его пользовательскому идентификатору), то записанные в ней права оказываются "сильнее" всех прав, которые он получает как член группы. Запись с правами по умолчанию часто рассматривается как более "слабая", чем явные и групповые записи, и при наличии у пользователя прав, полученных из записей по умолчанию, они игнорируются.

Каждое из этих правил по отдельности обычно преследует цель облегчить формирование списков, предоставляющих требуемые комбинации прав, но в результате полное описание семантики ACL многих распространённых операционных систем напоминает вынесенные в эпиграф фрагменты правил игры в "драконий покер".

Группирование объектов используется несколько реже, но также является мощным средством управления правами и сокращения общего объёма ACL в системе. Для файловых систем естественным средством группирования является иерархия каталогов.

Наследование прав на файлы в Novell Netware

По-видимому, наибольшей сложности группирование объектов достигло в системе Novell Netware. Рассмотрим схему установления прав на файлы в этой операционной системе.

Запись файлового ACL в Netware представляет собой битовую маску, значения разрядов которой перечислены в таблице 12.1. Видно, что некоторые из прав имеют смысл только для файлов, а некоторые — только для каталогов.

Каталоги и файлы в этой системе наследуют права доступа от родительских каталогов. Если пользователь или группа не перечислены явно в ACL объекта, их эффективные права будут определяться записями в ACL родительских каталогов (рис. 12.13). Если пользователь перечислен в ACL родительского и дочернего каталогов, его эффективные права будут равны сумме прав, указанных в обеих записях. Таким образом, по мере спуска по дереву каталогов эффективные права могут только возрастать.

Рис. 12.13. Наследование прав на каталоги в Novell Netware (обозначения прав соответствуют таблице 12.1)

При этом пользователь не обязан иметь права на каталог, чтобы видеть его файлы и подкаталоги. Поэтому система управления доступом Netware предполагает выдачу прав как можно ближе к файлам, права на которые необходимы. Права на корневые каталоги томов обычно выдаются только администратору системы.

Если потребуется изменить принцип расширения прав по мере спуска по дереву, каталоги и файлы, кроме ACL, имеют дополнительный атрибут, называемый IRF (Inherited Rights Filter — фильтр наследуемых прав). Этот атрибут представляет собой битовую маску, биты которой (кроме бита S — он не может быть отфильтрован) соответствуют битам записи ACL. Установка бита в этой маске приводит к блокировке наследования соответствующего права (рис. 12.14).

Рис. 12.14. Фильтр наследуемых прав в Novell Netware

Запрет на фильтрацию права супервизора обусловлен тем, что его включение по ошибке приведёт к потере прав на эту иерархию. Избавиться от такого поддерева можно было бы только переразметкой тома.

В пользовательской базе данных, которая начиная с Netware 4.x также имеет иерархическую структуру и наследование, блокирование супервизорских прав разрешено. Это позволяет по ошибке "даровать суверенитет" ветви дерева (рис. 12.15). Это одна из распространённых ошибок начинающих администраторов. В административных утилитах Netware 4.11 была введена специальная проверка, которая не позволяет отфильтровать право супервизора, если ни у кого нет явно выданных супервизорских прав на соответствующий контейнер или объект.

Рис. 12.15. Дарование суверенитета ветви дерева каталогов

Таблица 12.1. Права доступа к файлу в Novell Netware 3.x и выше

Альтернативой этим подходам является третий из упомянутых путей — ограничение комбинаций прав, которые реально могут быть выданы. С одним из примеров такого ограничения мы сталкивались ранее: диспетчер памяти VAX имеет четыре уровня привилегий, каждый из которых может иметь право чтения и записи в страницу памяти. Все возможные комбинации прав в этих условиях кодируются 8-ю битами, но наложение требования о том, что каждый более высокий уровень обязан иметь хотя бы те же права, что и более низкие, позволяет нам обойтись 15-ю допустимыми комбинациями и 4-мя битами для их кодирования.

При разработке такой системы нам нужно выработать такие ограничения, которые не только обеспечивали бы компактное представление ACL, но и позволяли так или иначе реализовать комбинации прав, необходимые для практической эксплуатации вычислительных систем. Примером ограниченного ACL, структура которого выдержала 30-летнюю проверку практикой, является модель безопасности в системах семейства Unix.

Авторизация в Unix

В этих системах ACL состоит ровно из трёх записей (рис. 12.16):

• Права хозяина файла (пользователя)
• Права группы
• Права по умолчанию

Рис. 12.16. Установление прав в системах семейства Unix

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

Бывают три права: чтения, записи и исполнения. Для каталога право исполнения означает право на открытие файлов в этом каталоге. Каждое из прав обозначается битом в маске прав доступа, т. е. все три группы прав представляются девятью битами или тремя восьмеричными цифрами.

Прав на удаление или переименование файла не существует; вообще, в Unix не определена операция удаления файла как таковая, а существует лишь операция удаления имени unlink. Это связано с тем, что файл в Unix может иметь несколько имен, и собственно удаление происходит только при уничтожении последнего имени (подробнее см. главу 11).

Удаление файлов из каталога, в действительности, можно в определённых пределах контролировать: установка дополнительного бита в маске прав запрещает удаление из каталога чужих файлов. Обладатель права записи в такой каталог может создавать в нём файлы и удалять их, но только до тех пор, пока они принадлежат ему.

Кроме прав, перечисленных в маске, хозяину файла разрешается изменять права на файл: модифицировать маску прав и передавать файл другой группе и, если это необходимо, другому пользователю (в системах с дисковыми квотами передавать файлы обычно запрещают).

Ещё один обладатель прав на файл, не указанный явно в его ACL, — это администратор системы, пользователь с идентификатором, равным 0. Этот пользователь традиционно имеет символическое имя root. Полномочия его по отношению к файлам, другим объектам и системе в целом правильнее описать даже не как обладание всеми правами, а как возможность делать с представленными в системе объектами что угодно, не обращая внимания на права.

Рис. 12.17. Дерево каталогов Unix

Многолетний опыт эксплуатации систем, использующих эту модель, показывает, что она вполне адекватна подавляющему большинству реальных ситуаций. Впрочем, ряд современных файловых систем в ОС семейства Unix предоставляет произвольного вида списки для управления доступом.