The design of the UNIX Operating System 135 страница
Рис. 16.1. Специфицирование прав доступа к ресурсам
Связь конкретных субъектов, функционирующих в операционных системах, может быть организована следующим образом.
• Каждый пользователь может быть доменом. В этом случае набор объектов, к которым может быть организован доступ, зависит от идентификации пользователя.
• Каждый процесс может быть доменом. В этом случае набор доступных объектов определяется идентификацией процесса.
|
|
|
• Каждая процедура может быть доменом. В этом случае набор доступных объектов соответствует локальным переменным, определенным внутри процедуры. Заметим, что когда процедура выпол-нена, происходит смена домена.
Рассмотрим стандартную двухрежимную модель выполнения ОС. Когда процесс выполняется в режиме системы (kernel mode), он может выполнять привилегированные инструкции и иметь полный контроль над компьютерной системой. С другой стороны, если процесс выполняется в пользовательском режиме, он может вызывать только непривилегированные инструкции. Следовательно, он может выполняться только внутри предопределенного пространства памяти. Наличие этих двух режимов позволяет защитить ОС (kernel domain) от пользовательских процессов (выполняющихся в user domain). В мультипрограмм-ных системах двух доменов недостаточно, так как появляется необходимость защиты пользователей друг от друга. Поэтому требуется более тщательно разработанная схема.
|
|
|
|
|
|
В ОС Unix домен связан с пользователем. Каждый пользователь обычно работает со своим набором объ-ектов.
Матрица доступа
Модель безопасности, специфицированная в предыдущем разделе (см . рис. 16.1), имеет вид матрицы, ко-торая называется матрицей доступа. Какова может быть эффективная реализация матрицы доступа? В общем случае она будет разреженной, то есть большинство ее клеток будут пустыми. Хотя существуют структуры данных для представления разреженной матрицы, они не слишком полезны для приложений, использующих возможности защиты. Поэтому на практике матрица доступа применяется редко. Эту матрицу можно разложить по столбцам, в результате чего получаются списки прав доступа (access control list - ACL). В результате разложения по строкам получаются мандаты возможностей (capability list
|
|
|
или capability tickets).
Список прав доступа. Access control list
| Основы операционных систем | 171 |
Каждая колонка в матрице может быть реализована как список доступа для одного объекта. Очевидно, что пустые клетки могут не учитываться. В результате для каждого объекта имеем список упорядочен-ных пар <domain, rights-set>, который определяет все домены с непустыми наборами прав для данного объекта.
Элементами списка могут быть процессы, пользователи или группы пользователей. При реализации ши-роко применяется предоставление доступа по умолчанию для пользователей, права которых не указаны . Например, в Unix все субъекты-пользователи разделены на три группы (владелец, группа и остальные), и для членов каждой группы контролируются операции чтения, записи и исполнения (rwx). В итоге имеем ACL - 9-битный код, который является атрибутом разнообразных объектов Unix.
Мандаты возможностей. Capability list
Как отмечалось выше, если матрицу доступа хранить по строкам, то есть если каждый субъект хранит список объектов и для каждого объекта - список допустимых операций, то такой способ хранения назы-вается "мандаты" или "перечни возможностей" (capability list). Каждый пользователь обладает несколь-кими мандатами и может иметь право передавать их другим. Мандаты могут быть рассеяны по системе и вследствие этого представлять большую угрозу для безопасности, чем списки контроля доступа. Их хра-нение должно быть тщательно продумано.
Дата добавления: 2021-01-21; просмотров: 92; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!