Список управление доступом. Матрица защиты с доменами в качестве объектов. Изобразить. - Morozov-5F/operational-system-docs GitHub Wiki

#9.3. Управление доступом к ресурсам

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

##9.3.1. Домены защиты

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

У каждого объекта есть уникальное имя, по которому к нему можно обращаться, и конечный набор операций, которые процессы могут выполнять в отношении этого объекта. Файлу свойственны операции read и write, а семафору — операции up и down.

Совершенно очевидно, что нужен способ запрета процессам доступа к тем объектам, к которым у них нет прав доступа. Более того, этот механизм должен также предоставлять возможность при необходимости ограничивать процессы поднабором разрешенных операций. Например, процессу A может быть дано право проводить чтение данных из файла F, но не разрешено вести запись в этот файл.

Чтобы рассмотреть различные механизмы защиты, полезно ввести понятие домена. Домен (domain) представляет собой множество пар (объект, права доступа). Каждая пара определяет объект и некоторое подмножество операций, которые могут быть выполнены в отношении этого объекта. Права доступа (rights) означают в данном контексте разрешение на выполнение той или иной операции. Зачастую домен соотносится с отдельным пользователем, сообщая о том, что может, а что не может сделать этот пользователь, но он может также иметь и более общий характер, распространяясь не только на отдельного пользователя. К примеру, сотрудники одной группы программистов, работающие над одним и тем же проектом, могут целиком принадлежать к одному и тому же домену и иметь доступ к файлам проекта.

Распределение объектов по доменам зависит от особенностей того, кому и о чем нужно знать. Тем не менее одним из фундаментальных понятий является принцип минимальных полномочий (Principle of Least Authority (POLA)), или принцип необходимого знания. В общем, безопасность проще соблюсти, когда у каждого домена имеется минимум объектов и привилегий для работы с ними и нет ничего лишнего.

На рис. 9.2 показаны три домена с объектами в каждом из них и правами на чтение, запись и выполнение (Read, Write, eXecute) применительно к каждому объекту. Заметьте, что объект Printer1 одновременно находится в двух доменах и обладает одинаковыми правами в каждом из них. Объект File1 также присутствует в двух доменах, но имеет разные права в каждом из них.

В любой момент времени каждый процесс работает в каком-нибудь домене защиты. Иными словами, существует некая коллекция объектов, к которым он может иметь доступ, и для каждого объекта у него имеется некий набор прав. Во время работы процессы могут также переключаться с одного домена на другой. Правила переключения между доменами сильно зависят от конкретной системы.

Чтобы конкретизировать идею домена защиты, рассмотрим пример из системы UNIX (который также относится к Linux, FreeBSD и им подобным клонам). В UNIX домен процесса определяется его идентификаторами UID и GID. Когда пользователь входит в систему, его оболочка получает UID и GID, которые содержатся в его записи в файле паролей, и они наследуются всеми его дочерними процессами. Представляя любую комбинацию (UID, GID), можно составить полный список всех объектов (файлов, включая устройства ввода-вывода, которые представлены в виде специальных файлов и т. д.), к которым процесс может обратиться с указанием возможного типа доступа (чтение, запись, исполнение). Два процесса с одинаковой комбинацией (UID, GID) будут иметь абсолютно одинаковый доступ к одинаковому набору объектов. Процессы с различающимися значениями (UID, GID) будут иметь доступ к разным наборам файлов, хотя, может быть, и со значительным перекрытием этих наборов.

Более того, каждый процесс в UNIX состоит из двух частей: пользовательской и системной (выполняемой в ядре). Когда процесс осуществляет системный вызов, он переключается из пользовательской части в системную. По сравнению с пользовательской частью системная часть имеет доступ к другому набору объектов. Например, системная часть процесса может иметь доступ ко всем страницам в физической памяти, ко всему диску и ко всем другим защищенным ресурсам. Таким образом, системный вызов является причиной для переключения доменов защиты.

Когда процесс осуществляет системный вызов exec в отношении файла, у которого установлен бит SETUID или бит SETGID, он получает новый действующий идентификатор UID или GID. С другой комбинацией (UID, GID) он имеет и другой набор доступных файлов и операций. Запуск программы с установленным битом SETUID или битом SETGID также вызывает переключение домена, так как при этом изменяются права доступа. Важно знать, как именно система отслеживает принадлежность объекта к тому или иному объекту. Концептуально можно представить себе большую матрицу, в которой строками будут домены, а колонками — объекты. В каждой ячейке перечисляются права, если таковые имеются, которыми располагает домен по отношению к объекту. Матрица для рис. 9.2 показана на рис. 9.3. Располагая этой матрицей и номером текущего домена, операционная система может определить, разрешен ли из конкретного домена определенный вид доступа к заданному объекту.

Само по себе переключение между доменами также может быть легко включено в ту же табличную модель, если в качестве объекта представить сам домен, в отношении которого может быть разрешена операция входа — enter. На рис. 9.4 снова показана матрица с рис. 9.3, но теперь на ней в качестве объектов фигурируют и сами три домена. Процессы в домене 1 могут переключаться на домен 2, но обратно вернуться уже не могут. Эта ситуация моделирует в UNIX выполнение программы с установленным битом SETUID. Другие переключения доменов в данном примере не разрешены.

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 имеется две записи (разделенные точкой с запятой). В первой записи сообщается, что любой процесс,

которым владеет пользователь 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; ... При таких условиях, когда поступает запрос на доступ к объекту, выполняется проверка UID и GID того, кто выдал этот запрос. Если эти идентификаторы присутствуют в ACL-списке, то предоставляются права, перечисленные в списке. Если комбинации (UID, GID) в списке нет, доступ не разрешается.

По сути, использование групп вводит понятие роли (role). Рассмотрим вычислительный центр, в котором Тана является системным администратором и поэтому входит в группу sysadm. Но предположим, что в компании есть также клубы для сотрудников и Тана является членом клуба любителей голубей. Члены клуба принадлежат к группе pigfan и имеют доступ к компьютерам компании для ведения своей голубиной базы данных. Часть ACL-списка может иметь вид, представленный в табл. 9.2.

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

В некоторых случаях пользователю может предоставляться доступ к определенным файлам независимо от того, к которой группе он принадлежит в данный момент. Это можно устроить за счет использования группового символа (wildcard), означающего все, что угодно. К примеру, запись

tana, *:RW

в файле паролей предоставит Тане доступ независимо от того, к какой группе она в данный момент принадлежит.

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

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

предоставляет возможность доступа к файлу для чтения и записи всем, кроме пользователя с именем Вирджил (Virgil). Эта запись срабатывает благодаря тому, что записи сканируются по порядку и из них берется первая подходящая, а последующие записи даже не анализируются. В первой же записи находятся подходящее имя Virgil и права доступа — в данном случае none (то есть отсутствие каких-либо прав), которые и вступают в силу. Тот факт, что все остальные имеют доступ, не удостаивается никакого внимания.

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

debbie: RW; phil: RW; pigfan: RW

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

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

Источники:

• Современные опреационные системы, Э. Таненбаум, 4-е изд.