Глава 3. Модель политики безопасности управления доступом — требования к составу и структуре модели. Базовый уровень МРОСЛ ДП-модели

3.1. Требования к составу и структуре модели

Основу системы требований по созданию на основе ОС общего назначения механизма управления доступом, сертификации ОС на соответствие «Требованиям безопасности информации к операционным системам», утвержденным приказом ФСТЭК России от 19 августа 2016 г. № 119 [15], составляют шесть профилей защиты ОС типа «А» [17]. Эти профили защиты, основываясь на ГОСТ Р ИСО/МЭК 15408, а также дополняя его, включают иерархическую систему функциональных требований и требований доверия, состав которых постепенно усиливается от шестого к первому классу защиты ОС.

Наибольший интерес, с учетом сложившейся практики создания и сертификации отечественных защищенных ОС, представляют профили защиты для третьего и второго классов [13, 14], ориентированные на информационные системы, в которых обрабатывается информация, содержащая секретные или совершенно секретные сведения соответственно.

Начиная с третьего класса защиты профили защиты включают компонент доверия ADV_SPM.1 «Формальная модель политики безопасности». В соответствии с ГОСТ Р ИСО/МЭК 15408 в этом компоненте указывается, что формальная модель должна быть изложена в формальном стиле (с использованием, например, математического языка), должно быть определено понятие «безопасность» для ОО и должно быть представлено формальное доказательство того, что ОО не может перейти в небезопасное состояние, а также должно быть продемонстрировано соответствие между какой-либо функциональной спецификацией, используемой ОО, и моделью. При этом непосредственно в замечаниях по применению компонента ADV_SPM.1 в профилях защиты испытательной лаборатории при выполнении соответствующей проверки предписывается руководствоваться п. 10.7.1 ГОСТ Р ИСО/МЭК 18045 [18]. Однако в нем лишь говорится, что «общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки», т. е. не дается содержательных пояснений, как выполнить данную проверку.

Кроме того, выполнение требований компонента доверия ADV_SPM.1 тесно связано еще, как минимум, с двумя компонентами. В самом компоненте доверия указывается на наличие зависимости от компонента доверия ADV_FSP.4 «Полная функциональная спецификация». Более того, в профилях защиты для ОС третьего и второго классов это требование усилено включением в них компонента доверия ADV_FSP.5 «Полная полуформальная функциональная спецификация с дополнительной информацией об ошибках» и ADV_FSP.6 «Полная полуформальная функциональная спецификация с дополнительной формальной спецификацией» соответственно. Разработка полуформальной функциональной спецификации, тем более формальной спецификации без «привязки» к формальной модели политики безопасности вряд ли представляется возможной.

Также в эти профили защиты включен отсутствующий в ГОСТ Р ИСО/МЭК 15408 компонент доверия AVA_CCA_EXT.1 «Анализ скрытых каналов». Для определения этого компонента в профилях защиты указано, что «анализ скрытых каналов является частью анализа уязвимостей и проводится с целью сделать заключение о существовании и потенциальной пропускной способности каналов передачи сигналов (коммуникационных каналов), которые не предусмотрены для передачи защищаемой информации (данных пользователя и иной информации) или неразрешенных сигналов, но которые могут быть для этого использованы потенциальными нарушителями (в нарушение установленных политик управления информационными потоками, управления доступом или иных установленных ограничений)».

В качестве скрытых каналов в профилях защиты рассматриваются:

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

Это значит, что в качестве скрытых каналов должны быть рассмотрены информационные потоки по времени [19], возникающие в результате действий над объектами доступа (получение доступов, изменение прав доступа, создание, удаление, переименование и т. д.), осуществляемых кооперирующими субъектами доступа ОС, примеры которых рассмотрены в [9, 20]. В результате анализ таких скрытых каналов вне рамок формальной модели политики безопасности, в первую очередь политики управления доступом, будет трудно признать адекватным.

Для выполнения требований компонента доверия ADV_SPM.1 необходимо, чтобы язык представления формальной модели был либо математическим [9], либо формальным (например, [21]). Однако не менее важным является содержательная сторона дела, каковы требования к свидетельствам, предоставляемым при выполнении компонента доверия, какова «глубина» проработки формальной модели. Можно ли считать удовлетворительным, например, следующее «математическое» представление механизма управления доступом ОС в рамках модели в виде кортежа (V,T), где V — множество состояний системы, как-то задающее доступы (текущие доступы или права доступа) субъектов из множества S к объектам из множества O, а T — какая-то функция переходов системы из состояния в состояние, без какой-либо детализации?

Довольно популярной среди разработчиков отечественных защищенных ОС до сих пор является модель Белла-ЛаПадулы. Можно ли признать ее адекватной современным ОС и достаточной для представления в профиле защиты, например механизма мандатного управления доступом, реализуемого в защищенных ОС, принадлежащих семейству Linux? При том, что в этой модели не содержится средств описания информационных потоков по времени, иерархии сущностей (адекватной файловым системам ОС), функционально ассоциированных с субъектами сущностей, мандатного контроля целостности, различий в условиях функционирования доверенных и недоверенных субъектов и др. Ответ, очевидно, отрицательный.

Здесь целесообразно отметить, что если принципы реализации мандатного управления доступом хотя бы в том объеме, в котором они были изложены в классической модели Белла-ЛаПадулы, известны многим разработчикам отечественных защищенных ОС, то в случае с мандатным контролем целостности ситуация часто обстоит иначе. С одной стороны, мандатный контроль целостности был впервые теоретически описан еще в 1975 г. в рамках во многом похожей на модель Белла-ЛаПадулы модели Биба [22]. Он с 2007 г. реализуется в механизме MIC (Mandatory Integrity Control) всех ОС семейства Microsoft Windows, где показал свою высокую эффективность при противодействии компьютерным вирусам и атакам, направленным на несанкционированное повышение привилегий. С другой стороны, среди отечественных ОС мандатный контроль целостности применен только ОССН Astra Linux Special Edition версии 1.5. По этой причине напомним читателю основные свойства мандатного контроля целостности.

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

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

В связи с изложенным для удовлетворения требованиям компонента доверия ADV_SPM.1 на основе опыта авторов по разработке, верификации и внедрению математической модели для обеспечения должной «глубины» и детализации целесообразно предложить следующие требования к ее содержанию. Модель должна включать в себя строго описанные:

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

Примером представления элементов такого описания является рассмотренный ниже базовый уровень мандатной сущностно-ролевой модели управления доступом и информационными потоками в ОС семейства Linux (МРОСЛ ДП-модели). В своей работе авторы используют именно ее в качестве исходной, математической модели политики безопасности управления доступом. Базовый уровень МРОСЛ ДП-модели описывает механизм управления доступом на основе ролей. Основное свойство этого механизма состоит в том, что субъект может получить доступ определенного вида к какой-либо сущности только тогда, когда он обладает ролью, имеющей право на этот вид доступа к этой сущности. Каждая роль представляет собой набор таких пар из сущности и права определенного доступа к ней, а назначение ролей субъектам осуществляет администратор безопасности. Другие уровни МРОСЛ ДП-модели описывают механизмы мандатного контроля целостности и мандатного управления доступом и в настоящей монографии детально не рассматриваются. По этой причине в монографии не излагаются подходы к анализу условий реализации скрытых каналов (информационных потоков) по памяти и по времени, как относящиеся в первую очередь к мандатному управлению доступом и выполненные на последующих после базового уровнях модели [9, 20]. В то же время в силу отмеченной важности осуществления такого анализа в рамках формальной модели безопасности управления доступом для выполнения требований компоненты доверия AVA_CCA_EXT.1 там, где это возможно, при описании базового уровня МРОСЛ ДП-модели даются пояснения, раскрывающие пути дальнейшего осуществления анализа скрытых каналов.

Кроме того, с учетом сложности математической модели политики безопасности управления доступом целесообразно в соответствии с требованиями компонента доверия ADV_SPM.1 для формального доказательства того, что ОС не может перейти в небезопасное состояние, а также для демонстрации соответствия между какой-либо функциональной спецификацией ОС и моделью требовать ее верификации с применением инструментальных средств. Для этого представление модели должно включать описание:

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

Возможность практического выполнения этих условий подтверждается опытом верификации МРОСЛ ДП-модели, представленной на формальном языке Event-B в инструментальной среде Rodin. Примерам такой верификации для базового уровня модели посвящена глава 3 настоящей монографии, а подходу к представлению на основе модели формальной функциональной спецификации элементов механизма управления доступом — глава 4.

3.2. Базовый уровень МРОСЛ ДП-модели в математической нотации

Как было показано в предыдущей главе, отправной точкой выполнения требований компонента доверия ADV_SPM.1 является либо разработка модели политики безопасности управления доступом в математической нотации с ее дальнейшим переводом формализованную нотацию, либо изначально представление модели в формализованной нотации. Первый путь базируются на отработанной десятилетиями опыте формирования классических математических моделей, начиная с модели Белла-ЛаПадулы, Take-Grant и др. [9]. Хотя перевод в формализованную нотацию представляет собой достаточно сложную с научной и практической точек зрения задачу, ее решение при наличии уже разработанной математической модели все же проще, чем второй путь — разработка модели политики безопасности управления доступом в формализованной нотации с нуля.

В связи с этим авторами настоящей монографии был выбран первый путь — разработка в математической нотации мандатной сущностно-ролевой ДП-модели (МРОСЛ ДП-модели) как теоретической основы для реализации механизма управления доступом ОССН. Этому, в свою очередь, предшествовал достаточно длительный этап формирования на основе классических моделей семейства ДП-моделей безопасности управления доступом в компьютерных системах с дискреционным, мандатным или ролевым управлением доступом. Рассмотрим его подробнее.

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

Основой всех моделей семейства стала дискреционная базовая ДП-модель, построенная с применением расширенной модели Take-Grant, модели Белла-ЛаПадулы, модели систем военных сообщений и субъектно-ориентированной модели изолированной программной среды [9]. При этом был использован классический субъект-сущностный подход. В рамках базовой ДП-модели были обоснованы необходимые и достаточные условия передачи в прав доступа или реализации информационных потоков по памяти или по времени для самого простого случая, когда все субъекты идеально кооперируют друг с другом при передаче прав доступа и создании информационных потоков.

Для анализа компьютерных систем, в которых все субъекты являются либо доверенными, либо недоверенными, когда доверенные субъекты не кооперируют с недоверенными при передаче прав доступа или реализации информационных потоков, были построены ДП-модель без кооперации доверенных и недоверенных субъектов (БК ДП-модель), ДП-модель с блокирующими доступами доверенных субъектов (БД ДП-модель) и ДП-модель с функционально ассоциированными с субъектами сущностями (ФАС ДП-модель), которая позволяет анализировать условия получения недоверенным субъектом права доступа владения к доверенному субъекту с использованием реализации недоверенным субъектом информационного потока по памяти к сущности, функционально ассоциированной с доверенным субъектом.

Для анализа безопасности компьютерных систем с мандатным управлением доступом были построены мандатная ДП-модель, мандатная ДП-модель с блокирующими доступами доверенных субъектов (БДМ ДП-модель), мандатная ДП-модель с отождествлением порожденных субъектов (ОСМ ДП-модель) и мандатная ДП-модель

КС, реализующих политику строгого мандатного управления доступом (ПСМ ДП-модель).

Дальнейшее развитие семейства ДП-моделей пошло по следующим двум направлениям:

построение ДП-моделей типовых практически значимых или перспективных компьютерных систем;
построение ДП-моделей, содержащих элементы принципиально новые по сравнению с элементами уже разработанных ДП-моделей.

По первому направлению построены ДП-модели для нескольких реальных компьютерных систем, в том числе ДП-модель веб-системы и веб-системы на основе СУБД, в рамках которых осуществлен анализ защищенности типовых веб-систем от угроз реализации атак вида межсайтового скриптинга ( Cross\ Site\ Scripting,\ XSS ) [24] и SQL-инъекции [25].

По второму направлению с использованием ДП-модели с функционально или параметрически ассоциированными с субъектами сущностями (ФПАС ДП-модели) [26] был рассмотрен случай, когда в компьютерной системе могут существовать параметрически ассоциированные с субъектами сущности (файлы паролей, файлы cookies), реализация от которых информационных потоков по памяти (например, их чтение) к недоверенным субъектам позволяет им получить контроль над другими субъектами системы, в том числе доверенными. Кроме того, описана ДП-модель файловых систем (ФС ДП-модель) [27], в которой анализируется характерный для файловых систем новый вид доверенных субъектов — потенциальных доверенных субъектов, из которых могут быть созданы доверенные субъекты, реализующие доступ к сущностям, защищенным механизмами файловых систем (например, механизмами файловой системы EFS в среде ОС семейства Windows\ XP/2003/Vista ).

Также по второму направлению для исследования безопасности компьютерных систем с учетом особенностей ролевого управления доступом на основе семейства ролевых моделей RBAC и семейства дискреционных и мандатных ДП-моделей были построены две ролевые ДП-модели (БР ДП-модель и РОСЛ ДП-модель) [28, 29], ставшие «промежуточными», заложившими фундамент формирования современной МРОСЛ ДП-модели.

В МРОСЛ ДП-модели было обеспечено сочетание мандатного управления доступом, мандатного контроля целостности с перспективным ролевым управлением доступом. При этом особое внимание уделялось детальному описанию правил переходов системы из состояние в состояние, которые классифицированы на де-юре и де-факто правила.

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

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

С использованием этих определений в модели были сформулированы и обоснованы достаточные условия безопасности системы во всех трех смыслах.

Однако такое описание МРОСЛ ДП-модели имело достаточно существенный объем и являлось «монолитным», т.е. элементы модели давались в порядке, удобном для описания модели в целом. Из-за большого объема и монолитности модели, невозможности в таком виде ее поэтапной реализации затрудняется использование модели разработчиками ОССН, а также создание на ее основе новых моделей.

Все выше перечисленное стало причиной переработки МРОСЛ ДП-модели в ее иерархическое представление. Первоначально при его разработке в модель (по сравнению с ее «монолитным» представлением) не добавлялись новые элементы, а основной целью являлось формирование следующих четырех упорядоченных уровней [30] (рис. 3.1):

Рис. 3.1. Актуальное иерархическое представление МРОСЛ ДП-модели

первый уровень (базовый) модель системы ролевого управление доступом (1.1);
второй уровень модель системы ролевого управление доступом и мандатного контроля целостности (2.1);
третий уровень модель системы ролевого управление доступом, мандатного контроля целостности и мандатного управления доступом только с информационными потоками по памяти (3.1);
четвертый уровень модель системы ролевого управление доступом, мандатного контроля целостности и мандатного управления доступом с информационными потоками по памяти и по времени (4.1).

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

Следующим шагом стало включение в иерархическое представление МРОСЛ ДП-модели новых уровней, содержащих элементы, до этого не использованные в «монолитном» представлении.

Практика использования МРОСЛ ДП-модели при реализации ОССН показала, что в ряде случаев применение ролей, обладающих только правами доступа к сущностям, разрешающим субъектам получение соответствующих доступов к ним, является недостаточным и создает неудобство при администрировании ОССН. В [31] описываются ситуации, когда, например, только одну учетную запись пользователя системы необходимо лишить права доступа, предоставляемого ей через роль, которой обладают все учетные записи пользователей системы, при этом все другие права доступа этой роли должны быть оставлены без изменений. В связи с этим в иерархическое представление модели был добавлен уровень запрещающих ролей (1.2). Запрещающие роли в отличие от «обычных» ролей содержат права доступа к сущностям или субъектам, которые не разрешают, а, наоборот, запрещают получение соответствующих доступов. Этот уровень основан на базовом уровне модели, на нем не реализованы мандатное управление доступом и мандатный контроль целостности, а для задания запрещающих ролей используется описанный еще в ролевых моделях семейства RBAC механизм ограничений (constraint).

Следует отметить, что мандатный контроль целостности — важнейший, хорошо зарекомендовавший себя механизм безопасности, который аналогично мандатному управлению доступом направлен на задание и применение четких, понятных для пользователей и администраторов современных операционных систем правил обеспечения целостности их программной среды. Изначально в МРОСЛ ДП-модели для задания мандатного контроля целостности применялись всего два уровня целостности: высокий (i_high) и низкий (i\_low) . Этого было вполне достаточно для разделения всех элементов ОССН на системные (доверенные компоненты ОССН, обеспечивающие функционирование процессов ее ядра и системных процессов, в том числе механизмов защиты и администрирования), обладающие высоким уровнем целостности, и пользовательские (недоверенные компоненты ОССН, выполняющие функции процессов непривилегированных пользователей, в том числе нарушителей), обладающие низким уровнем целостности.

Именно в таком виде мандатный контроль целостности реализован в версиях 1.4 и 1.5 ОССН. Но при использовании в ОССН технологий виртуализации (гипервизора), например на основе ПК «ВИУ» [32], а также при реализации сетевой доменной архитектуры, требуются дополнительные уровни целостности. Например, одним из возможных решений здесь может быть использование трех уровней целостности: высокого, соответствующего системному для основной ОССН, среднего, соответствующего системному для ОССН, запущенной в среде виртуализации (виртуализированной), и низкому — пользовательскому для основной и виртуализированной ОССН. Кроме того, в перспективе уровней целостности может потребоваться больше, в том числе для реализации невырожденной (состоящей из более чем двух уровней, где не каждый уровень сравним с каждым) решетки уровней целостности. В связи с изложенным был разработан уровень мандатного контроля целостности с невырожденной решеткой уровней целостности (2.2) [33].

Наиболее интересным было формирование уровня ролевого управления доступом с запрещающими ролями и мандатного контроля целостности с невырожденной решеткой уровней целостности (2.3) МРОСЛ ДП-модели, основанном не на одном, а впервые на двух предшествующих уровнях 1.2 и 2.2. В результате было показано, что структура иерархического представления модели может развиваться не только «древовидно». Она позволяет после разработки уровня, содержащего существенные новые элементы, далее дополнить этими элементами существующие «верхние» уровни модели, ориентированные на мандатное управление доступом с контролем информационных потоков по памяти и по времени.

Именно это было осуществлено далее при создании уровней ролевого управления доступом с запрещающими ролями, мандатного контроля целостности с невырожденной решеткой уровней целостности и мандатного управления доступом с информационными потоками по памяти (3.2) и по времени (4.2).

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

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

По мере описания модели также даются пояснения возможных способов или особенностей реализации ее элементов в реальной ОССН.

3.3. Состояние системы: структуры данных модели

3.3.1. Элементы состояния системы

Выбранный подход к моделированию политики безопасности управления доступом в литературе принято называть как state-based modeling, т. е. построение модели в форме системы переходов из состояния в состояние. Синонимом «системы переходов» в данном случае может быть термин «автоматная модель».

Основным элементам состояния системы в рамках модели, образующим конструкцию базового уровня иерархического представления МРОСЛ ДП-модели, соответствуют учетные записи пользователей, представляющие пользователей ОССН, функционирующих от их имени субъект-сессий — «активных» компонентов (процессов) ОССН, так называемые «пассивные» сущности, представляющие файлы, каталоги, сокеты и другие ресурсы ОССН, представляющие связи между пользователями и пассивными сущностями. Все эти элементы применяются для описания состояний рассматриваемой в рамках модели абстрактной системы, для чего используем следующие обозначения:

U — конечное непустое множество учетных записей пользователей (в любой ОССН задана хотя бы одна учетная запись пользователя);
S — конечное непустое множество субъект-сессий учетных записей пользователей (всех «активных» компонентов защищенной ОССН, при этом в любой ОССН есть хотя бы одна субъект-сессия, например, соответствующая системному процессу, реализующему процедуру входа пользователя в систему и запуска от имени его учетной записи процессов);
user: S \to U — функция принадлежности субъект-сессии учетной записи пользователя, задающая для каждой субъект-сессии учетную запись пользователя, от имени которой она активизирована;
E=O\cup C — конечное непустое множество сущностей (всех «пассивных» компонентов защищенной ОС, к которым назначаются права доступа, включающее файлы, каталоги, порты, сокеты, очереди, семафоры и другие объекты хранения данных, сетевого и межпроцессного взаимодействия), где O — множество объектов (например, файлов), C — множество контейнеров (например, каталогов) и O\cap C=\varnothing .

Также определим:

NAMES — множество допустимых имен сущностей, ролей и административных ролей;
entity\_name: C \times E \to 2^{NAMES} — функция имен сущностей в составе сущностей-контейнеров. При этом для любых контейнеров c,\ cx \in C по определению выполняются условия:
- |entity\_name(c, cx)| \leq 1 ;
- если c \neq cx и существует cy \in C такой, что entity\_name(c,cy) \neq \emptyset , то entity\_name(cx,cy) = \emptyset ;
- существует единственная сущность «корневой контейнер» ROOT \in C такая, что entity\_name(c,ROOT) = \emptyset и, если c \neq ROOT , то существует единственная последовательность контейнеров c_1 = c, c_2, \ldots, c_n = ROOT \in C такая, что n \geqslant 2 и entity\_name(c_i, c_{i-1}) \neq \emptyset , где 1 < i \leqslant n .

В большинстве ОС сущности образуют иерархические, древовидные структуры, для представления которых в модели вводится определение иерархии сущностей.

Определение 3.1. Иерархией сущностей называется заданное на множестве сущностей E бинарное отношение « \leqslant », удовлетворяющее условию: для двух сущностей e, ex \in E , выполняется отношение e \leqslant ex , когда либо e = ex, либо существует последовательность сущностей e_1 = e, e_2, \ldots, e_n = ex \in E такая, что n \geqslant 2 и entity\_name(e_i, e_{i-1}) \neq \emptyset , где 1 < i \leqslant n . В случае, когда для двух сущностей e_1,e_2\in E выполняются условия e_1\leqslant e_2 и e_1\neq e_2 , будем говорить, что сущность e_1 содержится в сущности-контейнере e_2 , и будем использовать обозначение e_1< e_2 . Определим функцию иерархии сущностей H_E\colon E\to 2^E , где для e\in E выполняется H_E(e)=\{ex\in E\mid entity\_name(e,ex)\neq\varnothing\}.

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

Определение 3.2. Иерархией субъект-сессий называется заданное на множестве S отношение частичного порядка « \leqslant », удовлетворяющее условию: если для субъект-сессии s \in S существуют субъект-сессии s_1, s_2 \in S такие, что s \leqslant s_2, s \leqslant s_1 , то s_1 \leqslant s_2 или s_2 \leqslant s_1 . В случае, когда для двух субъект-сессий s_1, s_2 \in S выполняются условия s_1 \leqslant s_2 и s_1 \neq s_2 , будем говорить, что субъект-сессия s_1 является потомком s_2 , и будем использовать обозначение s_1 < s_2 . Определим H_S : S \to 2^S — функцию иерархии субъект-сессий (сопоставляющую каждой субъект-сессии s \in S множество субъект-сессий H_S(s) \subset S , непосредственно в ней содержащихся), удовлетворяющую условиям:

если субъект-сессия s_1\in H_S(s_2) , то s_1< s_2 , и не существует субъект-сессии s\in S такой, что s_1< s< s_2 .
для любых субъект-сессий s_1, s_2 \in S, s_1 \neq s_2 выполняется равенство H_S(s_1) \cap H_S(s_2) = \emptyset .

Заметим, что в рамках МРОСЛ ДП-модели иерархия сущностей задана не «абстрактной» функцией H_E , а реализуемой явно в ОССН функцией имен сущностей в составе сущностей-контейнеров entity_name, что, кроме того, позволит в дальнейшем описать правила предоставления содержимого контейнеров (например, списков файлов и каталогов, выдаваемых в реальной ОССН по команде ls) с учетом параметров мандатного управления доступом. При этом учтено наличие механизма создания «жестких» ссылок (hard link) в файловой системе ОССН, обеспечивающего возможность размещения сущностей-объектов одновременно в нескольких сущностях-контейнерах, в том числе несколько «жестких» ссылок на одну сущность-объект в составе одной сущности-контейнере. Также описаны свойства корневой сущности-контейнера ROOT, как правило, соответствующей в реальных защищенных ОС корневому каталогу «/».

Еще одним важным отличием МРОСЛ ДП-модели от других ДП-моделей и классических моделей является то, что множество субъект-сессий не входит во множество сущностей. Это связно с тем, что в реальной ОССН функции управления доступом к субъект-сессиям (процессам) и сущностям (файлам, каталогам) реализуются раздельно. Таким образом, иерархия на множестве субъект-сессий определяется независимо от иерархии сущностей и при реализации в ОССН может быть задана двумя способами. Первый способ, когда существует явная связь между родительскими субъект-сессиями и их потомками (например, когда при завершении работы родительской субъект-сессии завершают работу ее субъект-сессии потомки, подчиненные родительской в иерархии). Второй способ, когда порожденная субъект-сессией другая субъект-сессия функционирует независимо, в этом случае подчинение ее в иерархии родительской субъект-сессии нецелесообразно.

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

Для введения ролей на базовом уровне иерархического представления МРОСЛ ДП-модели используем следующие обозначения:

R — множество ролей;
AR — множество административных ролей, при этом по определению AR\cap R=\varnothing (административные роли — особый вид ролей, предназначенный для изменения множеств прав доступа ролей, авторизации на роли, а также выполнения функций по администрированию системы, например управления мандатными уровнями конфиденциальности сущностей и субъект-сессий);
SAR \subset AR — множество специальных административных ролей, которые не могут создаваться, удаляться, переименовываться, менять свои параметры в процессе функционирования системы;
R_r = \{read_r, write_r, execute_r, own_r\} — множество видов прав доступа;
R_a = \{read_a, write_a\} — множество видов доступа.

Поскольку в ОССН реализованы три вида прав доступа к сущностям: на чтение, на запись и на выполнение (или на использование контейнера-каталога), а также при управлении доступом к сущностям и субъект-сессиям учитывается наличие у каждой из них уникального владельца, имеющего право передавать права доступа к ним другим учетным записям пользователей, то соответственно в рамках МРОСЛ ДП-модели будем использовать виды прав доступа read_r , write_r , execute_r , own_r . Кроме того, так как в ОССН при получении субъект-сессиями доступов к сущностям они реализуют одну из двух (или обе) основных возможностей: читать или записывать в сущности данные (например, когда процесс открывает доступ к файлу на чтение или на запись), то в модели заданы следующие виды доступов read_a и write_a :

P\subseteq (E\times R_r)\cup (S\times \{own_r\}) — множество прав доступа к сущностям и субъект-сессиям;
AP\subseteq (R\cup AR)\times R_r — множество административных прав доступа к ролям или административным ролям;
A\subseteq S\times E\times R_a — множество доступов субъект-сессий к сущностям;
AA\subseteq S\times (R\cup AR)\times R_a — множество доступов субъект-сессий к ролям или административным ролям;
PA:\ R\cup AR\to 2^P — функция прав доступа к сущностям ролей и административных ролей, при этом для каждого права доступа p\in P существует роль r\in R\cup AR такая, что выполняется условие p\in PA(r) ;
APA: AR \to 2^{AP} — функция административных прав доступа к ролям и административным ролям административных ролей, при этом для каждого административного права доступа ap \in AP существует административная роль ar \in AR такая, что выполняется условие ap \in APA(ar) ;
shared\_container: C \cup R \cup AR \to \{true, false\} — функция разделяемых контейнеров такая, что сущность-контейнер, роль или административная роль c \in C \cup R \cup AR является разделяемой, когда shared\_container(c) = true , в противном случае shared\_container(c) = false ;
V\colon E\cup R\cup AR \to \{(a_1,\dots,a_n)\colon a_i\in\{0,1\}, 1\leqslant i\leqslant n,n\geqslant 1\}\cup \cup\{\varnothing\} — функция значений сущностей, ролей и административных ролей (как аналогов сущностей-контейнеров), задающая возможность для каждой из них принимать значение любой (в том числе пустой) конечной последовательности битов;

role\_name: (R \cup AR) \times (R \cup AR) \to NAMES — функция имен ролей и административных ролей в составе роли или административной роли (как контейнера). При этом для любых ролей или административных ролей r, rx \in R \cup AR по определению выполняются условия:

|role\_name(r, rx)| \leq 1 ;
если role\_name(r, rx) \neq \emptyset , то либо r, rx \in R , либо r, rx \in AR ;
для роли или административной роли ry \in R \cup AR справедливо role\_name(r,ry) = role\_name(rx,ry);
если существует последовательность ролей или административных ролей r_1=r,r_2,\ldots,r_n=rx\in R\cup AR такая, что n\geqslant 2 и role\_name(r_i,r_{i-1})\neq\varnothing , где 1< i\leqslant n , то не существует последовательности ролей или административных ролей rx_1=rx,rx_2,\ldots,rx_m=r\in R\cup AR такой, что m\geqslant 2 и role\_name(rx_i,rx_{i-1})\neq\varnothing , где 1< i\leqslant m ;
для административной роли ar \in AR , если (r, read_r) \in APA(ar) и role\_name(r, rx) \neq \emptyset , то выполняется условие (rx, read_r) \in APA(ar) .

Роли также образуют иерархическую структуру, что было предусмотрено еще в классических ролевых моделях семейства RBAC. Это упрощает администрирование политики безопасности, делает ее более понятной для пользователей и администраторов компьютерной системы. Например, довольно часто ролевая иерархия задается в соответствии с должностной иерархией пользователей компьютерной системы.

Определение 3.3. Иерархией ролей или административных ролей называется заданное на множестве ролей R или AR соответственно бинарное отношение « \leqslant », удовлетворяющее условию: для ролей или административных ролей r, rx \in R \cup AR выполняется отношение r \leqslant rx , когда либо r = rx, либо существует последовательность ролей или административных ролей r_1 = r, r_2, \ldots, r_n = rx \in R \cup AR такая, что n \geqslant 2 и role\_name(r_i, r_{i-1}) \neq \varnothing , где 1 < i \leqslant n . В случае, когда для двух ролей или административных ролей r_1, r_2 \in R \cup AR выполняются условия r_1 \leqslant r_2 и r_1 \neq r_2 , будем говорить, что роль или административная роль r_1 содержится в роли или административной роли r_2 , и будем использовать обозначение r_1 < r_2 . Определим функцию иерархии ролей или административных ролей H_R : R \cup AR \rightarrow 2^R \cup 2^{AR} , где для r \in R \cup AR выполняется H_R(r) = \{rx \in R \cup AR \mid role\_name(r, rx) \neq \varnothing\} .

В отличие от других ролевых моделей МРОСЛ ДП-модель предлагает рассматривать роли как аналог сущностей-контейнеров [34], к которым субъект-сессии могут иметь (через административные роли) права доступа и получать доступы. При этом в рамках МРОСЛ ДП-модели иерархии ролей и административных ролей заданы (по аналогии с иерархией сущностей) не функцией H_R , а функцией имен ролей в составе ролей-контейнеров role_name. Таким образом, право доступа own_r — владелец роли, read_r — право получать роль как текущую, просматривать ее параметры, write_r право изменять множество прав доступа роли, execute_r — право обращаться к ролям, подчиненным данной роли в иерархии ролей (по умолчанию предполагается, что такое право доступа к ролям имеется всегда); доступ read_a — получение субъект-сессией роли как текущей, доступ write_a — изменение прав доступа роли или состава ролей, подчиненных ей в иерархии. Имеющиеся в ОС привилегии целесообразно задать административными или «обычными» ролями, это обеспечит целостность механизма управления доступом в ОССН и, кроме того, позволит в дальнейшем присваивать ролям-привилегиям уровни конфиденциальности и уровни целостности. В результате закладывается основа единого механизма мандатного управления доступом и мандатного контроля целостности для доступов к сущностям, получения в качестве текущих и администрирования ролей субъект-сессиями, с возможностью противодействия в дальнейшем запрещенным информационным потокам по памяти или по времени.

Кроме того, для сущностей-контейнеров, ролей и административных ролей задана функция разделяемых контейнеров (помечаемых в ОССН атрибутом (t)) и функция их значений. При реализации иерархий ролей в реальной ОССН по аналогии с файловой системой можно использовать виртуальную структуру сущностей-ролей, отличающуюся от структур для файлов наличием «жестких» ссылок не только на роли-«объекты» (роли, которым в иерархии не подчинена ни одна другая роль), но и на роли-«контейнеры» (роли, которым в иерархии подчинена хотя бы одна роль).

В моделях семейства RBAC и других ролевых ДП-моделях предполагалось, что функция авторизованных ролей учетных записей пользователей UA обладает свойством «наследования» подчиненных ролей, т. е. выполняется следующее условие: для учетной записи пользователя u \in U , если роли r, r' \in R такие, что r \in UA(u) и r' \leqslant r , то выполняется условие r' \in UA(u) . Это обеспечивается «наследованием» административной ролью права доступа read_r от данной роли ко всем подчиненным ей ролям в иерархии. При этом права доступа write_r и own_r таким свойством не обладают, что может позволить гибко задавать «диапазоны» администрируемых ролей по аналогии с моделью ролевого администрирования ARBAC.

Ранее в моделях семейства RBAC и ролевых ДП-моделях для задания текущих ролей использовалась функция roles [35, 36], а для администрирования ролей функции вида can\_assign , can\_revoke и can\_manage\_rights , которые потребовали бы отдельной реализации в ОССН. В МРОСЛ ДП-модели для этого используются контролируемые системой мандатного управления доступом доступы субъект-сессий к ролям (задаются множество AA) и административные права доступа административных ролей (задаются функцией APA). При этом для обеспечения большего быстродействия ОССН при проверке прав доступа субъект-сессий к сущностям целесообразно для каждой субъект-сессии хранить списки (по аналогии со списком привилегий) текущих ролей, к которым она имеет соответственно доступы read_a или write_a .

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

execute\_container : S \times C \times E \to \{true, false\} — функция доступа субъект-сессии к сущностям в контейнерах такая, что по определению для субъект-сессии s \in S , контейнера c \in C и сущности e \in E справедливо равенство execute\_container(s,c,e)=true тогда и только тогда, когда существует последовательность сущностей e_1,\ldots,e_n\in E , где либо n=1 и c=e=e_1 , либо n\geqslant 2 , c=e_{n-1} , e=e_n и выполняются следующие условия:

не существует сущности-контейнера e_0 \in E такой, что e_1 \in H_E(e_0) ;
верно e_i \in H_E(e_{i-1}) , где 1 < i \leqslant n ;
существует r_i \in R \cup AR такая, что (s,r_i,read_a) \in AA и (e_i,execute_r) \in PA(r_i) , где 1\leqslant i < n .

Также используем следующее обозначение для состояния системы в целом:

G = (APA, PA, user, A, AA, H_R, H_E, H_S),

где:

множества учетных записей пользователей U, сущностей E, субъект-сессий S, прав доступа к сущностям P, доступов субъект-сессий к сущностям A, доступов субъект-сессий к ролям и административным ролям AA;
функции административных прав доступа к ролям административных ролей APA, прав доступа ролей и административных ролей PA, принадлежности субъект-сессий учетным записям пользователей user, иерархии ролей H_R , иерархии сущностей H_E , иерархии субъект-сессий H_S .

Используем обозначение:

\Sigma(G^*, OP) — система, при этом:
- G^* множество всех возможных состояний;
- OP множество правил перехода системы из состояния в состояние, заданных в табл. 3.1 (см. разд. 3.3.3).

Также по традиции с классическими моделями используем следующее обозначение:

G \vdash_{op} G' — переход системы \Sigma(G^*, OP) из состояния G в состояние G’ с использованием правила перехода системы из состояния в состояние op \in OP , при этом, если условия применения правила op не выполняются в состоянии G, то по определению справедливо равенство G = G’.

Если для системы \Sigma(G^*, OP) определено начальное состояние, то будем использовать обозначение \Sigma(G^*, OP, G_0) — система \Sigma(G^*, OP) с начальным состоянием G_0 .

Таким образом, определены все основные элементы, используемые для описания состояний рассматриваемой в рамках базового уровня иерархического представления МРОСЛ ДП-модели абстрактной системы.

3.3.2. Условия консистентности модели

Связи между элементами, задающими каждое состояние абстрактной системы в рамках МРОСЛ ДП-модели и определяющими условия функционирования механизма управления доступом реальной ОССН, строятся не произвольным образом. Имеются ограничения, которые по сути являются критериями корректного, консистентного состояния МРОСЛ ДП-модели, а также переходов из состояния в состояние. Кратко будем называть эти ограничения условиями консистентности модели. Таким образом, консистентность состояний и переходов системы на базовом уровне иерархического представления МРОСЛ ДП-модели состоит в выполнении следующих условий.

Условие 1 (права доступа ролей или административных ролей к субъект-сессиям и доступы субъект-сессий друг к другу):

роли или административные роли могут обладать к субъект-сессиям только правом доступа владения: для роли или административной роли r \in R \cup AR и субъект-сессии s \in S , если (s,\alpha_r) \in PA(r) , то \alpha_r = own_r ;
субъект-сессии не могут иметь друг к другу никаких доступов: для субъект-сессий s,s'\in S выполняется \{(s,s',\alpha_a): \alpha_a\in R_a\}\cap A=\varnothing .

Условие 2 (административные права доступа и иерархия ролей или административных ролей):

все роли и административные роли являются «разделяемыми контейнерами»: для каждой роли или административной роли r \in R \cup AR справедливо равенство shared\_container(r) = true;
у каждой административной роли есть права доступа execute_r ко всем ролям и административным ролям: для каждой административной роли ar \in AR , роли или административной роли r \in R \cup AR выполняется условие (r, execute_r) \in APA(ar) .

Условие 3 (доступы и права доступа, право доступа владения, администрирование параметров прав доступа сущностей, ролей, административных ролей):

к ролям, административным ролям и сущностям субъект-сессии могут иметь любые виды доступа из множества R_a ;
роли и административные роли могут иметь к сущностям любые права доступа из множества R_r , только административные роли могут иметь к ролям или административным ролям права доступа из множества R_r ;
для управления доступом к сущности субъект-сессия должна иметь к ней через соответствующую текущую роль или административную роль право доступа владения;
для каждой сущности или субъект-сессии, если существует, то единственная роль или административная роль, обладающая к ней правом доступа владения, при этом для изменения роли или административной роли, обладающей правом доступа владения к сущности или субъект-сессии, необходимо наличие у субъект-сессии доступа на чтение к административной роли entities_admin_role или subjects_admin_role соответственно: для каждой сущности e \in E выполняется условие |\{r \in R \cup AR: (e, own_r) \in PA(r)\}| \leq 1 , для каждой субъект-сессии s \in S выполняется условие |\{r \in R \cup AR: (s, own_r) \in PA(r)\}| \leq 1 , где entities_admin_role, subjects_admin_role \in SAR ;
для каждой роли существует единственная административная роль roles_admin_role, обладающая к ней правом доступа владения, для каждой административной роли существует единственная административная роль admin_roles_admin_role, обладающая к ней правом доступа владения: для каждой роли r \in R выполняется условие \{ar' \in AR: (r, own_r) \in APA(ar')\} = \{roles\_admin\_role\} , для каждой административной роли ar \in AR выполняется условие \{ar' \in AR: (ar, own_r) \in APA(ar')\} = \{admin\_roles\_admin\_role\} , где roles\_admin\_role , admin\_roles\_admin\_role SAR;
для управления доступом к роли или административной роли субъект-сессия должна иметь доступ на чтение к административной роли roles_admin_role или admin_roles_admin_role соответственно.

Условие 4 (доступ к сущностям в иерархии сущностей). Для получения субъект-сессией любого доступа к сущности, создания «жесткой» ссылки на нее, получения или изменения параметров, прав доступа к ней, активизации из нее субъект-сессии требуется существование последовательности непосредственно вложенных друг в друга сущностей-контейнеров, начинающейся с некоторой сущности-«корневой контейнер» (например, корневой контейнер «/» в ОССН) и заканчивающейся сущностью-контейнером, в состав которой непосредственно входит сама сущность, и наличие у субъект-сессии текущих ролей или административных ролей, обладающих в совокупности правами доступа execute, ко всем сущностям-контейнерам этой последовательности: для состояний системы G и G’, правила перехода системы из состояния в состояние op \in OP таких, что G \vdash_{op} G' , если субъект-сессия s \in S , сущность e \in E , (s, e, \alpha_a) \notin A и (s,e,\alpha_a)\in A' , где \alpha_a\in R_a , то существует контейнер c\in C и execute\_container(s, c, e) = true.

Условие 5 (создание, переименование или удаление сущности, роли или административной роли или «жесткой» ссылки на нее, получение ее параметров):

для создания, переименования или удаления сущности, роли или административной роли или «жесткой» ссылки на нее в сущности-контейнере, роли или административной роли соответственно субъект-сессии необходимо иметь к последней доступ на запись и текущую роль или административную роль, обладающую к последней правом доступа на выполнение execute_r;
для изменения прав доступа роли или административной роли субъект-сессии необходимо иметь к ней доступ на запись, за исключением случаев, когда либо административным ролям назначаются административные права доступа read_r или execute_r к ролям или административным ролям при изменении их иерархии в соответствии условием 2 и определением 3.3, либо удаляются сущности, субъект-сессии, роли или административные роли и, соответственно, удаляются имеющиеся к ним у ролей или административных ролей права доступа;
для переименования, удаления сущности или «жесткой» ссылки на сущность e в сущности-контейнере c ( e \in H_E(c) ), помеченной как разделяемая ( shared\_container(c) = true ), требуется наличие у субъект-сессии доступа на чтение к роли или административной роли, обладающей правом доступа владения own_r к сущности e;
сущности-контейнеры при создании помечаются как неразделяемые. Для изменения метки разделяемости сущности-контейнера субъект-сессии необходимо обладать текущей ролью или административной ролью, имеющей право доступа владения к этой сущности-контейнеру или доступом на чтение к административной роли entities_admin_role;
для получения субъект-сессией данных о ролях или административных ролях, обладающих правами доступа к сущности, требуется либо наличие у субъект-сессии доступа на чтение к административной роли entities_admin_role, либо роли или административной роли, обладающей правом доступа владения own_T к этой сущности;
для получения субъект-сессией данных о ролях или административных ролях, обладающих правом доступа владения к другой субъект-сессии или имеющихся у этой субъект-сессии текущих ролях или административных ролях, требуется либо наличие у первой субъект-сессии доступа на чтение к административной роли subjects_admin_role, либо к роли или административной роли, обладающей правом доступа владения own, ко второй субъект-сессии;
для создания, переименования, удаления, получения параметров роли или административной роли, «жесткой» ссылки на нее, числа «жестких» ссылок к ней, множества административных ролей, обладающих к ней правами доступа, требуется наличие у субъект-сессии доступа на чтение к административной роли roles_admin_role или admin_roles_admin_role соответственно.

Условие 6 (администрирование учетных записей пользователей):

для создания или удаления учетной записи пользователя требуется наличие у субъект-сессии доступа на чтение к административной роли users\_admin\_role \in SAR , доступов на чтение, а при создании и на запись, к административным ролям roles_admin_role и admin_roles_admin_role, при этом множество субъект-сессий, функционирующих от имени данной учетной записи пользователя, должно быть пустым;
для получения субъект-сессией параметров учетной записи пользователя она либо должна функционировать от ее имени, либо иметь текущую административную роль users_admin_role.

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

Условие 8 (вид метки): - для каждой сущности, роли или административной роли задается вид ее метки: прямая или косвенная, который не изменяется в процессе функционирования системы: задается функция direct: E \cup R \cup AR \rightarrow \{true, false\} , где для e \in E \cup R \cup AR , если direct(e) = true, то метка прямая, иначе косвенная; - метка каждой роли или административной роли является прямой: для r \in R \cup AR верно равенство direct(r) = true; - если у некоторой сущности-контейнера метка косвенная, то у всех сущностей ниже ее в иерархии она также косвенная: если для сущности-контейнера c \in C выполняется direct(c) = false, то для всех сущностей e \in E таких, что e \leqslant c , выполняется direct(e) = false; - для каждой сущности с косвенной меткой существует единственная старшая ее в иерархии сущность-контейнер с прямой меткой, для которой все сущности, находящиеся ниже ее в иерархии, имеют косвенные метки, а права доступа всех ролей или административных ролей к ним равны правам доступа к этой сущности-контейнеру: для каждой сущности e \in E такой, что direct(e) = false, существует единственная сущность-контейнер c \in C такая, что direct(e) = true, e < c и для любой сущности e' \in E такой, что e’ < c, верно direct(e’) = false и выполняется (e', \alpha_r) \in PA(r) тогда и только тогда, когда (c, \alpha_r) \in PA(r) ; - в сущностях-контейнерах с косвенной меткой нельзя создавать сущности с прямой меткой или «жесткие» ссылки на них.

В сущности-контейнере с прямой меткой могут создаваться сущности или «жесткие» ссылки на них с метками одного вида. «Жесткая» ссылка на сущность-объект с косвенной меткой может создаваться в сущности-контейнере, подчиненной в иерархии той же самой единственной сущности-контейнеру, которой подчинена в иерархии сама сущность-объект.

Условие 9 (индивидуальная административная и индивидуальная роли учетной записи пользователя, общая роль):

для каждой учетной записи пользователя u \in U задается индивидуальная административная роль u\_admin \in AR , не находящаяся в иерархии других ролей, при этом задано множество всех индивидуальных административных ролей U\_ADMIN = \{u\_admin: u \in U\} . Множество других ролей учетной записи пользователя u задается с использованием административных прав доступа этой административной роли, определяемых функцией APA. На траекториях функционирования системы у этой административной ролей не изменяется имя;
для каждой учетной записи пользователя задается индивидуальная роль, не находящаяся в иерархии других ролей, административными правами доступа на чтение, запись и выполнение к которой обладает ее индивидуальная административная роль: для каждых учетной записи пользователя u \in U задается роль u\_c \in R такая, что (u\_c, \alpha_r) \in APA(u\_admin) , где \alpha_r \in \{read_r, write_r, execute_r\} , при этом задано множество всех индивидуальных ролей U\_ROLES = \{u\_c : u \in U\} ;
задается общая роль common\_role \in R , не находящаяся в иерархии других ролей, административными правами доступа на чтение, запись и выполнение к которой обладают все индивидуальные административные роли всех учетных записей пользователей, и задано множество COMMON\_ROLES = \{common\_role\} : для каждой учетной записи пользователя u \in U выполняется (common\_role, \ \alpha_r) \in APA(u\_admin) , где \alpha_r \in \{read_r, write_r, execute_r\} ;
административные роли roles_admin_role и admin_roles_admin_ role не используются для нарушения правил назначения административных прав доступа к индивидуальным административным ролям, индивидуальным ролям учетных записей пользователей и общим ролям.

Условие 10 (доступы субъект-сессии к индивидуальным ролям и общим ролям):

при создании каждой субъект-сессии она получает доступ на чтение к индивидуальной административной роли и доступ на чтение и запись к индивидуальной роли ее учетной записи пользователя и общей роли: для субъект-сессии s \in S выполняются условия (s, user(s)\_admin, read_a) , (s, user(s)\_c, read_a) , (s, common\_role, read_a) , (s, user(s)\_c, write_a) , (s, common\_role, write_a) \in AA ;
при создании каждой субъект-сессии индивидуальная роль ее учетной записи пользователя получает право доступа владения к этой субъект-сессии: для субъект-сессии s \in S выполняется условие (s, own_r) \in PA(user(s)\_c) ;
при удалении субъект-сессии удаляются все ее административные доступы к индивидуальной, индивидуальной административной и общей ролям.

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

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

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

Условие 3 задает общий порядок получения доступов и назначения прав доступа ролей или административных ролей, ролей-«владельцев» к сущностям, субъект-сессиям, ролям или административным ролям, при этом вводятся специальные административные роли entities_admin_role, subjects_admin_role, roles_admin_role и admin_roles_admin_role, используемые для администрирования сущностей, субъект-сессий, ролей или административных ролей соответственно.

Условия 4 и 5 задают порядок получения доступа к сущностям, их создания, переименования или удаления, получения параметров типичный для ОССН, при этом эти условия основаны на ролевом управлении доступом и использовании функции execute_container. Соответствующие условия задаются для осуществления аналогичных действий с ролями и административными ролями, при этом требуются специальные административные роли roles_admin_role и admin_roles_admin_role.

В условии 6 указываются роли, требуемые для администрирования учетных записей пользователей, что в предшествующих ДП-моделях не допускалось. Типичные для ОССН условия создания или удаления субъект-сессий заданы в условии 7.

Для обеспечения возможности задания в ОССН прав доступа к сущностям, находящимся в архивах или на внешних устройствах (файловая система которых часто не позволяет хранить права доступа или другие параметры механизма управления доступом, например уровни конфиденциальности или целостности, в соответствии с требованиями МРОСЛ ДП-модели), в условии 8 используются косвенные метки сущностей, с помощью которых указывается, что права доступа ролей или административных ролей к сущности (в дальнейшем уровни конфиденциальности или целостности) наследуются от сущности-контейнера, являющейся «точкой монтирования» к файловой системе архива или внешнего устройства. Так как файловая система ОССН не позволяет создавать «жесткие» ссылки на сущности между файловыми системами различных устройств, то в соответствии с условием 2 такая «точка монтирования» определяется однозначно для каждой сущности с косвенной меткой, а следовательно, однозначно задаются права доступа к ней.

В условиях 9 и 10 в отличие от моделей семейства RBAC и других ролевых ДП-моделей впервые вместо функций UA и AUA для задания авторизованных ролей и административных ролей учетных записей пользователей используются права доступа их индивидуальных административных ролей, задаваемых функцией APA. Такой подход позволяет реализовать ролевое управление доступом — назначение прав доступа учетным записям пользователей только через роли. Также достигается большая совместимость со штатными механизмами управления доступом реальной ОССН. Для обеспечения возможности функционирования в реальной ОССН субъект-сессии (процессу) необходимо предоставить хотя бы одну индивидуальную роль, обладающую или имеющую возможность получения прав доступа к сущностям (особенно при их создании), «принадлежащим» только учетной записи пользователя, от имени которой функционирует субъект-сессия. Например, такие сущности могут располагаться в «домашнем» каталоге («/home/user»). Кроме того, для представления прав доступа ролей, которые в реальных дискреционных ОС семейства Linux задаются «для всех остальных» учетных записей пользователей, аналогично индивидуальным ролям учетных записей пользователей используется общая роль. На базовом уровне модели она единственная, на последующих уровнях модели их может быть несколько, поэтому для общих ролей задано соответствующее множество COMMON_ROLES. Таким образом, с использованием индивидуальных административных, индивидуальных ролей учетных записей пользователей и общей роли легко выразить традиционный для ОС семейства Linux подход к реализации дискреционного управления доступом.

3.3.3. Де-юре правила перехода системы из состояния в состояние

МРОСЛ ДП-модель, как и большинство классических моделей политик безопасности управления доступом [9], является автоматной, а значит, после задания состояний моделируемой абстрактной системы должна быть задана функция переходов, которая в модели по традиции определяется через описание правил перехода системы из состояния в состояние.

В рамках базового уровня иерархического представления МРОСЛ ДП-модели используются правила перехода системы из состояния в состояние из множества OP, которые по аналогии с моделью Take-Grant классифицированы на де-юре правила — правила, которые требуют реализации в ОССН, т. е. приводящие к «реальным» изменениям ее параметров: изменению множеств прав доступа ролей, получению доступов субъект-сессий к сущностям или ролям и т. д.; и де-факто правила — правила, которые не требуют реализации в ОССН, так как используются в модели для отражения факта получения субъект-сессией де-факто владения субъект-сессиями или факта реализации информационного потока по памяти или по времени. В связи с этим на базовом уровне иерархического представления МРОСЛ ДП-модели задаются только де-юре правила перехода системы из состояния в состояние (табл. 3.1).

Таблица 3.1

Де-юре правила перехода системы из состояния в состояние на базовом уровне иерархического представления МРОСЛ ДП-модели

Исходное состояние G

Результирующее состояние G'

1. create_user(x, u)

Исходное состояние G:

\begin{aligned} & x \in S, \\ & u \notin U, \\ & (x, users\_admin\_role, read_{a}) \in AA, \\ & (x, roles\_admin\_role, \alpha_{a}) \in AA, \\ & (x, admin\_roles\_admin\_role, \alpha_{a}) \in AA, \\ & \text{ где } \alpha_{a} \in \{read_{a}, write_{a}\} \end{aligned}