На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Субъект доступа «ПРОЦЕСС» и его учет при разграничении доступа

Включение субъекта «ПРОЦЕСС» в схему управления доступом
Процесс, как субъект доступа
Выше рассматривались классические схемы управления доступом к ресур­сам, реализуемые на основе дискреционного и мандатного механизмов управления доступом. В качестве субъекта доступа для них понимается «ПОЛЬЗОВАТЕЛЬ». При этом доступ к объектам, в соответсвии с задан­ными правилами, разграничивается именно для пользователей.
Тем не менее, ранее было отмечено, что в качестве самостоятельного субъекта доступа может выступать процесс, так как в общем случае он может запускаться не от лица текущего пользователя (например, систем­ные процессы).
Возможности механизмов управления доступом могут быть существенно расширены при включении в субъекты доступа субъекта «ПРОЦЕСС», для которого, аналогично субъекту доступа «пользователь», могут разграничиваться права доступа на основе задаваемой матрицы доступа D.
Все сказанное ранее (применительно к субъекту доступа «пользователь»)
может быть отнесено и к случаю, когда в качестве субъекта доступа выс­тупает «процесс». Соответственно множество С = {С1,...,Ск} - линейно упорядоченные множества процессов. В качестве субъекта доступа «про­цесс» Ci, i = l,...,k рассматривается как отдельный процесс, так и группа процессов, характеризуемая одинаковыми правами доступа к объектам.
В частности, каноническую модель управления доступом можно предста­вить матрицей доступа D, имеющей следующий вид: где «О» обозначает отсутствие доступа процесса к объекту, а «I» — пол­ный доступ (например, разрешены типы доступа «Запись» и «Чтение» для файловых объектов).
Под канонической моделью управления доступом для линейно упорядочен­ных множеств процессов (групп процессов) и объектов (групп объектов) до­ступа будем понимать модель, описываемую матрицей доступа, элементы
главной диагонали которой «1» задают полный доступ процессов к объектам,
остальные элементы «О» задают запрет доступа процессов к объектам.
Аналогично сказанному ранее для субъектов доступа «процесс» в моде­ли управления доступом могут быть реализованы либо выделенные, либо
виртуальные каналы взаимодействия субъектов доступа.
Следуя определению канонической модели, можем сделать вывод, что включение в схему управления субъекта доступа «процесс» позволяет в
системе локализовать объекты доступа (например, области дисковой па­мяти, устройства и т.д.) для отдельных приложений и иных групп про­цессов. Верно и обратное: можно локализовать процессы (приложения) для отдельных объектов доступа (данных).
Схема управления доступом для субъекта «ПРОЦЕСС»
Итак, в общем случае следует различать два вида субъекта доступа -«пользователь» и «процесс». Поэтому в общем случае диспетчером дос­тупа по отношению к объектам должны реализовываться следующие воз­можности:
• разграничение прав доступа к объектам процессов вне разграничений
пользователей;
» разграничение прав доступа к объектам пользователей вне разграни­чений процессов;
» комбинированное разграничение прав доступа — разграничение прав доступа к объектам процессов в рамках разграничений пользователей (совместное разграничение доступа процессов и пользователей).
Субъект доступа «процесс» является вторичным по отношению к субъекту доступа «пользователь». В отличие от субъекта «пользователь» он может либо присутствовать, либо отсутствовать в схеме разграничения прав доступа.
2 приведена схема обработки запроса доступа к объекту, реа­лизуемая диспетчером доступа в КСЗИ «Панцирь» при разграничении прав доступа для субъектов «пользователь» и «процесс» [31, 32].
Обозначения используемых на схеме функциональных блоков: блок ана­лиза запроса доступа к ресурсу — 1, блок формирования отказа в досту­пе к ресурсу — 2, блок анализа прав доступа процесса — 3, блок разре­шения/запрета доступа процессу к ресурсу — 4, блок анализа прав доступа пользователя — 5, блок разрешения/запрета доступа пользователя к ре­сурсу — 6, блок формирования запроса доступа к ресурсу — 7.
Работает схема реализации диспетчера доступа следующим образом. В блок 1 поступает запрос пользователя на доступ к ресурсу, содержащий идентификатор ресурса и требуемое действие (чтение, запись, выполне­ние). Блок 1 формирует из запроса учетную информацию запрашиваемого доступа — идентификатор ресурса и требуемое действие над ним. Затем
блок 1 выдает данную информацию в блоки 3 и 5.
В блок 5 поступает имя (идентификатор) пользователя, запросившего ре­сурс, в блок 3 — идентификатор (полный путь) процесса, запросившего
ресурс. Сначала блок 3 определяет, какие права доступа к ресурсу разре­шены процессу, запросившему ресурс, и какие права доступа к ресурсу им запрошены. Затем он сравнивает заданные и запрошенные права доступа. Кроме того, блок 3 анализирует, каким способом обрабатываются права доступа процесса к ресурсу: эксклюзивно,   либо с правами пользователя.
При совпадении заданных и запрошенных прав блоком 3 вырабатывается код разрешающего сигнала, поступающий в блок 4. При несовпадении задан­ных и запрошенных для процесса прав блок 4 подаст сигнал в блок 2, и пользователю будет сообщено об отказе в доступе.
При эксклюзивном режиме обработки процесса блок 4 пропускает зап­рос сразу в блок 7. При этом права пользователя не учитываются.
В режиме обработки запроса процесса вместе с правами пользователя, запрос блоком 4 в блок 7 не выдается. В этом случае, при совпадении для процесса заданных и запрошенных прав, блок 4 передает информа­цию в блок 6.
Теперь рассмотрим как производится анализ прав пользователя. А про­изводится он блоком 5, и результат передается в блок 6. Соответсвенно,
в случае несовпадения для пользователя заданных и запрошенных прав, ему блоком 6 через блок 2 будет отказано в доступе. Если права пользо­вателя оказались достаточными, то блок 6 будет ждать разрешающего
сигнала от блока 4, который разрешает/запрещает доступ процессу.
ВЫВОДЫ
1. Ввиду того, что в схеме управления доступом присутствуют два субъекта доступа «ПОЛЬЗОВАТЕЛЬ» и «ПРОЦЕСС», причем про­цесс может запускаться и не от лица текущего пользователя (на­пример, системные процессы), с целью корректного решения зада­чи управления доступом к ресурсам следует осуществлять разграничения для обоих этих субъектов доступа.
2. Необходимо учитывать, что процесс может запускаться и не с пра­вами текущего пользователя, то есть в системе существуют приви­легированные (системные) процессы. В связи с этим для коррект­ной реализации управления доступом должны предусматриваться следующие схемы разграничений для субъектов доступа:
• Разграничение прав доступа к объектам процессов вне разграни­чений пользователей.
• Разграничение прав доступа к объектам пользователей вне раз­граничений процессов.
• Комбинированное разграничение прав доступа — разграничение
прав доступа к объектам процессов в рамках разграничений пользователей (совместное разграничение доступа процессов и пользователей).

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика