Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
Механизмы защиты
Предлагаем Вашему вниманию главу из книги Э.═Таненбаума ╚Современные операционные системы╩. Издательство "Питер". 2002 г.
Окончание. Начало ╚КИ╩ ╧ 01/2003, стр. 22
Использование групп вводит понятие роли. Рассмотрим систему, в которой Тана является системным администратором, и поэтому входит в группу sysadm. Однако предположим, что в компании есть также клубы для сотрудников, и Тана является членом клуба любителей голубей. Члены клуба принадлежат к группе pigfan и обладают доступом к компьютерам компании для управления своей голубиной базой данных. Часть ACL-списка может быть показана в таблице.
| Файл | Список управления доступом |
| Password | tana, sysadm: RW |
| Pigeon_data | bill, pigfan: RW; tana, pigfan: RW;... |
Если Тана пытается получить доступ к одному из этих файлов, результат зависит от того, под какой учетной записью она зарегистрировалась в системе. Во время регистрации система может попросить ее выбрать группу, которую она намеревается использовать. Также Тана может зарегистрироваться в системе под различными именами. Цель этой схемы состоит в том, чтобы Тана не могла иметь доступа к файлу паролей, когда занимается голубями. Доступ к файлу паролей она может получить только в том случае, когда регистрируется в системе как системный администратор.
В некоторых случаях пользователю может предоставляться доступ к определенным файлам независимо от того, к какой группе он принадлежит в данный момент. Эта ситуация в записи ACL-списка может обозначаться, например, символом звездочки, означающей все группы. Так, запись
tana,*: RW
для файла паролей предоставила бы Тане доступ к нему независимо от того, к какой группе Тана принадлежит в данный момент.
Кроме того, права доступа могут предоставляться пользователю, принадлежащему к определенной группе, если эти права предоставлены всей группе. В данном случае пользователь, принадлежащей одновременно к нескольким группам, не должен задумываться, какую группу указывать во время регистрации. При такой схеме членство в группах является постоянным и не указывается при регистрации в системе. Недостаток такого подхода заключается в том, что он предоставляет меньшую степень инкапсуляции: Тана может редактировать файл паролей во время собрания голубиного клуба.
С помощью групп и символов звездочки можно селективно блокировать определенного пользователя, отказав ему в доступе к конкретному файлу. Например, запись
hacker,*: (none); *,*: RW
предоставляет разрешения чтения и записи файла всем пользователям, кроме пользователя hacker. Это работает, так как записи сканируются слева направо, и выбирается первая подходящая; последующие записи даже не изучаются. Следовательно, находится запись hacker, и соответствующий ей уровень доступа (none), то есть никакого. На этом поиск прекращается.
Другая схема работы с группами заключается в том, что записи ACL-списка состоят не из пар (UID, GID), а просто содержат только UID или GID. Например, запись для файла pigeon_data может выглядеть следующим образом:
debbie: RW; phil: RW; pigfan: RW
означая, что Дебби и Фил, а также все члены группы pigfan могут читать и писать этот файл.
Иногда бывает так, что у какого-либо пользователя или группы есть определенные разрешения доступа к файлу, которые владелец файла хотел бы у них отнять. С помощью списков управления доступом аннулировать предоставленные ранее права доступа довольно просто. Все, что для этого нужно ≈ это отредактировать ACL-список, чтобы внести соответствующие изменения. Однако если ACL-список проверяется только при открытии файла, вероятнее всего, эти изменения затронут только последующие системные вызовы open. Любой уже открытый файл будет сохранять права на этот файл, полученные при его открытии, даже если пользователю вообще запретили любой доступ к этому файлу, но уже после того, как он открыл файл.
Матрица защиты с доменами в роли объектов может также храниться по рядам. При использовании этого метода с каждым процессом ассоциирован список объектов, к которым может быть получен доступ, вместе с информацией о том, какие операции разрешены с каждым объектом, другими словами, доменом защиты объекта. Такой список называется перечнем возможностей, а его элементы называются возможностями. Пример трех процессов и их перечней возможностей показан на рис.═1.
Рис. 1. Использование ACL-списков для управления доступом к файлам
Каждый элемент перечня возможностей предоставляет владельцу определенные права по отношению к определенному объекту. Например, на рис.═1 процесс, которым владеет пользователь A, может читать файлы F1 и F2. Обычно элемент перечня возможностей состоит из идентификатора файла (или, в более общем случае, объекта) и битового массива для различных разрешений. В операционных системах типа UNIX в качестве идентификатора файла может использоваться номер его i-узла. Перечни возможностей сами являются объектами и на них могут указывать другие перечни возможностей, таким образом облегчая совместное использование субдоменов.
Очевидно, что перечни возможностей должны быть защищены от искажения их пользователями. Известны три способа их защиты. Для первого способа требуется теговая архитектура, то есть аппаратно реализованная структура памяти, в которой у каждого слова памяти есть дополнительный (теговый) бит, сообщающий, содержит ли данное слово памяти элемент перечня возможностей или нет. Теговый бит не используется в обычных командах процессора, таких как арифметические или команды сравнения. Изменен он может быть только программой, работающей в режиме ядра (то есть операционной системой). Машины с подобной архитектурой были построены, и хорошо себя показали. В качестве популярного примера такой машины можно называть компьютер IBM AS/400.
Второй способ состоит в том, что перечень возможностей хранится внутри операционной системы. При этом к элементам перечня возможностей можно обращаться по их позиции в перечне. Процесс может запросить, например, прочитать 1 Кбайт из файла, на который указывает элемент перечня возможностей номер 2. Такая форма адресации напоминает использование дескрипторов файла в UNIX. Именно таким образом работала система Hydra.
Третий способ заключается в хранении перечня возможностей в пространстве пользователя, но в зашифрованном виде, так чтобы пользователь не смог изменить эту информацию. Этот метод хорошо подходит для распределенных систем и работает следующим образом. Когда клиентский процесс отправляет сообщение удаленному серверу, например файловому серверу, чтобы создать объект для него, сервер создает объект, а также формирует большое случайное число, используемое как контрольное поле. В таблице файлового сервера для объекта резервируется запись, в которой также хранится контрольное поле, адреса дисковых блоков и т. д. В терминах системы UNIX контрольное поле хранится на сервере в i-узле. Оно не посылается пользователю и вообще никогда не попадает в сеть. Затем сервер формирует и передает пользователю элемент перечня возможностей, формат которого показан на рис. 2.
Рис. 2. Элемент перечня возможностей, защищенный с помощью шифрования
Возвращаемый пользователю элемент перечня возможностей содержит идентификатор сервера, номер объекта (индекс в таблицах сервера, по сути, i-узел), а также права доступа, хранящиеся в виде битового массива. У только что созданного объекта все биты разрешений установлены в единицу. Последнее поле представляет собой результат необратимой функции f от конкатенации объекта, прав и контрольного поля. Такая функция уже обсуждалась ранее.
Когда пользователь желает получить доступ к объекту, он отправляет в запросе серверу элемент перечня возможностей. Сервер извлекает из него номер объекта и использует его в качестве индекса для поиска объекта в своих таблицах. Затем он вычисляет f (Objects, Rights, Check), причем первые два параметра для этой функции он берет из присланного ему пользователем элемента перечня возможностей, а третий параметр из своих таблиц. Если результат совпадает с четвертым полем элемента перечня возможностей, запрос удовлетворяется, в противном случае он отвергается. Если пользователь пытается получить доступ к чужому объекту, он не сможет подделать четвертое поле, так как не знает значения контрольного поля.
Пользователь может попросить сервер создать элемент перечня возможностей с меньшими правами, например позволяющий только читать объект. Сначала сервер проверяет действительность элемента перечня возможностей. Если подпись совпадает, он вычисляет f (Objects, New_rights, Check) для нового разрешения и создает новый элемент перечня возможностей, помещая это значение в четвертое поле. Обратите внимание, что при этом используется оригинальное значение контрольного поля Check, так как от него зависят другие элементы перечня возможностей.
Этот новый элемент перечня возможностей посылается обратно запрашивающему процессу. Теперь пользователь может передать его, скажем, отправив по электронной почте своему другу. Если друг попытается установить в единицу какой-либо бит разрешения, сервер тут же обнаружит это, так как значение функции f изменится. Поскольку другу неизвестно значение контрольного поля, он не сможет подделать элемент перечня возможностей так, чтобы тот соответствовал фальшивым битам разрешений. Эта схема была разработана для распределенной операционной системы Amoeba и активно в ней применялась.
Помимо специфических разрешений, зависящих от конкретного объекта, например чтение и исполнение, элементы перечня возможностей (как системные, так и защищенные шифрованием) содержат, как правило, общие права, то есть разрешения выполнения действий, применимых ко всем объектам. Примерами таких действий являются:
1. Копирование элемента перечня возможностей: создание нового элемента перечня возможностей для того же объекта.
2. Копирование объекта: создание дубликата объекта с новым элементом перечня возможностей.
3. Удаление элемента перечня возможностей: удаление записи в перечне возможностей; объект при этом не затрагивается.
4. Удаление объекта: удаление объекта и элемента перечня возможностей.
Напоследок стоит отметить, что аннулирование доступа к объекту в системах перечней возможностей, реализованных на уровне ядра, довольно сложно. Системе трудно найти все элементы перечня возможностей для конкретного объекта, чтобы забрать их, так как они могут храниться в перечнях возможностей по всему диску. Один из методов заключается в том, что элемент перечня возможностей должен указывать не на сам объект, а на косвенный объект. Система может в любой момент разорвать связь между объектом и указывающим на него косвенным объектом, таким образом аннулируя все возможности. (Когда элемент перечня возможностей позднее появляется в системе, пользователь обнаружит, что косвенный объект теперь указывает на нулевой объект.)
В системе Amoeba аннулирование разрешений выполняется легко. Все, что для этого требуется ≈ это изменить контрольное поле, хранимое с объектом. В результате одного удара все существующие элементы перечня возможностей становятся недействительными. Однако ни одна схема не обеспечивает выборочного аннулирования разрешений, то есть невозможно, например, аннулировать разрешения Джона, не затронув всех остальных. Этот недостаток присущ всем системам перечней возможностей.
Другая проблема состоит в том, чтобы гарантировать, что владелец действительного элемента перечня возможностей не раздаст его копию 1000 своих лучших друзей. Эта проблема решается в системах типа Hydra, в которых перечнями возможностей управляет ядро, но подобное решение не работает в распределенных системах, таких как Amoeba.
С другой стороны, перечни возможностей позволяют очень элегантно решить проблему помещения мобильной программы в песочницу. При запуске чужая программа получает список возможностей, содержащий только те возможности, которые владелец машины согласен ей предоставить, например возможность вывода на экран и чтения и записи файлов из одного временного каталога, специально созданного для этой программы. Если мобильная программа помещается в собственный процесс только с этими ограниченными возможностями, она не сможет получить доступ к другим системным ресурсам. Таким образом, программа оказывается в песочнице, для чего не требуется модификация кода или интерпретация программы. Запуск программы с минимальным набором прав доступа, называемый принципом наименьшего уровня привилегий, представляет собой мощное средство при создании защищенных систем.
Итак, кратко подведем итоги. ACL-списки и перечни возможностей обладают взаимодополняющими свойствами. Перечни возможностей очень эффективны, так как если процесс выдает запрос вида ╚Откройте файл, на который указывает элемент перечня возможностей 3╩, то не требуется никакой дополнительной проверки. При использовании ACL-списков для открытия файлов может потребоваться процесс поиска (возможно, долгий). Если группы не поддерживаются системой, тогда, чтобы предоставить доступ чтения файла всем пользователям системы, потребуется перечислить всех пользователей в ACL-списке. Кроме того, перечни возможностей позволяют легко инкапсулировать процесс, чего не могут ACL-списки. С другой стороны, ACL-списки обеспечивают выборочное аннулирование разрешений, тогда как при использовании перечней возможностей это нереально. Наконец, если объект удаляется, а элемент перечня возможностей нет или наоборот, возникают проблемы, которых лишены ACL-списки.
КОМПЬЮТЕР-ИНФОРМ Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
e-mail:
Для пресс-релизов и новостей