Главная страница  Межпроцессное взаимодействие (состязание) 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 [ 160 ] 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

Хотя это и не отражено в данном примере, один и тот же объект может иметь в различных доменах разные разрешения.

Домен 1 Домен 2 Домен 3


Рис. 5.20. Три домена защиты

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

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

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

Когда процесс выполняет системный вызов exec с файлом, у которого установлен бит SETUID или SETGID, процесс может получить новые идентификаторы UID и GID. При новой комбинации UID и GID процесс получает новый набор доступных файлов и операций. Запуск профаммы с установленным битом SETUID или SETGID также представляет собой переключение домена, так как права доступа при этом изменяются.

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



операционная система может для каждого домена определить разрешения к любому заданному объекту.

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

Домен

Объект

Файл 1

Файл 2

ФайлЗ

Файл 4

Файл 5

Файле

Принтер 1

Плоттер 2

Чтение

Чтение Запись

Чтение

Чтение Запись Исполнение

Чтение Запись

Запись

Чтение Запись Исполнение

Запись

Запись

Рис. 5.21. Матрица защиты Объект

Домен Плоттер 2 Домен 2

Файл 1 Файл 2 Файл 3 Файл 4 Файл 5 Файл 6 Принтер 1 Домен 1 Домен 3

Чтение

Чтение Запись

Enter

Чтение

Чтение Запись Исполнение

Чтение Запись

Запись

Чтение Запись Исполнение

Запись

Запись

Рис. 5.22. Матрица защиты с доменами в роли объектов

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

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



Согласно первому методу, с каждым объектом ассоциируется список (упорядоченный), содержащий все домены, которым разрешен доступ к данному объекту, а также тип доступа. Такие списки называются ACL-списками (Access Control List - список управления доступом. Если бы данный способ управления доступом реализовывался в UNIX, проще всего было бы для каждого файла завести отдельный дисковый блок, хранящий список, и включить номер этого блока в г-узел файла. Так как здесь хранятся только заполненные ячейки матрицы доступа, места потребуется гораздо меньше, чем для хранения всей матрицы.

Как работают списки управления доступом, мы рассмотрим на примере UNIX, где домен определяется парой (UID, GID). Действительно, в системе MULTIX, по образу которой строилась UNIX, ACL работали примерно так же, поэтому пример не столь уж гипотетический.

Предположим, имеется четыре пользователя (то есть четыре UID): Jan, Els, Jelle и Maarike, которые входят соответственно в фуппы system, staff, student, student. Далее, предположим, что имеются файлы со следующими ACL:

FileO: (Jan, *, RWX) Filel: (Jan, system, RWX)

File2: (Jan, *, RW-), (Els, staff, RW-), (Maarike, *, RW-)

File3: (*, student, R-)

File4: (Jelle, *,---), (*, student, R-)

Каждая из записей ACL состоит из трех частей: UID, GID и разрешенные способы доступа: Read (чтение). Write (запись), eXecute (исполнение). Звездочка означает любую группу пользователей или любого пользователя. Тогда файл FileO могут читать, записывать и исполнять те процессы, у которых UID = Jan и с любым GID. Доступ к файлу Filel могут получить только процессы с UID = Jan и GID = system. Процесс, у которого UID = Jan и GID = staff, может обращаться к файлу FileO, а к файлу Filel - нет. Файл File2 вправе читать и изменять процессы с UID = Jan, независимо от GID, кроме того, его разрешено читать процессам с UID = Els и GID = staff, или с UID = Maarike и любым GID. Файл File3 могут читать любые студенты (группа student). Особенно интересен файл File4. ACL этого файла гласит, что любой процесс с UID = ЕИе, независимо от GID, не имеет к файлу никакого доступа, а всем остальным студентам он доступен. Благодаря ACL можно запретить доступ к объекту для отдельных пользователей или групп, в то же время разрешая доступ остальным представителям того же класса.

Итак, достаточно говорить о том, чего нет в UNIX. Давайте теперь изучим то, что есть. В UNIX выделяются группы из трех битов для владельца файла, группы владельцев и для остальных. Эта схема, опять же, является ACL, но, на этот раз, ужатым до 9 бит. Это ассоциированный с файлом список, описывающий, кому и что разрешено делать с файлом. Хотя принятая в UNIX 9-битная схема, очевидно, имеет меньше возможностей, чем полноценная система с ACL, на практике она вполне адекватна, а ее реализация намного проще и дешевле.

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



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 [ 160 ] 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

© 2000 - 2018 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.