А.Ю.Щеглов Учебное пособие

Замечание. Введение рассмотренных правил назначения меток безопасности иерархическим объектам доступа обусловливает необходимость противодействия доступу пользователей к остаточной информации (ранее отмечали, что основой данного противодействия является реализация механизма обеспечения замкнутости программной среды, в дополнение может осуществляться гарантированная очистка остаточной информации). Поясним необходимость сказанного. Пусть в объекте Ok+1 (таким образом разметили логический диск) находятся два файла (объекты Ok-m и Ok-l). Пусть данным объектам присвоены различные метки безопасности. Тогда при удалении одного из объектов, на диске сохраняется остаточная информация, к которой, штатными средствами доступ пользователи получить не могут, но при определенных условиях (средствами прямого доступа к диску), могут получить доступ вне рамок мандатного механизма управления доступом (остаточная информация не имеет признаков объекта, к ней не может разграничиваться доступ субъектам) пользователи, имеющие различные метки безопасности. Правда, ради справедливости, отметим, что подобными средствами (если их разрешить запускать на компьютере, пользователь может получить доступ не только к остаточной, но и к актуальной информации, т.к. они обращаются не к объекту, а напрямую к диску, т.е. минуя механизм управления доступом.

Рассмотрим примеры применения введенных правил.

Пример 1. Пусть на логическом диске D: вводится три каталога, соответственно, D:\2, D:\3, D:\4 (реализуется мандатный механизм управления доступа к этим каталогам) и пусть соответствующим образом назначаются метки безопасности каталогам – 2, 3, 4. В этом случае корневым включающим элементом является диск D (объект Ok+1), ему должна быть присвоена метка Mk+1=5. Иллюстрация назначаемых меток безопасности объектам доступа для рассматриваемого примера приведена в табл. 3.1.

Таблица 3.1 Пример назначения меток безопасности иерархическим объектам доступа

Метка безопасности	Субъекты доступа	Объекты доступа
2		D:\2
3		D:\3
4		D:\4
5		D:

131

Пример 2. Рассмотрим более сложную иерархическую структуру. Пусть на логическом диске D: вводится два каталога, соответственно, D:\2, D:\3, в каталоге D:\2 расположен объект доступа – файл User 1, который должен иметь метку 2, и пусть в каталоге D:\3 присутствуют два объекта доступа

– файлы User 2 и User 3, соответствующим образом размечаемые – имеют метки 3 и 4. В этом случае включающим корневым элементом является диск D (объект Ok+1) – ему присваивается метка Mk+1 = 5. Иллюстрация назначаемых меток безопасности для рассматриваемого примера приведена в табл. 3.2.

Таблица 3.2 Пример назначения меток безопасности иерархическим объектам доступа

Метка безопасности	Субъекты доступа	Объекты доступа
2		D:\2
3		D:\3\User 2
4		D:\3\User 3
5		D:

Замечание. В примере разметки, изложенном в табл. 3.2, элемент D:\3 наследует метку включающего элемента D:, для файла User 1 достаточно назначить метку включающему его каталогу D:\2, которую он наследует.

Таким образом, настройка мандатного механизма управления доступом с иерархической структурой объектов доступа отличается следующим:

Вводится дополнительная группа объектов (Ok+1), которую образуют корневые включающие объекты доступа элементы;

Вводится дополнительная метка безопасности Mk+1 (причем M1 < M2 < M3<…<Mk < Mk+1), которая присваивается корневым включающим объекты доступа элементам (для файловой системы – логическим дискам или томам), образующим группу дополнительно вводимую группу объектов Ok+1;

Метка Mk+1 наследуется всеми включаемыми элементами иерархии,

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

Следствие. Рассмотренная реализация мандатного механизма управления доступом является универсальной в том смысле, что объектом доступа (ресурсом, к которому разграничивается доступ посредством

132

назначения меток безопасности) может являться любой элемент иерархии (например, для файловой системы – логический диск, каталог, подкаталог, файл).

Замечание. Процедура создания группы объектов Ok+1 и назначение ей метки безопасности Mk+1 легко формализуется и может быть реализована диспетчером доступа автоматически. При такой реализации диспетчера доступа настройка мандатного механизма управления доступом (задание правил разграничения доступа в диспетчере доступа) с иерархическими объектами доступа не сложнее, чем с неиерархическими объектами доступа.

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

3.3.6. Разграничения доступа для субъекта «процесс»

Выше рассматривались классические схемы управления доступом к ресурсам, реализуемые на основе дискреционного и мандатного механизмов управления доступом. В качестве субъекта доступа для них понимается «ПОЛЬЗОВАТЕЛЬ», при этом диспетчером доступа в соответствии с задаваемыми правами разграничивается доступ пользователей к объектам.

Возможности механизмов управления доступом могут быть существенно расширены (если не сказать, изменены) при включении в субъекты доступа субъекта «ПРОЦЕСС», для которого, аналогично субъекту доступа пользователь, могут разграничиваться права доступа на основе задаваемой матрицы доступа D.

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

133

сегодня несет в себе одну из доминирующих угроз несанкционированного доступа к информации.

Все сказанное ранее может быть отнесено и для рассматриваемого здесь случая, где в качестве субъекта доступа выступает «процесс», соответственно множество С = {С1,…, Ск} - линейно упорядоченные множества процессов. В качестве субъекта доступа «процесс» Сi, i = 1,…,k рассматривается как отдельный процессов, так и группа процессов, характеризуемая одинаковыми правами доступа к объектам, например, системные процессы (процессы ОС), процессы отдельных приложений и т.д.

В частности каноническую модель управления доступом можно представить матрицей доступа D, имеющей следующий вид:

	С1		С2….Ck-1		Ck
O1	1		0	0	0
O2	0		1	0	0
.		……………………….……..
D = .
		………………………………
.
Ok-1	0		0	1	0
Ok	0		0	0	1

где «0» обозначает отсутствие доступа процесса к объекту, «1» – полный доступ (например, разрешены типы доступа «Запись» и «Чтение» для файловых объектов).

Определение. Под канонической моделью управления доступом для линейно упорядоченных множеств процессов (групп процессов) и объектов (групп объектов) доступа понимается модель, описываемая матрицей доступа, элементы главной диагонали которой «1» – задают полный доступ процессов к объектам, остальные элементы «0» – задают запрет доступа процессов к объектам.

Аналогично сказанному ранее для субъектов доступа процесс в модели управления доступом могут быть реализованы выделенный, либо виртуальные каналы взаимодействия субъектов доступа.

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

Таким образом, в общем случае следует различать два вида субъекта доступа в схеме разграничения прав доступа к ресурсам – пользователь и

134

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

Разграничение прав доступа к объектам процессов вне разграничений пользователей;

Разграничение прав доступа к объектам пользователей, вне разграничений процессов;

Комбинированное разграничение прав доступа - разграничение прав доступа к объектам процессов в рамках разграничений пользователей (совместное разграничение доступа процессов и пользователей).

Замечание. Субъект доступа процесс является вторичным по отношению к субъекту доступа пользователь (в отличие от субъекта доступа пользователь, он может присутствовать, либо отсутствовать в схеме разграничения прав доступа).

На рис.3.17 приведен укрупненный алгоритм обработки запроса доступа к объекту, реализуемый диспетчером доступа.

135

	Начало		Путь проверки
			запроса с
			субъектом процесс
		Нет
	Имеет ли процесс		Обычный путь
			Проверки запроса
	собственные права?
	Да
	Нет		Нет
	Имеет ли	Имеет ли
	процесс право	право пользователь
	на доступ?	на доступ?
	Да	Да
	Вместе с правами
		пользователя
	Режим проверки
		Эксклюзивный
	Возврат	Выполнение
	ошибки	запроса

Рис.3.17. Укрупненный алгоритмо бработки запроса доступа к объекту диспетчером доступа

Выводы.

1.Ввиду того, что в схеме управления доступом присутствуют два субъекта доступа «ПОЛЬЗОВАТЕЛЬ» и «ПРОЦЕСС», причем процесс может запускать и не от лица пользователя, с целью корректного решения задачи управления доступом к ресурсам следует осуществлять разграничения для обоих этих субъектов доступа.

2.Так как процесс может запускать и не с правами текущего пользователя и, ввиду того, что в системе существуют привилегированные (системные) процессы, для корректной реализации

136

управления доступом должны предусматриваться следущие схемы разграничений для субъектов доступа:

Разграничение прав доступа к объектам процессов вне разграничений пользователей;

Разграничение прав доступа к объектам пользователей, вне разграничений процессов;

Комбинированное разграничение прав доступа - разграничение прав доступа к объектам процессов в рамках разграничений пользователей (совместное разграничение доступа процессов и пользователей).

3.3.7. Разграничение доступа к объекту «ПРОЦЕСС». Механизм обеспечения замкнутости программной среды

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

Управление доступом к исполняемым файлам реализует разграничение прав доступа субъектов на запуск прикладных программ.

Для разграничения доступа субъектов к исполняемым файлам введем право доступа “И” – “исполнение” (запуск программы), тогда множество прав доступа в общем случае имеет вид {Зп/Чт, Чт, Д, И}.

Используя обозначения, введенные ранее, введем следующее обозначение – пусть S = {0,И} – множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «И» – доступ к исполняемому файлу (разрешение чтения исполняемого файла). Тогда, по аналогии со сказанным ранее, каноническую модель управления доступом к исполняемым файлам можно представить матрицей доступа D, имеющей следующий вид:

	С1		С2….Ck-1		Ck
O1		И	0	0	0
O2	0		И	0	0
.		……………………….……..
D = .
		………………………………
.
Ok-1	0		0	И	0
Ok	0		0	0	И

Модель управления доступом формально может быть описана следующим образом - элемент (Dij) матрицы Dij = И, если i = j, иначе Dij = 0.

137

Определение. Под канонической моделью управления доступом к исполняемым файлам для линейно упорядоченных множеств субъектов (групп субъектов) и объектов (групп объектов) доступа понимается модель, описываемая матрицей доступа, элементы главной диагонали которой «И» – задают доступ к исполняемому файлу (разрешение на запуск программы), остальные элементы «0» – задают запрет доступа субъектов к исполняемым файлам.

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

Доказывается утверждение от обратного. Если каноническую модель управления доступом реализовать невозможно – присутствуют элементы «И» вне главной диагонали матрицы доступа, то в системе присутствует, по крайней мере, один объект - программа, доступ к запуску которой невозможно разграничить в полном объеме (объект включается одновременно в несколько групп объектов, априори характеризуемых различными правами доступа к ним).

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

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

В матрице доступа D это означает включение группы (групп) объектов, для которых несколько субъектов будут иметь доступ, пример такой матрицы, которой введена группа объектов (программ) Ok+1, доступ к которым (запуск которых) разрешен всем субъектам, приведен ниже.

		С1	С2….Ck-1		Ck
O1		И	0	0	0
O2	0		И	0	0
.		……………………….……..
D = .
		………………………………
.
Ok-1	0		0	И	0
Ok	0		0	0	И
Ok+1		И	И	И	И

138

Аналогично тому, как и для управления доступом к файлам данных, здесь может быть реализован дискреционный и мандатный механизмы управления доступом. Дискреционный механизм предполагает реализацию доступа диспетчером на основе заданной мартицы доступа D, мандатный – на основе меток безопасности.

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

Метки безопасности являются элементами линейно упорядоченного множества M = {M1,…, Mk} и задаются субъектам и объектам доступа. Метки безопасности назначаются субъектам и объектам (группам субъектов и объектов), служат для формализованного представления их уровня полномочий. Как и ранее, будем считать, что чем выше полномочия субъекта и объекта – уровень защиты информации, обеспечиваемый приложением (меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}), тем меньшее значение метки безопасности Mi, i = 1, …, k им присваивается, т.е.: M1 < M2 < M3<…<Mk.

Таким образом, в качестве учетной информации субъектов и объектов доступа, кроме их идентификаторов – имен, в диспетчере доступа каждому субъекту и объекту задаются метки безопасности из множества M.

Разграничение доступа диспетчером реализуется на основе правил, определяющих отношение линейного порядка на множестве M, где для любой пары элементов из множества M, задается один из типов отношения : {>,<,=} (на практике реализуется выбор подмножества M, изоморфного конечному подмножеству натуральных чисел – такой выбор делает естественным арифметическое сравнение меток безопасности).

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

139

быть не ниже, чем требуется для обработки информации, доступ к которой разрешен субъекту.

Каноническая полномочная модель управления доступом к исполняемым файлам может быть представлена следующей матрицей доступа D.

		С1	С2….Ck-1		Ck
O1		И	И	И	И
O2	0		И	И	И
.		……………………….……..
D = .
		………………………………
.
Ok-1	0		0	И	И
Ok	0		0	0	И

Модель управления доступом формально может быть описана следующим образом - элемент (Dij) матрицы Dij = И, если i <= j, иначе Dij = 0.

Определение. Под канонической моделью управления доступом к исполняемым файлам с виртуальными каналами взаимодействия субъектов доступа для линейно полномочно упорядоченных множеств субъектов (групп субъектов) и объектов (групп объектов) доступа понимается модель, описываемая матрицей доступа, элементы главной диагонали которой и, элементы, расположенные выше главной диагонали, «И» – задают право доступа «Исполнение», остальные элементы матрицы «0» – запрет запуска исполняемого файла.

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

Ms – метка безопасности субъекта (группы субъектов) доступа;

Mo – метка безопасности объекта (группы объектов) доступа;

Метка безопасности с порядковым номером i – Mi устанавливается для субъекта доступа с порядковым номером i – Ci и для объекта доступа с порядковым номером i – Oi.

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

1.Субъект С имеет доступ к объекту О в режиме “Исполнение” в случае, если выполняется условие: Mc => Mo.

2.Субъект С не имеет доступ к объекту О в режиме “Исполнение” в случае, если выполняется условие: Mc < Mo.

Выводы:

1.В схеме управления доступом в качестве отдельного объекта доступа следует рассматривать исполняемый файл (процесс). В этом

140