Добавлен: 29.10.2018
Просмотров: 48148
Скачиваний: 190
9.3. Управление доступом к ресурсам
671
Рис. 9.3. Матрица защиты
Рис. 9.4. Матрица защиты с доменами в качестве объектов
9.3.2. Списки управления доступом
На практике матрица, изображенная на рис. 9.4, используется довольно редко из-за
больших размеров и разряженного характера. Многие домены вообще не имеют доступа
ко многим объектам, следовательно, на хранение очень большой практически пустой
матрицы будет напрасно тратиться дисковое пространство. Поэтому практическое
применение нашли два метода: хранение матрицы по строкам или по столбцам, а затем
хранение только заполненных элементов. Как ни удивительно, но эти два подхода отли-
чаются друг от друга. В данном разделе будет рассмотрено хранение этой информации
по столбцам, а в следующем — по строкам.
В первом методе с каждым объектом ассоциируется упорядоченный список, содержа-
щий все домены, которым разрешен доступ к данному объекту, а также тип доступа.
Такой список, показанный на рис. 9.5, называется ACL (Access Control List — список
управления доступом). Здесь показаны три процесса, принадлежащие доменам A, B и C,
а также три файла: F1, F2 и F3. Чтобы упростить ситуацию, предположим, что каждому
домену соответствует только один пользователь, в данном случае это пользователи A,
B и C. Довольно часто в литературе по информационной безопасности пользователей
называют субъектами (subjects) или принципалами (principals), то есть пользователя-
ми, имеющими учетную запись в данной среде, чтобы отличать их владельцев некими
вещами, объектами (objects), к которым, к примеру, можно отнести файлы.
У каждого файла есть связанный с ним ACL. В ACL-списке файла F1 имеется две запи-
си (разделенные точкой с запятой). В первой записи сообщается, что любой процесс,
672
Глава 9. Безопасность
Рис. 9.5. Использование списков управления доступом для управления доступом к файлам
которым владеет пользователь A, может проводить в отношении этого файла операции
чтения и записи. Во второй записи сообщается, что любой процесс, которым владеет
пользователь B, может читать этот файл. Все остальные типы доступа для данных поль-
зователей и все виды доступа для остальных пользователей запрещаются. Обратите
внимание на то, что права предоставляются не процессу, а пользователю. В результате
работы системы защиты любой процесс, которым владеет пользователь A, может вы-
полнять операции чтения и записи в отношении файла F1. Сколько таких процессов,
один или сто, не имеет значения. Важно, кто владелец процесса, а не какой у процесса
идентификатор.
В ACL-списке файла F2 имеется три записи: пользователи A, B и C могут читать файл,
а пользователь B может также выполнять в него запись. Другие типы доступа не раз-
решаются. Очевидно, файл F3 представляет собой исполняемую программу, так как
пользователи A и B могут как читать, так и исполнять этот файл. Пользователю B также
разрешается вести в него запись.
Этот пример иллюстрирует самую общую форму защиты с помощью ACL-списков. На
практике зачастую применяются более сложные системы. Начнем с того, что здесь ото-
бражены всего лишь три права доступа: чтение, запись и исполнение. Кроме них могут
быть и другие права доступа. Часть прав может иметь общий характер, то есть распро-
страняться на все объекты, а часть может иметь специфическое отношение к объекту.
Примерами прав общего характера могут послужить право уничтожения объекта (destroy
object) и копирования объекта (copy object), они могут принадлежать любому объекту
независимо от его типа. К правам, имеющим специфическое отношение к объекту, можно
отнести право добавления сообщения (append message) для объекта почтового ящика
и право сортировки в алфавитном порядке (sort alphabetically) для объекта каталога.
До сих пор рассматриваемые записи в ACL-списке относились к отдельным пользовате-
лям. Многие системы поддерживают концепцию групп (group) пользователей. У групп
есть имена, и они также могут включаться в ACL-списки. Семантика групп имеет два
возможных варианта. В некоторых системах у каждого процесса есть идентификатор
пользователя UID и идентификатор группы GID. В таких системах ACL-списки со-
держат записи вида
UID1, GID1: права1; UID2, GID2: права2; ...
9.3. Управление доступом к ресурсам
673
При таких условиях, когда поступает запрос на доступ к объекту, выполняется про-
верка UID и GID того, кто выдал этот запрос. Если эти идентификаторы присутствуют
в ACL-списке, то предоставляются права, перечисленные в списке. Если комбинации
(UID, GID) в списке нет, доступ не разрешается.
По сути, использование групп вводит понятие роли (role). Рассмотрим вычислитель-
ный центр, в котором Тана является системным администратором и поэтому входит
в группу sysadm. Но предположим, что в компании есть также клубы для сотрудников
и Тана является членом клуба любителей голубей. Члены клуба принадлежат к группе
pigfan и имеют доступ к компьютерам компании для ведения своей голубиной базы
данных. Часть ACL-списка может иметь вид, представленный в табл. 9.2.
Таблица 9.2. Два списка управления доступом
Файл
Список управления доступом
Password
tana, sysadm: RW
Pigeon data
bill, pigfan: RW; tana, pigfan: RW;
Если Тана пытается получить доступ к одному из этих файлов, то результат зависит от
того, в какую группу она вошла. Во время регистрации система может спросить, какой
из своих групп она намерена воспользоваться, или у нее могут быть разные имена и/
или пароли для того, чтобы хранить входы в группы по отдельности. Суть этой схемы
состоит в том, чтобы Тана не могла иметь доступа к файлу паролей в тот момент, ког-
да она занята своим голубиным хобби. Доступ к файлу паролей она может получить
только в том случае, если зарегистрируется в системе как системный администратор.
В некоторых случаях пользователю может предоставляться доступ к определенным
файлам независимо от того, к которой группе он принадлежит в данный момент. Это
можно устроить за счет использования группового символа (wildcard), означающего
все, что угодно. К примеру, запись
tana, *:RW
в файле паролей предоставит Тане доступ независимо от того, к какой группе она
в данный момент принадлежит.
Еще одна возможность заключается в том, что пользователь, входящий в любую из
групп и имеющий определенные права доступа, получает эти права. Преимущество
состоит в том, что пользователь, входящий одновременно в несколько групп, при
регистрации не должен указывать, какую группу следует использовать. Все они учи-
тываются на протяжении всей его работы. Недостаток такого подхода заключается
в том, что он предоставляет меньшую степень инкапсуляции, поскольку теперь Тана
может редактировать файл паролей во время собрания голубиного клуба. Использова-
ние групп и групповых символов дает возможность выборочно заблокировать доступ
к файлу со стороны определенного пользователя. Например, запись
virgil, *: (none); *, *:RW
предоставляет возможность доступа к файлу для чтения и записи всем, кроме пользо-
вателя с именем Вирджил (Virgil). Эта запись срабатывает благодаря тому, что записи
сканируются по порядку и из них берется первая подходящая, а последующие записи
даже не анализируются. В первой же записи находятся подходящее имя Virgil и права до-
674
Глава 9. Безопасность
ступа — в данном случае none (то есть отсутствие каких-либо прав), которые и вступают
в силу. Тот факт, что все остальные имеют доступ, не удостаивается никакого внимания.
Другой способ работы с группами заключается в том, что записи ACL-списка состав-
лены не из пар (UID, GID), а содержат либо UID, либо GID. Например, запись для
файла
pigeon_data
может иметь следующий вид:
debbie: RW; phil: RW; pigfan: RW
означающий, что Дебби и Фил, а также все члены группы pigfan могут обращаться
к этому файлу для чтения и записи.
Случается, что у какого-нибудь пользователя или группы есть определенные права
доступа к файлу, которых владелец этого файла впоследствии может их лишить. При
использовании списков управления доступом отзыв ранее предоставленных прав
осуществляется довольно просто. Нужно лишь отредактировать ACL-список и внести
в него соответствующие изменения. Однако если ACL-список проверяется только при
открытии файла, то, вероятнее всего, эти изменения вступят в силу лишь при следующем
системном вызове open. На любой уже открытый файл будут сохраняться права, полу-
ченные при его открытии, даже если у пользователя уже нет прав доступа к этому файлу.
9.3.3. Перечни возможностей
Матрицу, показанную на рис. 9.5, можно также разрезать по строкам. При использо-
вании этого метода с каждым процессом будет связан список объектов, к которым
может быть получен доступ, а также информация о том, какие операции разрешены
с каждым объектом, иными словами, с ним будет связан его домен защиты. Такой
список называется перечнем возможностей (capability list, C-list), а его элементы —
возможностями
(capabilities) (Dennis and Van Horn, 1966; Fabry, 1974). Набор из трех
процессов и перечней их возможностей показан на рис. 9.6.
Рис. 9.6. При использовании возможностей каждый процесс получает их перечень
Каждый элемент перечня возможностей предоставляет владельцу определенные права
по отношению к определенному объекту. К примеру, на рис. 9.6 процесс, которым владе-
ет пользователь A, может читать файлы F1 и F2. Обычно элемент перечня возможностей
9.3. Управление доступом к ресурсам
675
состоит из идентификатора файла (или, в более общем случае, объекта) и битового
массива для различных прав. В операционных системах семейства UNIX в качестве
идентификатора файла может использоваться номер его i-узла. Перечни возможностей
сами являются объектами, и на них могут указывать другие перечни возможностей,
облегчая, таким образом, совместное использование субдоменов.
Вполне очевидно, что перечни возможностей должны быть защищены от подделки
со стороны пользователей. Известны три способа их защиты. Для первого способа
требуется теговая архитектура (tagged architecture), то есть аппаратная конструкция,
в которой каждое слово памяти имеет дополнительный (теговый) бит, сообщающий,
содержит данное слово памяти элемент перечня возможностей или нет. Теговый бит
не используется в обычных командах, к которым относятся арифметические действия,
сравнения или им подобные команды, и может быть изменен только программами,
работающими в режиме ядра (то есть операционной системой). Машины с теговой ар-
хитектурой были созданы и могли быть настроены на успешную работу (Feustal, 1972).
Наиболее распространенным примером такой машины может послужить IBM AS/400.
Второй способ заключается в хранении перечня возможностей внутри операционной
системы. При этом к элементам перечня возможностей можно обращаться по их по-
зиции в перечне. Процесс может запросить, например, чтение 1 Кбайт из файла, на
который указывает элемент перечня возможностей номер 2. Такая форма адресации
напоминает использование дескрипторов файла в UNIX. Именно таким образом ра-
ботала система Hydra (Wulf et al., 1974).
Третий способ заключается в хранении перечня возможностей в пространстве поль-
зователя, но в зашифрованном виде, так чтобы пользователь не смог подделать эту
информацию. Такой подход особенно хорош для распределенных систем и работает
следующим образом. Когда клиентский процесс отправляет сообщение удаленному
серверу, например файловому серверу, чтобы для него был создан объект, сервер созда-
ет объект, а также генерирует сопутствующее ему большое случайное число, используе-
мое как контрольное поле. В таблице файлов сервера для объекта резервируется запись,
в которой контрольное поле хранится наряду с адресами дисковых блоков. В понятиях
системы UNIX контрольное поле хранится на сервере в i-узле. Оно не отправляется
пользователю и вообще никогда не попадает в сеть. Затем сервер формирует и передает
пользователю элемент перечня возможностей, формат которого показан на рис. 9.7.
Рис. 9.7. Криптографически защищенный элемент перечня возможностей
Возвращаемый пользователю элемент перечня возможностей содержит идентификатор
сервера, номер объекта (индекс в таблицах сервера, по сути, — номер i-узла), а также
права доступа, хранящиеся в виде битового массива. У только что созданного объекта
все биты прав доступа установлены в единицу, поскольку само собой разумеется, что
владелец может делать все, что ему заблагорассудится. Последнее поле представляет
собой конкатенацию объекта, прав и контрольного поля, пропущенную через крип-
тостойкую одностороннюю функцию f (y = f(x)), позволяющую при наличии x легко
получить y, но обратный процесс — при наличии y получить x — невозможен. Под-
робно функция будет рассматриваться в разделе 9.5. А сейчас достаточно знать, что