<<
>>

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

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

Согласно первому методу, с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки называются списками управления доступом (Access Control List, ACL, рис. 5.24). На нем изображены три процесса, А, Б и С, принадлежащие разным доменам, и три файла, F1, F2 и F3. Для простоты предположим, что каждый домен соответствует ровно одному пользователю, в данном случае, А, Б и С.

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

Рис. 5.24. Использование списков управления доступом применительно к файлам

С каждым файлом связан список управления доступом. АСЬ файла Р1 состоит из двух записей, разделенных точкой с запятой. Первая запись указывает на то, что любой процесс пользователя А может читать и писать в файл, а вторая — на то, что пользователь В может читать файл. Другие виды доступа для этих пользователей, а также все виды доступа для остальных пользователей запрещены.

Обратите внимание на то, что права назначены не процессам, а пользователям. С точки зрения системы защиты, любой процесс, владельцем которого является пользователь А, имеет право читать и писать в файл Р1. Не имеет значения, сколько таких процессов — один или сто; учитывается не идентификатор процесса, а его владелец.

У файла F2 в ACL три записи: пользователи А, В и С могут читать файл, а, кроме того, В имеет право записи в него. Все прочие виды доступа запрещены. Файл F3, очевидно, является исполняемой программой, поскольку пользователи В и С могут читать и исполнять его. Процесс В также имеет разрешение на запись в F3.

Данный пример демонстрирует простейшую форму защиты посредством ACL. Механизмы, используемые на практике, более сложны. Для начала мы показали лишь три права: на чтение, на запись и на исполнение. Существуют и другие права: например, широко распространены права на копирование и уничтожение объекта. Они имеются у любого объекта независимо от его типа. Возможны права, специфичные для конкретных объектов. Например, у объекта «почтовый ящик» существует право на добавление сообщения, а у объекта «каталог» — право сортировки в алфавитном порядке.

До настоящего момента мы говорили о ACL-записях, соответствующих отдельным пользователям. Многие системы поддерживают концепцию групп пользователей. Группы имеют имена и могут включаться в ACL. Для групп поддерживаются два вида семантики. В некоторых системах у каждого процесса есть идентификатор пользователя (UID) и идентификатор группы (GID). В этом случае ACL-запись выглядит следующим образом:

UIDl, GID1: права1; UID2 , GID2: права 2; ...

При получении запроса на доступ к объекту проверяется наличие UID и GID процесса в ACL, и, если эти идентификаторы удается найти, применяются перечисленные права. В противном случае в доступе отказывается.

Подобное использование групп приводит к концепции роли. Рассмотрим систему, в которой пользователь tana является системным администратором, а следовательно, входит в группу sysadm. Пусть в компании имеется несколько клубов для сотрудников, и tana входит в сообщество любителей голубей.

Члены этого сообщества принадлежат группе pigf ап и имеют возможность управлять собственной базой данных с компьютеров компании. В табл. 5.4 приведен фрагмент списка управления доступом.
Таблица 5.4. Два списка управления доступом
Файл Список управления доступом
Password tana, sysadm: RW
Pigeon_data bill, pigfan: RW; tana, pigfan: RW;

Если tana попытается получить доступ к одному из этих файлов, результат зависит от того, к какой группе этот пользователь принадлежит в текущий момент. Возможно, при входе система просит его указать группу, в которую он хотел бы войти; не исключено, что для разделения групп каждой из них даже соответствуют свои имена входа и (или) пароли. Цель такой схемы — лишить пользователя tana возможности доступа к файлу паролей, если он вошел в систему как член сообщества любителей голубей. Он может работать с файлом паролей только как системный администратор.

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

tana, *: RW

Запись подобного вида дает пользователю tana доступ к файлу паролей независимо от того, в какой группе он находится в текущий момент.

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

Применение групп и масок позволяет выборочно блокировать доступ пользователей к файлам. Например:

virgil, *: (none); *.*: RW

Эта запись дает возможность всем, кроме пользователя virgil, читать и писать в файл. Такой эффект достигается потому, что записи сканируются в порядке перечисления и применяется первая подходящая (остальные же записи даже не проверяются). Для virgil такой записью является первая; в ней указано отсутствие каких-либо прав (попе). На этом поиск заканчивается, и то, что все остальные пользователи имеют права доступа, остается «за кадром».

Другой способ работы с группами предполагает, что в ACL-записях задействованы не пары (UID, GID), а один из этих идентификаторов. Например, для файла pigeon_data запись может выглядеть следующим образом:

debbie: RW; phil: RW; pigfan: RW

Она означает, что пользователи debbie, phil и все члены группы pigfan имеют право чтения и записи.

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

5.5.3.

<< | >>
Источник: Э. ТАНЕНБАУМ, А. ВУДХАЛЛ. ОПЕРАЦИОННЫЕ СИСТЕМЫ Разработка и реализация 3-е издание. 2007

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

  1. Метод Ключ – защита от стресса и доступ к управлению внутренними ресурсами
  2. Номер один в списке неправильных действий
  3. 3. Доступ к источникам информации.
  4. Статья 1040. Обращение взыскания на имущество, переданное в управление, по требованию кредитора установщика управления
  5. Прямой доступ к информации и предузнавание
  6. Непосредственный доступ и предсказания
  7. § 6. Равный доступ к государственной службе
  8. 2.1.4. Классификация информации по доступу к ней
  9. Ключ доступен каждому.
  10. Прямой доступ к информации (на основе книг Барбары Энн Бреннан).
  11. Принцип обеспечения потерпевшим права на доступ к правосудию и возмещение причиненного преступлением вреда
  12. § 3. Право управления предприятием как особый вид абсолютных прав. Право полного и ограниченного управления (п. 1774-1776)
  13. УПРАВЛЕНИЕ ВРЕМЕНЕМ VERSUS УПРАВЛЕНИЕ СОБОЙ
  14. Статья 200. Незаконные действия с документами на перевод, платежными карточками и иными средствами доступа к банковским счетам, оборудованием для их изготовления
  15. 15.6. Порядок доступа к Архивным фондам и использования архивных документов