CC BY
147
2012 Математические основы компьютерной безопасности №1(15)
МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ
УДК 004.94
РОЛЕВАЯ ДП-МОДЕЛЬ УПРАВЛЕНИЯ ДОСТУПОМ И ИНФОРМАЦИОННЫМИ ПОТОКАМИ В ОПЕРАЦИОННЫХ СИСТЕМАХ СЕМЕЙСТВА Linux
П. Н. Девянин
Институт криптографии, связи и информатики, г. Москва, Россия E-mail: peter_devyanin@hotmail.com
Базовая ролевая ДП-модель управления доступом и информационными потоками в операционных системах (БРОС ДП-модель) достраивается до ролевой ДП-модели управления доступом и информационными потоками в операционных системах (ОС) семейства Linux (РОСЛ ДП-модели). Описываются ее новые элементы: имена сущностей, мандатные атрибуты целостности сущностей-контейнеров, функция де-факто владения. Основное отличие модели — четкое разделение де-юре правил преобразования состояний (требующих реализации в ОС) и де-факто правил (используемых только для анализа условий нарушения безопасности системы). Рассматриваются ограничения, инвариантные относительно немонотонных правил преобразования состояний. С учетом внесенных изменений обосновывается утверждение о возможности использования только монотонных правил преобразования состояний для анализа условий передачи прав доступа ролей, получения доступов или реализации информационных потоков.
Ключевые слова: компьютерная безопасность, ролевая ДП-модель, операционная система Linux.
1. Введение. Этапы разработки ролевых ДП-моделей
Одним из направлений развития теории компьютерной безопасности является адаптация формальных моделей логического управления доступом и информационными потоками к условиям функционирования реальных компьютерных систем, в особенности ОС. Существующие ОС включают механизмы дискреционного или мандатного управления доступом, сложность реализации которых существенно превосходит возможности аппарата формальных моделей, ориентированных на анализ безопасности этих механизмов. Классические модели, например Take-Grant или Белла — ЛаПаду-лы [1], в основном устарели и не позволяют учитывать свойства современных ОС, существенно влияющие на их безопасность [2]. Таким образом, целесообразна постепенная детализация формальных моделей, уточнение описания их элементов, отработка в рамках моделей техники строгого теоретического обоснования свойств ОС.
Хотя ролевое управление доступом является достаточно сложным механизмом обеспечения безопасности компьютерных систем как с точки зрения научного исследования его свойств, так и с учетом особенностей его практической реализации, оно является одним из самых перспективных, в том числе для применения в ОС. В связи
с этим разработка семейства моделей ролевого управления доступом и информационными потоками (ролевых ДП-моделей) осуществлялась автором поэтапно.
На первом этапе на базе ролевых моделей семейства RBAC, дискреционных и мандатных ДП-моделей была построена базовая ролевая ДП-модель (БР ДП-модель) [1], в рамках которой отработана техника обоснования необходимых и достаточных условий передачи прав доступа ролей и реализации информационных потоков по памяти (для случая, когда на траекториях функционирования системы субъект-сессии не получают доступа владения друг к другу с использованием информационных потоков по памяти к функционально ассоциированным с субъект-сессиями сущностям).
На втором этапе с использованием ДП-модели с функционально или параметрически ассоциированными с субъектами сущностями (ФПАС ДП-модели) [3], моделей мандатной политики целостности информации Биба и мандатного ролевого управления доступом [1] была разработана базовая ролевая ДП-модель управления доступом и информационными потоками в ОС (БРОС ДП-модель) [4]. В нее по сравнению с БР ДП-моделью включены некоторые специфичные современным ОС элементы: учетные записи пользователей, сущности, параметрически ассоциированные с субъект-сессиями или ролями («знание» которых — реализация от которых информационных потоков по памяти — позволяет недоверенным субъект-сессиям получить контроль над доверенными субъект-сессиями), де-факто роли, права доступа, возможности и доступы недоверенных субъект-сессий (получаемые ими за счет контроля над доверенными субъект-сессиями), мандатный контроль целостности. Это позволило смоделировать применяемые в ряде современных ОС соответствующие механизмы защиты (например, механизмы MIC — Mandatory Integrity Control и UAC — User Account Control в ОС семейства Microsoft Windows). Основное внимание в БРОС ДП-модели было уделено уточнению условий и результатов применения правил преобразования состояний с учетом включенных в нее новых элементов. Кроме того, так же, как в предыдущих ДП-моделях, была обоснована возможность использования только монотонных правил преобразования состояний при анализе условий передачи прав доступа, реализации информационных потоков по памяти или по времени.
На третьем реализуемом в настоящее время автором этапе исследований формируется ролевая ДП-модель управления доступом и информационными потоками в ОС семейства Linux (РОСЛ ДП-модель), основные элементы которой описаны в [5]. Эта модель не сформирована окончательно, в нее (по сравнению с БРОС ДП-моделью) вносятся изменения, направленные в первую очередь на постепенную адаптацию модели к условиям функционирования реальных ОС, на создание предпосылок для разработки механизма управления доступом в защищенных ОС рассматриваемого семейства на основе формальной модели. Рассмотрим эти изменения подробнее.
2. Состояние системы
При описании состояния системы в рамках РОСЛ ДП-модели скорректированы предположения 1 и 5 БРОС ДП-модели (см. [4]), в которых вместо информационных потоков по памяти к сущностям рассматриваются доступы на чтение к ним субъект-сессий. Это связано с тем, что в реальных ОС возникновение информационных потоков является «де-факто следствием» «де-юре получения» субъект-сессиями доступов к сущностям. Кроме того, дополнительно определены следующие функции:
1) shared_container : C ^ {true, false} — функция разделяемых контейнеров: сущность-контейнер c Е C \ S является разделяемой, когда shared_container(c) = = true, в противном случае shared_container (c) = false;
2) entity_name : (C \ S) x (E \ S) ^ NAMES — функция имен сущностей (не являющихся субъект-сессиями) в составе сущностей-контейнеров (также не являющихся субъект-сессиями), где NAMES — некоторое множество допустимых имен сущностей, включающее элемент «»—пустая строка. При этом по определению если e Е He (c), то entity_names(c,e) = «», иначе entity_names(c,e) = «»;
3) CCRI : E \ S ^ {true, false} — функция, задающая способ доступа к сущностям, не являющимся субъектами, внутри контейнеров (с учетом их меток мандатных уровней целостности). Если сущность e Е C является контейнером и доступ к сущностям, содержащимся внутри контейнера e, разрешен без учета уровня целостности контейнера e, то по определению выполняется равенство CCRI(e) = false, в противном случае выполняется равенство CCRI(e) = true. При этом по определению для каждой сущности e Е E, являющейся объектом, выполняется условие CCRI(e) = false;
4) execute_container : S x E ^ {true, false} — функция доступа субъект-сессии к сущностям в контейнерах, такая, что по определению для субъект-сессии s Е S и сущности e Е E справедливо равенство execute_container(s,e) = true тогда и только тогда, когда либо e Е S, либо e Е E \ S и существует последовательность сущностей ei,... ,en Е E, где n ^ 1, e = en, удовлетворяющих следующим условиям:
— не существует сущности-контейнера eo Е E \ S, такой, что e1 Е He(e0);
— ei Е He (ei-1), где 1 < i ^ n;
— (ei,executer) Е PA(roles(s)) и либо ie(ei) ^ is(s), либо CCRI(ei) = false, где
1 ^ i < n.
Таким образом, для сущностей-контейнеров задана функция разделяемых контейнеров (помечаемых в ОС атрибутом «t»), а для всех сущностей, не являющихся субъект-сессиями, определены их имена в составе сущностей-контейнеров. По аналогии с моделью систем военных сообщений [1] добавлен также мандатный атрибут целостности сущностей-контейнеров — CCRI, а с использованием функции execute_container заданы условия доступа субъект-сессии к сущности с учетом ее текущих прав доступа ко всем сущностям-контейнерам, в которые входит данная сущность.
С учетом дополнительных элементов модели в предположении 6 (см. [4]) уточнено, что в начальном состоянии G0 любой системы T,(G*, OP, G0) выполняются следующие условия:
— функции UA0, PA0 и roles0 удовлетворяют соответствующим ограничениям Constraintu, Constraintp, Constraints;
— для любых субъект-сессии s Е S0 и сущности e Е E0 если (s,e,aa) Е A0 (т. е. доступ уже имеется в начальном состоянии системы), где аа Е Ra, то справедливо равенство execute_container(s, e) = true (этот доступ мог быть получен субъект-сессией s только с учетом ее текущих прав доступа ко всем сущностям-контейнерам, в которые входит сущность e).
Предположения 7 и 9 дополнены и частично переформулированы. Предположение 7. Уровень целостности роли не превосходит уровней целостности ролей, которым она подчинена в иерархии ролей. Уровень целостности сущности, входящей в состав сущности-контейнера и не являющейся субъект-сессией, не превосходит уровня целостности сущности-контейнера. Уровни целостности сущностей, параметрически ассоциированных с учетной записью пользователя, совпадают с ее уровнем целостности. Текущий уровень целостности субъект-сессии не превосходит уровня целостности учетной записи пользователя, от имени которой она функционирует, и текущего уровня субъект-сессии, которой она подчинена в иерархии. При этом
в дополнение к предположению 1 недоверенная субъект-сессия всегда может создать недоверенную субъект-сессию с низким уровнем целостности. Уровень целостности роли не может быть выше уровня целостности учетной записи пользователя, которая на нее может быть авторизована, и текущего уровня целостности субъект-сессии, во множество текущих ролей которой она входит. Права доступа владения ownr и на запись writer к сущности, не являющейся субъект-сессией, могут принадлежать только ролям, имеющим уровень целостности не ниже, чем уровень целостности сущности. Право доступа владения ownr к субъект-сессии может принадлежать только ролям, имеющим уровень целостности не ниже, чем уровень целостности субъект-сессии. Таким образом, выполняются следующие условия:
1. Для ролей r,rJ Е R U AR, если r ^ r', то ir (r) ^ ir (r').
2. Для сущностей e,e' Е E \ S, если e ^ e', то ie(e) ^ ie(e').
3. Для субъект-сессий s, s' Е S, если s ^ s', то is(s) ^ is(s').
4. Для каждой сущности e Е ]u[, где и Е U, справедливо равенство ie(e) = iu(u).
5. Для субъект-сессии s Е S верно неравенство is(s) ^ iu(user(s)).
6. Для учетной записи пользователя u Е U и роли r Е R, если r Е UA(u), то
ir (r) ^ iu(u).
7. Для субъект-сессии s Е S и роли r Е R, если r Е roles(s), то ir(r) ^ is(s).
8. Для права доступа к сущности (e, а) Е P, где а Е {ownr, writer}, и роли r Е R,
если (e, а) Е PA(r), то или e Е E \ S и ie(e) ^ ir(r), или e Е S, а = ownr и
is(e) ^ ir(r).
Предположение 9. Субъект-сессии могут иметь друг к другу только доступ владения owna. Роли могут обладать к субъект-сессиям только правом доступа владения ownr. К сущностям, не являющимся субъект-сессиями, субъект-сессии могут иметь любые виды доступа из множества Ra, а роли могут иметь к таким сущностям любые права доступа из множества Rr. Для управления доступом к сущности субъект-сессия должна получить к ней доступ владения. Для создания, переименования или удаления сущности или «жесткой» ссылки на нее в сущности-контейнере субъект-сессии необходимо иметь к сущности-контейнеру доступ на запись. Для переименования, удаления сущности или «жесткой» ссылки на сущность e в сущности-контейнере c (e Е He (c)), помеченной как разделяемая (shared_container(c) = true), требуется наличие у субъект-сессии текущей роли, обладающей правом доступа владения ownr к сущности e. При этом для осуществления субъект-сессией любых действий над сущностью (управление к ней доступом, получения доступа, создания, удаления и др.), не являющейся субъект-сессией, требуется существование последовательности непосредственно вложенных друг в друга сущностей-контейнеров, начинающейся с некоторой сущности-«корневой контейнер» (например, корневой контейнер «/» в ОС семейства Linux) и заканчивающейся сущностью-контейнером, в состав которой непосредственно входит сама сущность, и наличие у субъект-сессии:
— текущих ролей, обладающих в совокупности правами доступа executer ко всем сущностям-контейнерам этой последовательности;
— возможности получения доступа (с учетом уровня целостности субъект-сессии) внутрь всех сущностей-контейнеров этой последовательности с учетом их уровней целостности и мандатных атрибутов целостности CCRI.
Таким образом, с учетом предположения 5 всегда справедливо:
— для субъект-сессий s, s' Е S, если (s, s', аа) Е A, то аа = owna;
— для роли r Е R, если (s, аr) Е PA(r), где s Е S, то а,г = ownr;
— для субъект-сессии s Е S и сущности e Е E, если (s,e,aa) Е A, то execute _container(s,e) = true.
Ранее при разработке ДП-моделей для отражения ситуации, когда одна субъект-сессия получает контроль над другой субъект-сессий, использовалось право доступа владения owna. В то же время в реальных ОС такой доступ не всегда может быть явно задан как ее параметр. Например, когда субъект-сессия осуществляет отладку другой субъект-сессии, можно считать, что этот доступ задан явно, а когда первая субъект-сессия через переполнение буфера памяти (реализацию информационного потока по памяти к сущности, функционально ассоциированной с другой субъект-сессий) получила над ней контроль, доступ владения явно не предоставляется. В связи с этим используем обозначение и следующие формулировки предположений 10 и 11: de_facto_own : S ^ S — функция де-факто владения субъект-сессиями, т. е. по определению будем говорить, что субъект-сессия s де-факто владеет субъект-сессией s', когда выполняется условие s' Е de_facto_own(s). При этом по определению всегда s Е de_facto_own(s) (субъект-сессия де-факто владеет сама собой) и если (s,s',owna) Е A, то s' Е de_facto_own(s) (если есть де-юре владение, то есть и дефакто владение).
Предположение 10. Если субъект-сессия s реализовала информационный поток по памяти от себя к сущности, функционально ассоциированной с другой субъект-сессией s', или субъект-сессия s реализовала информационный поток по памяти к себе от всех сущностей, параметрически ассоциированных с другой субъект-сессией s', то субъект-сессия s получает де-факто владение субъект-сессией s' (s' Е de_facto_own(s)).
Предположение 11. Если субъект-сессия s де-факто владеет субъект-сессией s', то субъект-сессия s получает следующие возможности:
— использовать роли из множества текущих ролей субъект-сессии s';
— изменять множество текущих ролей субъект-сессии s';
— использовать текущий уровень целостности субъект-сессии s';
— использовать доступы субъект-сессии s';
— получать де-факто владение субъект-сессиями, которыми де-факто владеет субъект-сессия s';
— использовать административные роли субъект-сессии s' для осуществления действий над ролями и сущностями, которые позволяют ей изменять права доступа ролей субъект-сессии s';
— использовать информационные потоки, в реализации которых участвует субъект-сессия s';
— удалить субъект-сессию s'.
При этом используем обозначения:
1) de_facto_roles : S ^ 2RL>AR — функция де-факто текущих ролей субъект-сессий, при этом по определению в каждом состоянии системы G для каждой субъект-сессии s Е S верно равенство de_facto_roles(s) = {r Е R U AR: существует s' Е S, такая, что s' Е de_facto_own(s) и r Е roles(s')};
2) de_facto_rights : S ^ 2P — функция де-факто текущих прав доступа субъект-сессий, при этом по определению в каждом состоянии системы G для каждой субъект-сессии s Е S верно равенство de_facto_rights(s) = {p Е P: существует r Е de_facto_roles(s), такая, что p Е PA(r)};
3) de_facto_accesses : S ^ 2A — функция де-факто доступов субъект-сессий, при этом по определению в каждом состоянии системы G для каждой субъект-сессии s Є S верно равенство de_facto_accesses(s) = {(s',e,aa) : s' Є de_facto_own(s), (s',e,a,a) Є A}.
Заметим, что функция де-факто возможностей субъект-сессий (de_facto_actions) более в рамках РОСЛ ДП-модели не рассматривается.
3. Правила преобразования состояний
В рамках РОСЛ ДП-модели используются следующие правила преобразования состояний из множества OP (табл. 1 и 2), которые либо добавлены впервые, либо существенно отличаются от правил БРОС ДП-модели. По аналогии с моделью Take-Grant их можно неформально классифицировать на де-юре правила (правила, которые требуют реализации в ОС, то есть приводящие к «реальным» изменениям ее параметров: изменению множеств текущих ролей, прав доступа ролей, получению доступов субъект-сессий к сущностям и т.д.) и де-факто правила (правила, которые не требуют реализации в ОС, так как используются в модели для отражения факта получения субъект-сессией де-факто владения субъект-сессиями или факта реализации информационного потока по памяти или по времени).
Таким образом, в рамках РОСЛ ДП-модели заданы 18 де-юре и 11 де-факто правил преобразования состояний. Проанализируем их наиболее существенные отличия от аналогичных правил БРОС ДП-модели.
Во всех де-юре правилах, где ранее требовалось выполнение «де-факто условия» — реализация информационного потока по памяти либо от некоторой субъект-сессии к сущности i_entity, либо от сущности e, параметрически ассоциированной с ролью или учетной записью пользователя, к некоторой субъект-сессии, — теперь требуется выполнение «де-юре условия» — наличие у этой субъект-сессии доступа соответственно либо на запись к сущности i_entity, либо на чтение к сущности e. Фактические возможности также заменены на соответствующие доступы — владения, на запись или на чтение.
Правило создания сущности заменено на три правила — создания сущности-объекта, сущности-контейнера и «жесткой» ссылки на сущность. В эти правила, а также в правило переименования сущности добавлен дополнительный параметр — имя сущности (name). Кроме того, в правило создания сущности-контейнера create_container включены параметры t (указывающий, является ли сущность-контейнер разделяемым) и ccri (мандатный атрибут целостности). В связи с этим в модель добавлено новое правило set_container_attr, позволяющее субъект-сессиям изменять параметры t и ccri сущностей-контейнеров.
В условиях выполнения правил получения доступов владения, на чтение или на запись к сущности добавлена проверка прав доступа к сущностям-контейнерам, содержащим эту сущность, что отражает порядок предоставления аналогичных доступов в реальных ОС семейства Linux.
Де-факто правило de_facto_op(x,op(y,y',...)) не имеет аналогов в других ДП-моделях и позволяет субъект-сессии х, де-факто владеющей субъект-сессиями y и y', выполнить от имени y любое де-юре правило. Данное правило позволило исключить из рассмотрения в рамках РОСЛ ДП-модели де-факто возможности субъект-сессий и более ясно описать условия применения де-юре правил преобразования состояний.
Таблица 1
Де-юре правила преобразования состояний РОСЛ ДП-модели
Правило Исходное состояние G = (PA, user, roles, A, F, He) Результирующее состояние G' = (PA', user', roles', A', F', H'E)
1 2 3
take role(x,x', {rj :1 ^ j ^ k}) x,x' Е S, rj Е UA(user(x)) U UAU A(user(x)), {(x,e,reada) : e е]гj[} С A, ir(rj) < is(x), Constraints (roles') = true, [если ir (rj) = i high, то (x',i entity, writea) Е A], где 1 < j < k S' = S, E' = E, PA' = PA, user' = user, A' = A, H'E = HE, roles'(x) = roles(x) U {rj : 1 ^ j ^ k} и для s G S \ \{x} выполняется равенство roles'(s) = roles(s), если x G (Ns U UNFS) П S и {rj : 1 ^ j ^ k}\ roles(x) = 0, то F' = F U {(x, s, writet) : s G (Ns U NFs) П S, x = s и x G de facto own(s)}, иначе F' = F
remove role(x, x' {rj :1 ^ j ^ k}) x,x' Е S, rj Е roles(x), {(x,e,reada) : e E]rj[} С A, , Constraints(roles') = true, [если ir (rj) = i high, то (x',i entity, writea) E A], где 1 < j < k S' = S, E' = E, PA' = PA, user' = user, A' = A, H'E = He, roles'(x) = roles(x) \ {rj : 1 ^ j ^ k} и для s G S \ {x} выполняется равенство roles'(s) = roles(s), если x G (Ns U NFs) П S, то F' = F U U{(x, s,writet): s G (Ns U NFs), x = s и x G de facto own(s)}, иначе F' = F
grant right(x,x', r, {(Vj ,arj ) ■ 1 < j < k}) x, x' E S, yj E E, r E can -manage rights(roles(x)ПAR), (x,yj,owna) E A, ir(r) ^ is(x), [если yj E S, то arj = ownr и is(yj) < ir (r)], [если yj E E \ S и arj E {ownr, writer}, то ie(yj) < ir (r)], [Constraint p (PA') = true], [если ie(yj) = i high, то (x',i entity, writea) E A], где 1 < j < k S' = S, E' = E, user' = user, roles' = roles, A' = A, HE = He, PA'(r) = PA(r)U{(yj,ar.) : 1 ^ j ^ k} и для r' G R \ {r} выполняется равенство PA'(r') = PA(r'), если x G (Ns U NFs) П S, то F' = F U U{(x, s,writet): s G (Ns U NFs) П S, x = s, r G de facto roles(s), и существует j, такое, что 1 ^ j ^ k, (yj,arj ) G PA(r) и (yj, aa) G de facto accesses(s), где aa G Ra}, иначе F' = F
remove right(x, x',r, {(yj,arj) : 1 < j ^ k}) x, x' E S, yj E E, (yj ,arj) E PA(r), r E can -manage rights(roles(x)ПAR), (x,yj , own a) E A, ir (r) < is(x), Constraint p (PA') = true, [если ie(yj) = i high, то (x',i entity, writea) E A], где 1 < j < k S' = S, E' = E, user' = user, roles' = roles, A' = A, HE = He, PA'(r) = PA(r)\{(yj,a^) : 1 ^ j ^ k} и для r' G R \ {r} выполняется равенство PA'(r') = PA(r'), если x G (Ns U NFs) П S, то F' = F U U{(x, s, writet) : s G (Ns U NFs) П S, x = s, r G de facto roles(s), и существует j, такое, что 1 ^ j ^ k и (yj, aa) G de facto accesses(s), где aa G Ra}, иначе F' = F
create object (x, x', r, y, yi, name, z x,x' E S, y E E, z E C \ S, name E NAME\ {«»}, r E can manage rights(roles(x) П AR), (x, z,writea) E A, yi ^ < ir (r) < is(x), yi < ie(z), Constraintp(PA') = true, [если ie(z) = i high, то (x',i entity, writea) E A] S' = S, E' = E U {y} (O' = O U {y}, C' = C), при этом y G UE U RE, user' = user, roles' = = roles, A' = A, i'e(y) = yi, CCRI'(y) = false, entity name (z, y) = name, PA'(r) = PA(r) U{(y, ownr)} и для r' G R\{r} выполняется равенство PA'(r') = PA(r'), HE (z) = He (z) U {y}, HE (y) = 0, для e G G E \ {z} выполняется равенство H'E(e) = = HE(e), если x G (Ns U NFs) П S, то F' = F U {(x, e,writet) : e G E и y ^ e}U U{(x, s,writet) : s G (Ns U NFs) П S,x = = s, r G de facto roles(s) и (z, aa) G de facto accesses(s), где aa G Ra}, иначе F' = F
Продолжение табл. 1
1 2 3
create container (x, x', r, y, yi, ccri, t, name, z) x,x' E S, y E E, z E C \ S, ccri,t E {true, false}, name NAME\ {«»}, r E can manage rights(ro-les(x) П AR), (x, z, writea) E A, yi < ir(r) < is(x), yi < ie(z), Constraintp(PA') = true, [если ie(z) = i high, то (x',i entity, writea) E A] S' = S, E' = E U {y} (O' = O, C' = C U {y}), при этом y G UE U RE, user' = user, roles' = = roles, A' = A, i'e(y) = yi, CCRI'(y) = ccri, entity name(z, y) = name, PA'(r) = PA(r) U{(y, ownr)} и для r' G R\{r} выполняется равенство PA'(r') = PA(r'), H'E (z) = He (z) U {y}, H'E (y) = 0, для e G G E \ {z} выполняется равенство H'E(e) = = He (e), shared container'(y) = t, если x G G (Ns U NFs) П S, то F' = F U {(x, e, writet) : e G E и y ^ e} U {(x, s,writet) : s G (Ns U UNFs) П S, x = s, r G de facto roles(s) и (z,aa) G de facto accesses(s), где aa G Ra}, иначе F' = F
create hard link(x, x', y, name, z) x,x' E S, yEO \ S, zEC \ S, name NAME\ {«»}, y E UEURE, (x, z,writea) E A, ie(y) < ie(z), [если ie(z) = = i high, то (x', i entity, writea) E A] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, entity name(z, y) = name, H'e (z) = He (z) U {y}, для e G E \ {z} выполняется равенство H'E (e) = He (e), если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E и y ^ e}, иначе F' = F
rename entity (x, x', y, name, z) x,x' E S, y, z E E \ S, y E He(z), name NAME\ {«»}, (x, z,writea) E A, [если ie(z) = = i high, то (x', i entity, writea) E A], [если shared -container(z) = true, то (y, ownr) E PA(roles(x))] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE' = HE, entity name(z, y) = name, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e, и или e ^ y, или e = z} U {(x, s, writet): s G (Ns U NFs) П S, x = s, (e, aa) G de facto accesses(s), где e G E, e ^ y, aa G Ra}, иначе F' = F
set container attr(x, x', y, ccri, t x,x' E S, y E C \ S, ccri,t E {true, false}, (x,y,writea) E A, [если ie(y) = = i high, то (x', i entity, writea) E A] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE' = HE, CCRI '(y) = ccri, shared container' (y) = t, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e и e ^ y} U {(x, s, writet): s G (Ns U NFs) П S, x = s, (e, aa) G G de facto accesses (s), где e G E, e ^ y, aa G Ra}, иначе F' = F
delete entity (x, x', y, z) x,x' E S, y E E \ S, zEC \ S, y E He(z), He(y) = 0, [не существует z' E , такой, что z' = z и y E He(z')], [y E E (UEURE), (x, z,writea) E A, Constraintp(PA') = true], [если ie(z) = i high, то (x', i entity, writea) E A], [если shared container(z) = true, то (y, ownr) E PA(roles(x))] S' = S, E' = E \ {y}, user' = user, roles' = roles, H'E (z) = He (z) \ {y}, для всех e E' \ {z} выполняется равенство HE' (e) = = He (e), для r G R выполняется равенство PA'(r) = PA(r)\ {(y, ar): a G Rr}, A' = A\{(s,y,aa): s G S, a.a G Ra}, если x G (Ns U NFs) П S, то F' = (F U U{(x, e,writet) : e G E, x = e и z ^ e} U U {(x, s, writet) : s G (Ns U NFs) П S', x = s и (y,aa) G de facto accesses(s), где aa G G Ra}) \ ({(e,y,af) : e G E,af G Rf} U U{(y, e,af ) : e G E, af G Rf}), иначе F' = F
Продолжение табл. 1
1 2 3
delete hard link(x, x', y, z) x,x' E S, y E O \ S, z E EC \ S, y E He (z), [не существует z' C, такой, что z' = z и y E He (z% [y E (UE U RE), (x, z, writea) E A], [если ie(z) = i high, то (x', i entity, writea) E A], [если shared container(z) = true, то (y,ownr) E PA(roles(x))] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, H'e(z) = He(z) \ {y}, для всех e € E' \ {z} выполняется равенство H'e(e) = = He(e), если x € (NS U NFS) П S, то F' = = (F U {(x, e, writet) : e € E, x = e и или y ^ e, или z ^ e}, иначе F' = F
create first session(x, x', u, r, y, z, zi) x,x' E S, u E U, y E E, z E E, (y,executer) E PA(roles(x)), execute container (x,y)=true, r E can manage rights(ro-les(x) П AR), zi ^ iu(u), zi ^ ir(r), {(x, e, reada): e E]u[} С A, Constraintp(PA') = true, Constraints(roles') = true, [если zi = i high, то (x', i entity, writea) E A] S' = S U {z}, E' = E U {z}, A' = A U {(x, z, owna)}, i's(z) = zi, user'(z) = u, для s€S выполняется равенство user'(s) = user(s), roles'(z) = 0, для s € S выполняется равенство roles'(s) = roles(s), [z] = fa(u,y), ]z[= fp(u,y), PA'(r) = PA(r) U {(z,ownr)} и для r' € R \ {r} выполняется равенство PA'(r') = PA(r'), H'e(z) = 0, для e € E выполняется равенство H'e (e) = He (e), если x € (NSU NFS) П S, то F' = FU{(z, x, writet), (x, z, writet)} U {(x, e, writet) : e € E и y ^ e}U U{(x, s, writet) : s € (NS U NFs) П S, x = s и r € de facto roles(s)}, иначе F' = F
create session(x, x', r, y, z, zi) x,x' E S, y E E, z E E, (y,executer) E PA(roles(x)), execute container (x,y)=true, r E can manage rights(ro-les(x) П AR), zi ^ ir (r) ^ is(x), Constraintp(PA') = true, Constraints(roles') = true, [если zi = i high, то (x', i entity, writea) E A] S' = S U {z}, E' = E U {z}, A' = A U {(x, z, owna)}, i's(z) = zi, user'(z) = user(x), для s S выполняется равенство user'(s) = = user(s), roles'(z) = 0, для s € S выполняется равенство roles'(s) = roles(s), [z] = fa(user(x),y), ]z[= fp(user(x),y), H'e(x) = H= (x) U {z}, H'e(z) = 0, для e € E \ {x} выполняется равенство H'e(e) = H= (e), PA'(r) = PA(r) U {(z,ownr)} и для r' R \ {r} выполняется равенство PA'(r') = PA(r'), если x € (NS U NFS) П S, то F' = F U {(z, x, writet), (x, z, writet)} U {(x, e, writet) : e € E и y ^ e} U {(x, s,writet) : s € (NS U NFs) П S, x = s и r € de facto roles(s)}, иначе F' = F
delete session(x, x', z) x,x',z E S, (x,z,owna) E A, is(z) < is(x), Constraintp(PA') = true, Constraints(roles') = true, [если is(z) = i high, то (x', i entity, writea) E A] S' = S \ {z}, E' = E \ {z}, для s S' верно user'(s) = user(s), roles'(s) = roles(s), для z' € S, такой, что z € H= (z'), верно H'e(z') = (H= (z') \ {z}) U H= (z), при этом выполняется: для e € E' \ {z'} верно H'e(e) = = H= (e), PA'(r) = PA(r) \ {(z, ownr)}, и для r' € R \ {r} верно PA'(r') = PA(r'), A' = A \ ({(z, e, a a) : e € E, a.a € Ra} U {(s, z, owna) : s € S}), если x € (NS U NFs) П S, то F' = (F U {(x, s, writet) : e E, x = e и z < e} U {(x, s, writet) : s € (NS U NFs) П S, x = s и z € de facto own(s)}) \ ({(z,e,a.f) : e € E, af € Rf} U {(e, z, af) : e € E, af € Rf}), иначе F' = F
Окончание табл. 1
1 2 3
access own(x, x',y) x, x' S, y E, x = y, (y,ownr) E PA(roles(x)), execute container(x, y) = true, [если yES, то is(y) < is(x)], [если y E E \ S, то ie(y) ^ < is (x)], [если (yES и is(y) = = i high) или (y E \ S и ie(y) = i high), то (x', i entity, writea) E A] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = He, A' = A U {(x, y, owna)}, если x G (NS U NFS) П S, то F' = F U {(x, e, writet): e G E, x = e и y ^ e} U {(x, s, writet): s G (NS U NFS) П S, x = s и [если y G E \ S, то (y,owna) G de facto accesses(s)], [если y G S, то y G de facto own(s)]}, иначе F' = F
access read(x, x', y) x,x' E S, y E E \ S, (y,readr) E PA(roles(x)), execute container(x, y) = true S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = He, A' = A U {(x,y, reada)}, если x G (NS U NFS) П S, то F' = = F U {(y,x, writem)} U {(x, e, writet) '■ e G E, x = e и y ^ e}, иначе F' = F U {(y, x, writem)}
access write(x, x', y) x,x' E S, y E E \ S, (y,writer) E PA(roles(x)), execute container(x, y) = true, ie(y) < is(x), [если ie(y) = i high, то (x', i entity, writea) E A] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = He, A' = A U {(x, y, writea)}, если x G (NS U NFS) П S, то F' = F U {(x, y, writem)} U {(x, e, writet): e G E, x = e и y ^ e}, иначе F' = F U {(x, y, writem)}
delete access(x, x', y, aa) x, x' E S, y E E \ S, (x, y, aa) E A S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = He, A' = A \ {(x, y, aa)}, если x G (NS U NFS) П S, то F' = F U {(x, e, writet) : e G E, x = e и y ^ e}, иначе F' = F
Таблица 2
Де-факто правила преобразования состояний РОСЛ ДП-модели
Правило Исходное состояние G = (PA, user, roles, A, F, He) Результирующее состояние G' = (PA', user', roles', A', F', HE)
1 2 3
de facto op(x, op(y, y', ...)) x,y,y' G S, y,y' G de facto own(x), выполняются условия применения де-юре правила преобразования состояний op(y, y',...), заданные в табл. 1 Соответствуют результатам применения правила op(y, y',...)
control(x, y, z) x,y G S, x = y, z G [y] и или x = z, или (x, z, writem) G F, или z G S и z G de facto -own(x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H ' = H , de facto own'(x) = de facto own(x) U {y}, если x G (Ns U NFS) П S, то F' = F U {(x, e, writet): e G E, x = e и y ^ e}, иначе F' = F
know(x, y) x, y G S, x = y, и для каждой e G ]y[ существует (e, x, writem) G F S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H ' = H , de facto own'(x) = de facto own(x) U {y}, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e и y ^ e}, иначе F' = F
take access own(x, y, z) x, y, z S, y G de facto own(x), z G de facto own(y) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H ' = H , de facto own'(x) = de facto own(x) U {z}, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e и z ^ e}, иначе F' = F
О к о н ч а н и е т а б л. 2
1 2 3
flow memory access(x, y, aa) x G S, y G E, (y,aa) G de facto accesses(x), где aa G {reada, writea} S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'e = He, если aa = reada, то F' = F U {(y, x, writem)}, если aa = writea, то F' = F U {(x, y, writem)}
flow time access(x, y) x G S, y G E, (y,a.a) G de facto accesses(x) или [y G S и y G de facto own(x)] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'e = He, если x G (Ns U NFS) П S, то F' = F U {(x, e, writet): e G E, x = e и y ^ e} U {(e, x, writet): x = e и e ^ y}, иначе F' = F
flow(x, y, y', z) x, z S, y, y' E, x = z, y < y', [или x = y, или (y, aa) G G de facto accesses (x), или y S и y de facto own(x)], [или z = y', или (y', ßa) G de -facto accesses(z), или y' G S и y' G de facto own(z)], где aa, ßa G Ra S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'e = He, если x, z G (NS U NFS) П S, то F' = F U {(x, z, writet), (z, x, writet)}, иначе F' = F
find(x, y, z) x, y S, z E, x = z, [(x, y, a) G F, где a G {writem, writet}], и [или (z, ß) G de -facto accesses(y), где ß = = writea, или (y, z, ß) F, где ß G {writem,writet}] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE = He, если writet G {a, в}, то F' = F U {(x, z, writem)}, если writet G {a, в} и x, y G (NS U NFS) П S, то F' = F U {(x, z, writet)}, иначе F' = F
post(x, y, z) x, z S, y E, x = z, (y,reada) G de facto accessess(z) и [или (y, a) G de facto accesses(x), где a = writea, или (x, y, a) F, где a G {writem, writet}] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE = He, если a = writet, то F' = F U {(x, z, writem)}, если a = writet и x, z G (Ns U NFs) П S, то F' = F U {(x, z, writet)}, иначе F' = F
pass(x, y, z) y S, x, z E, x = z, (x,reada) G de facto accesses¡(y) и [или (z, a) G de facto accesses(y), где a = writea, или (y, z, a) F, где a G {writem, writet}] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE = He, если a = writet, то F' = F U {(x, z, writem)}, если a = writet и y G (Ns U NFs) П S, то F' = F U {(x, z, writet)}, иначе F' = F
take flow(x, y) x, y G S, x = y, y G de facto own(x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE = He, если x G (NsUNFs) ПS, то F' = FU{(x, e, a) : (y, e, a) G F, e G E, a G {writem, writet}}, иначе F' = F U {(x, e, writem) : (y, e, writem) G F, e G E}
Доступы владения в де-факто правилах take_access_own, flow и take_flow заменены на де-факто владение. Новое правило flow_memory_access позволяет субъект-сессии, имеющей де-факто доступ на чтение или на запись к сущности, реализовать между ними соответствующий информационный поток по памяти, а правило flow_time_access позволяет субъект-сессии, имеющей любой де-факто доступ к сущности или (в случае, когда сущность является субъект-сессией) де-факто владеющей ею, реализовать информационный поток по времени ко всем сущностям и от всех сущностей, которым в иерархии подчинена данная сущность.
Таким образом, зависимости условий и результатов применения де-юре и де-факто правил преобразования состояний РОСЛ ДП-модели существенно изменились. Схе-
ма этих зависимостей показана на рис. 1, на котором сплошными линиями показаны зависимости, возникающие при применении де-юре правил (за исключением информационных потоков), а прерывистыми линиями — зависимости, возникающие при применении де-факто правил или в результате получения информационных потоков при применении де-юре правил.
Рис. 1. Зависимости условий и результатов применения правил преобразования состояний РОСЛ ДП-модели
4. Выполнение ограничений и требований мандатного контроля целостности на траекториях системы
Поскольку в рамках РОСЛ ДП-модели, в отличие от других ролевых ДП-моделей, используется механизм ограничений, обоснуем следующее утверждение.
Утверждение 1. Пусть О0 —начальное состояние системы Т.(О* ,ОР,О0), в котором функции (ги, ге,гг, г3)0 удовлетворяют условиям предположения 7. Тогда в любом состоянии Ом любой траектории О0 \~ор1 О1 \~ор2 ■ ■ ■ ^~орм Ом, где ор1, ... , орм — правила преобразования состояний и N ^ 0, функции ЦЛN, РЛм и го1евм удовлетворяют
соответствующим ограничениям Constraintu, ConstraintP и Constraints и функции (iu,ie,ir,ís)n удовлетворяют условиям предположения 7.
Доказательство. Докажем утверждение индукцией по длине N траектории функционирования системы.
Пусть N = 0, тогда по предположению 6 в состоянии G0 функции UA0, PA0 и roles0 удовлетворяют соответствующим ограничениям Constraintu, ConstraintP и ConstraintS и по условию функции (iu,ie,ir,is)0 удовлетворяют условиям предположения 7.
Пусть N > 0 и утверждение верно для всех траекторий длины 0 ^ L < N. Пусть G0 \~орi G1 \~ор2 ... \~opN Gn — траектория функционирования системы длины N. По предположению индукции в состоянии Gn-1 функции UAn-1, PAn-1 и rolesN-1 удовлетворяют соответствующим ограничениям Constraintu, ConstraintP и Constraints и функции (iu,ie,ir,is)N-1 удовлетворяют условиям предположения 7.
Рассмотрим правило преобразования состояний opN. Если условия его применения не выполняются в состоянии Gn-1, то по определению правил преобразования состояний справедливо равенство Gn-1 = Gn и по предположению индукции в состоянии Gn функции UAn , PAn и rolesN удовлетворяют соответствующим ограничениям Constraintu, ConstraintP и Constraints и функции (iu,ie,ir,is)N удовлетворяют условиям предположения 7. Пусть условия применения правила преобразования состояний opN выполняются в состоянии Gn-1.
Де-факто правила (за исключением правила de_facto_op(x, op(y,y',...)) не изменяют значения функций UA, PA, roles, (iu,ie,ir,is), множества сущностей, субъект-сессий, текущих ролей субъект-сессий, прав доступа ролей, отношения подчиненности в иерархии на множествах сущностей или субъект-сессий. Таким образом, если opN является де-факто правилом (за исключением правила de_facto_op(x,op(y,y',...)), по предположению индукции в состоянии Gn-1 функции UAn-1, PAn-1 и rolesN-1 удовлетворяют соответствующим ограничениям Constraintu, ConstraintP и Constraints и функции (iu, ie, ir, is)N-1 удовлетворяют условиям предположения 7, то в состоянии Gn функции UAn , PAn и rolesN также удовлетворяют соответствующим ограничениям Constraintu, ConstraintP и Constraints и функции (iu, ie,ir,is)N удовлетворяют условиям предположения 7.
Если opN является де-факто правилом de_facto_op(x, op(y, y',...)), то результаты его применения совпадают с результатами применения де-юре правила op(y,y',...), поэтому далее при обосновании шага индукции будем считать, что opN —де-юре правило.
В рамках РОСЛ ДП-модели не заданы де-юре правила преобразования состояний, изменяющие значение функций UA, iu, ir и множества UE. Следовательно, поскольку в состоянии Gn-1 функция UAn-1 удовлетворяет ограничениям Constraintu и функции (iu, ie, ir, is)N-1 удовлетворяют условиям предположения 7, то в состоянии Gn функция UAn удовлетворяет ограничениям Constraintu и функции (iu, ie, ir, is)N удовлетворяют условиям 1, 4, 6 предположения 7.
Если opN является де-юре правилом вида create _hard_link(x, x' ,y,name, z), delete _hard_link(x, x', y, z), rename_entity(x, x', y, name, z), set_container_attr(x, x', y, ccri, t), access_own(x, x', y), access_read(x, x',y), access_write(x, x', y) или delete _ac-cess(x,x',y,aa), то оно не изменяет значения функций PA и roles. Следовательно, поскольку функции PAn-1 и rolesN-1 соответственно удовлетворяют ограничениям ConstraintP и Constraints в состоянии Gn-1, то функции PAn и rolesN соответственно удовлетворяют им в состоянии Gn .
Если opN является де-юре правилом вида take_roles(x,x', {rj : 1 ^ j ^ k}) или remove _roles(x,x', {rj : 1 ^ j ^ k}), то оно не изменяет значение функции PA. Следовательно, поскольку функция PAn-і удовлетворяет ограничениям Constraintp в состоянии Gn -і, то функция PAn удовлетворяет им в состоянии Gn . При этом соответствие функции rolesN ограничениям Constraints в состоянии Gn следует из условий применения правил.
Если opN является де-юре правилом вида grant_rights(x,x',r, {(yj,arj) : 1 ^ j ^ ^ k}), remove _rights(x,x' ,r, {(yj ,ar.) :1 ^ j ^ k}), create _object(x,x' ,r,y,yi,name, z), create _container (x, x' ,r,y,yi, ccri,t, name, z) или delete _entity(x,x' ,y,z), то оно не изменяет значение функции roles. Следовательно, поскольку функция rolesN-і удовлетворяет ограничениям Constraints в состоянии Gn-і, то функция rolesN удовлетворяет им в состоянии Gn . При этом соответствие функции PAn ограничениям Constraintp в состоянии Gn следует из условий применения правил.
Если opN является де-юре правилом вида create_first_session(x,x',u,r,y,z,zi), create_session(x, x',r,y, z, zi) или delete_session(x,x',z), то из условий применения правил следует, что функции PAn и rolesN удовлетворяют соответственно ограничениям ConstraintP и Constraints в состоянии Gn .
Таким образом, обосновано, что в состоянии Gn функции UAn, PAn и rolesN удовлетворяют соответствующим ограничениям Constraintu, ConstraintP и Constraints.
Если opN является де-юре правилом вида rename_entity(x, x', y, name, z), set_con-tainer _attr(x,x' ,y,ccri,t), access _own(x, x' ,y), access _read(x, x',y), access _write(x, x', y) или delete_access(x, x', y, aa), то оно не изменяет множества сущностей, субъект-сессий, текущих ролей субъект-сессий, прав доступа ролей, отношения подчиненности в иерархии на множествах сущностей или субъект-сессий. Следовательно, по предположению индукции в состоянии Gn функции (iu, ie,ir, is)N удовлетворяют условиям 2,
3, 5, 7 и 8 предположения 7.
Если opN является де-юре правилом вида remove_roles(x, x', {rj : 1 ^ j ^ k}), remove_rights(x, x', {(yj,arj) : 1 ^ j ^ k}), delete_entity(x, x',y, z), delete_hard_-link(x, x', y, z) или delete_session(x, x', z), то оно не добавляет новых элементов во множества сущностей, субъект-сессий, текущих ролей субъект-сессий, прав доступа ролей, не изменяет отношение подчиненности в иерархии на множествах сущностей или субъект-сессий, остающихся в последующем состоянии системы. Следовательно, по предположению индукции в состоянии Gn функции (iu,ie,ir,is)N удовлетворяют условиям 2, 3, 5, 7 и 8 предположения 7.
Если opN является де-юре правилом вида take_roles(x,x', {rj : 1 ^ j ^ k}), то оно не добавляет новые элементы во множества сущностей, субъект-сессий, прав доступа ролей, не изменяет отношение подчиненности в иерархии на множествах сущностей или субъект-сессий в последующем состоянии системы. Значит, по предположению индукции в состоянии Gn функции (iu,ie,ir,is)N удовлетворяют условиям 2, 3, 5 и 8 предположения 7. Выполнение условия 7 предположения 7 следует из предположения индукции и из условий и результатов применения правила.
Если opN является де-юре правилом вида grant_rights(x,x',r, {(yj,arj) : 1 ^ j ^ ^ k}), то оно не добавляет новые элементы во множества сущностей, субъект-сессий, текущих ролей субъект-сессий, не изменяет отношение подчиненности в иерархии на множествах сущностей или субъект-сессий в последующем состоянии системы. Значит, по предположению индукции в состоянии Gn функции (iu,ie,ir,is)N удовлетворяют условиям 2, 3, 5 и 7 предположения 7. Выполнение условия 8 предположения 7 следует из предположения индукции и из условий и результатов применения правила.
Если opN является де-юре правилом вида create _object(x, x' ,r,y,yi, name, z), create_container(x, x', r, y, yi, ccri, t, name, z) или create_hard_link(x, x', y, name, z), то оно не добавляет новые элементы во множества субъект-сессий, текущих ролей субъект-сессий, не изменяет отношение подчиненности в иерархии на множестве субъект-сессий в последующем состоянии системы. Значит, по предположению индукции в состоянии Gn функции (iu,ie,ir,is)N удовлетворяют условиям 3, 5 и 7 предположения 7. Выполнение условий 2 и 8 предположения 7 следует из предположения индукции и из условий и результатов применения правил.
Если opN является де-юре правилом вида create_first_session(x,x',u,r,y,z,zi) или create_session(x, x',r, y, z, zi), то оно не добавляет новые элементы во множества сущностей (не являющихся субъектами) и не изменяет отношение подчиненности в иерархии на множестве сущностей в последующем состоянии системы. Значит, по предположению индукции в состоянии Gn функции (iu,ie,ir,is)N удовлетворяют условию 2 предположения 7. Выполнение условий 3, 5, 7 и 8 предположения 7 следует из предположения индукции и из условий и результатов применения правила.
Таким образом, обосновано, что в состоянии Gn функции (iu,ie,ir,is)N удовлетворяют условиям 1-8 предположения 7. Шаг индукции доказан. ■
5. Монотонные и немонотонные правила преобразования состояний.
Инвариантность ограничений относительно немонотонных правил
По аналогии с существующими ДП-моделями дадим определение.
Определение 1. Монотонное правило преобразования состояний — правило преобразования состояний из множества OP, применение которого не приводит к удалению из состояний:
— ролей из множества текущих ролей субъект-сессий;
— прав доступа ролей к сущностям;
— субъект-сессий, сущностей или «жестких» ссылок на сущности-объекты;
— доступов субъект-сессий к сущностям;
— информационных потоков.
По определению в соответствии с условиями и результатами применения правил преобразования состояний, заданных в табл. 1 и 2, монотонными будут являться следующие правила: take_roles(x,x', {rj : 1 ^ j ^ k}), grant _rights(x, x' ,r, {(yj ,rj) : 1 ^ j ^ k}), create_object(x, x', r, y, yi, name, z), create_container(x, x', r, y, yi, ccri, t, name, z), create _hard_link(x, x', y, name, z), rename_entity(x, x', y, name, z), set_container_attr(x, x', y, ccri,t), create _ first _session(x, x', u, r, y, z, zi), create _session(x, x', r, y, z, zi), access _own(x, x' ,y), access _read(x, x',y), access _write(x, x',y), control(x,y, z), know(x,y), take _access _own(x,y, z), flow_memory_access(x,y,aa), flow _time_ac-cess(x,y), flow(x,y,y', z), find(x,y,z), post(x,y,z), pass(x,y,z) и take_flow(x,y). Немонотонными правилами преобразования состояний будут являться де-юре правила remove _roles(x, x', {rj : 1 ^ j ^ k}), remove _rights(x,x' ,r, {(yj ,rj) : 1 ^ j ^ k}), delete _entity (x, x',y, z), delete _hard_link(x,x' ,y,z), delete _session(x, x', z), delete _-access(x,x',y,aa). Де-факто правило de_facto_op(x, op(y, y',...)) по определению будем считать монотонным или немонотонным в зависимости от монотонности или немонотонности де-юре правила op(y,y',...).
Наличие в РОСЛ ДП-модели механизма ограничений в общем случае может требовать использования монотонных и немонотонных правил при передаче прав доступа ролей или возникновении информационных потоков. Например, пусть в некоторой
системе задано ограничение на значения множеств текущих ролей субъект-сессий, заключающееся в том, что некоторой ролью может одновременно обладать только одна субъект-сессия. Тогда без использования немонотонного правила вида remove_roles одной субъект-сессией может оказаться невозможным получение данной роли другой субъект-сессией.
Заметим, что в условиях применения правил преобразования состояний, приведенных в табл. 1 и 2, за исключением, возможно, ограничений из множеств ConstraintP и Constraints, не требуется проверка отсутствия каких-либо элементов (например, сущностей, ролей, прав доступа ролей, информационных потоков), задающих исходное состояние G. По предположению 6 на траекториях системы не изменяются значения функций, задающих уровни целостности сущностей или субъект-сессий, существовавших в предшествующих состояниях системы. Таким образом, в рамках РОСЛ ДП-модели только ограничения обладают свойством, обуславливающим в некоторых случаях необходимость применения немонотонных правил для выполнения в дальнейшем условий применения других правил преобразования состояний. Значит, поиск способов обоснования возможности использования только монотонных правил преобразования состояний при анализе условий передачи прав доступа или возникновения информационных потоков целесообразно осуществлять не в общем случае, а для некоторых заданных для конкретных систем множеств ограничений. Дадим определение и обоснуем утверждение.
Определение 2. Ограничение инвариантно относительно немонотонных правил преобразования состояний в системе T,(G*, OP), если при условии, что в системе задано только данное ограничение, для любых состояния системы G0, немонотонного правила преобразования состояний op1 и правил преобразования состояний op2, ..., opN, где N > 1, справедливо следующее: если G0 \~opi G1 hop2 ... \~opN _i GN-1, G0 \~op2 G'2 \~op3 ... \~opN-i G'n- 1 и в состоянии Gn-1 выполнены ограничения, заданные в условиях применения правила opN, то эти ограничения выполнены в состоянии G'n_ 1. Ограничения, заданные в системе T,(G*, OP), по определению инвариантны относительно немонотонных правил преобразования состояний, когда каждое из ограничений в отдельности инвариантно относительно этих правил.
Так как в правилах преобразования состояний, заданных в рамках РОСЛ ДП-модели, не используются ограничения на значения множеств авторизованных ролей учетных записей пользователей, то по определению 2 в любой системе все ограничения из множества Constraintu инвариантны относительно немонотонных правил преобразования состояний.
Утверждение 2. Пусть G0 —начальное состояние системы T.(G*,OP,G0), в котором все ограничения инвариантны относительно немонотонных правил преобразования состояний, и функции (iu,ie,ir,is)0 удовлетворяют условиям предположения 7. Пусть также существуют состояния системы G1, ..., Gn = (PAn,user'N,rolesN, An,Fn,HEn) и правила преобразования состояний op1, ..., opN, такие, что
G0 \~opi G1 \~op2 ... \~opN Gn, где N ^ 0. Тогда существуют состояния G1, ..., G'M = (PA'M,user'M,roles'M, A'M, F'm, H'Em), где M ^ 0, и монотонные правила преобразования состояний op1, ... , op'M, такие, что G0 \~op^ G[ \~op>2 ... \~op-M G'M и выполняются следующие условия:
1. Верно включение SN С S'M и для каждой субъект-сессии s G SN выполняются условия userN(s) = user'M(s), rolesN(s) С roles'M(s), de_facto_ownN(s) С С de_facto_own'M (s).
2. Верно включение En С Е'м, для каждой сущности e E En \ Sn, не являющейся субъектом, выполняется условие HEn(e) С H'Em(e), для любых сущностей e,e' E En если в состоянии Gn выполняется условие e < e', то данное условие выполняется в состоянии G'm .
3. Для каждой роли r E R выполняется условие PAN (r) С PAM (r).
4. Верно включение AN С A'M.
5. Верно включение FN С F'M.
6. Функции (iu,ie,ir, is)M удовлетворяют условиям предположения 7.
Доказательство. Пусть существуют состояния Go, Gi, ..., Gn системы E(G*, OP, Go) и правила преобразования состояний opi, ..., opN, такие, что Go \~opi Gi \~ор2 ... \~opN Gn , где N ^ 0. Докажем утверждение индукцией по длине N последовательности состояний.
Пусть N = 0. Тогда положим M = 0, G'o = Go, и для состояний Go и G'o условия 1-6 утверждения выполнены.
Пусть N > 0 и условия утверждения выполнены для всех последовательностей состояний длины 0 ^ L < N. Докажем, что условия 1-5 утверждения выполнены для последовательностей состояний длины N.
По предположению индукции для последовательности состояний Go, Gi, ... , Gn-i существует последовательность состояний Go, Gi, ... , G'k = (PA'K,user'K,roles'K,A!K, F'k, H'Ek), где K ^ 0, и для состояний Gn-i и G'k выполнены условия 1-5 утверждения.
Рассмотрим правило преобразования состояний opN. Если условия его применения не выполняются в состоянии Gn-i, то справедливо равенство Gn-i = Gn. Положим M = K, и для состояний Gn и GM выполнены условия 1-5 утверждения. Пусть условия применения правила opN выполняются в состоянии Gn-i, тогда возможны два, случая.
Первый случай: правило преобразования состояний opN является немонотонным.
Если в opN (x,...) субъект-сессия x принадлежит LFs П Sn-i, то положим M = K, и условия 1-5 утверждения выполняются для состояний Gn и G'k .
Пусть x E (NS U NFS) П Sn-i.
Пусть opN = remove_roles(x, x', {rj : 1 ^ j ^ l}). Тогда в результате применения правила возникают информационные потоки по времени из множества STime = = {(x,s,writet) : s E (NS U NFS) П Sn-i, x = s и x E de_facto_ownN^(s)}. Так как для состояний Gn-i и G'k выполнены условия 1-5 утверждения, то для s E Sn-i С S'k справедливо de_facto_ownN-i(s) С de_facto_own'K(s). Положим M = K + ISTimel и последовательно для каждой субъект-сессии si E (NS U NFS) П Sn-i, такой, что x = si и x E de_facto_ownN-i(si), положим opi = flow_time_access(si,x), где K < i ^ M. Пусть состояние G'm получено из состояния G'k в результате применения последовательности правил op'K+i, ... , op'M: G'k \~op'K+1 ... \~op'M G'm. Таким образом, для состояний Gn и GM выполнены условия 1-5 утверждения.
Пусть opN = remove_rights(x,x',r, {(yj,rj) : 1 ^ j ^ k}). Тогда в результате применения правила возникают информационные потоки по времени из множества STime = {(x, s,writet) : s E (NS U NFS) П Sn-i, x = s, r E de_facto_rolesN-i(s) и существует j, такое, что 1 ^ j ^ k и (yj,aa) E de_facto_accessesN^(s), где aa E Ra}. Положим Z = ISTimel. Так как для состояний Gn-i и G'k выполнены условия 1-5 утверждения, то выполняются условия (x,yj ,owna) E A'k и для каждого si, к которому создается информационный поток из множества STime, выполняются условия (yj,aa) E de_facto_accessesN-l(si) С de_facto_accesses'K(si), где 1 ^ i ^ Z. Положим op'K+i = flow(x,yj,yj,si), где 1 ^ i ^ Z, и M = K + Z. Пусть состояние G'm
получено из состояния G'K в результате применения последовательности правил op'K+\, ... , op'M: G'K \~ор'к+1 • • • ^ор'м G'M. Таким образом, для состояний GN и G'M выполнены условия 1-5 утверждения.
Пусть opN = delete_entity(x,x',y, z). Тогда в результате применения правила возникают информационные потоки по времени, в том числе из множества STime = = {(x, s, writet) : s Є (NS U NFS) П SN-1, x = s и (y, aa) Є de _f acto _accessesN^(s), где aa Є Ra}. Положим Z = ISTimel. Так как для состояний Gn-1 и G'k выполнены условия 1-5 утверждения, то выполняются условия (x, z,writea) Є A'k , и для каждого si, к которому создается информационный поток из множества STime, выполняются условия (y,aa) Є de_facto_accessesN-1(si) С de_facto_accesses'K(si), где 1 ^ i ^ Z. Положим op'K+i = flow(x,y,y, si), где 1 ^ i ^ Z, op'K+Z+1 = flow_time_access(x,y), и M = K + Z +1. Пусть состояние GM получено из состояния GK в результате применения последовательности правил op'K+1, ..., op'M : G’K ^~op^1 ... ^~op'M GM. Таким образом, для состояний Gn и GM выполнены условия 1-5 утверждения.
Пусть opN = delete_hard_link(x,x',y, z). Так как для состояний GN-1 и G'K выполнены условия 1-5 утверждения, то выполняются условия (x, z,writea) Є AK, ie(y) ^ ir(r) ^ is(w), ie(y) ^ ie(z) ^ is(w), и если ie(z) = i_high, то (x', i_entity, writea) Є AK. Следовательно, в состоянии GK выполнены условия применения правила create_hard_link(x,x',y,name, z), где name Є NAME\ {«»} — некоторое допустимое имя сущности. Тогда положим M = K + 1, opM = create_hard_-link(x,x',y,name,z), и пусть состояние G'M получено из состояния G'K применением к нему правила opM : GK ]^op^ GM. Таким образом, для состояний Gn и GM выполнены условия 1-5 утверждения.
Пусть opN = delete_session(x,x', z). Тогда в результате применения правила возникают информационные потоки по времени, в том числе из множества STime = = {(x, s,writet) : s Є (NS U NFS) П SN-1, x = s и z Є de_facto_ownN-1(s)}. Положим Z = ISTimel. Так как для состояний Gn-1 и GK выполнены условия 1-5 утверждения, то выполняются условия (x, z,writea) Є A'k , и для каждого si, к которому создается информационный поток из множества STime, выполняются условия z Є de_facto_ownN-1(si) С de_facto_own'K(si), где 1 ^ i ^ Z. Положим op'K+i = flow(x, z, z, si), где 1 ^ i ^ Z, op'K+Z+1 = flow_time_access(x, z) и M = K + Z +1. Пусть состояние GM получено из состояния G'k в результате применения последовательности правил op'K+1, ..., op'M : G'K ^~op^1 ... ^~op>M G'm - Таким образом, для состояний Gn и GM выполнены условия 1-5 утверждения.
Пусть opN = delete_access(x,x',y,aa). Так как для состояний GN-1 и G'K выполнены условия 1-5 утверждения, то выполняется условие (x,y,aa) Є AK. Положим M = K + 1, op'M = flow_time_access(x,y), и пусть состояние G'M получено из состояния G'k применением к нему правила opM : G'k ^~op'м GM. Таким образом, для состояний Gn и GM выполнены условия 1-5 утверждения.
Пусть opN = de_facto_op(x, op(y, y',...)), где op(y, y',...) — немонотонное правило преобразования состояний. Так как для состояний Gn-1 и G'k выполнены условия 1-5 утверждения, то de_facto_ownN-1(x) С de_facto_own'K(x) и в состоянии G'K выполняются условия применения правила op(y,y',...), являющегося одним из шести рассмотренных немонотонных правил. Следовательно, повторяя рассуждения для этих правил, получаем состояние GM, такое, что для состояний Gn и GM выполнены условия 1-5 утверждения.
Второй случай: правило преобразования состояний opN является монотонным. Положим M = K + 1, opM = opN, таким образом, монотонные правила исходной после-
довательности op1, ..., opN без изменений добавляются в последовательность op1, ... , op'M. Так как для состояний Gn-1 и G'K выполнены условия 1-5 утверждения и по предположению 6 на траекториях системы не изменяются значения функций, задающих уровни целостности сущностей или субъект-сессий, существовавших в предшествующих состояниях системы, то в состоянии G'k выполняются все условия применения правила opN, за исключением, возможно, ограничений, заданных в opN. Данные ограничения выполнены в состоянии Gn-1, предположим, что они не выполнены в состоянии GK.
Если N = 1, то G'k = Gn-i = G0, противоречие. Следовательно, выполняется неравенство N > 1. Будем считать, что из последовательности opi, ... , opN-1 удалены все правила, условия применения которых не выполняются. Если последовательность op1, ... , opN-i состоит только из монотонных правил, то справедливо K = N — 1, opi = opi, где 1 ^ i ^ N — 1, и G'k = Gn-1. Противоречие. Следовательно, в последовательности opi, ... , opN-i есть немонотонные правила. По определению 2, данные немонотонные правила, начиная с конца последовательности op1, ..., opN-1, могут быть удалены из нее, и на их место могут быть вставлены соответствующие монотонные правила вида create _hard _link(x, x', y, name, z), flow _time_access(x,y), flow(x,y,y', z), использованные в доказательстве для первого случая. Эти правила добавляют все информационные потоки, которые создавались соответствующими немонотонными правилами, и не влияют на выполнение ограничений (так как не изменяют значения функций PA и roles). В результате будет получена последовательность монотонных правил op1, ... , opK, и по определению 2 в состоянии G'k должно выполняться ограничение, заданное в правиле opN. Противоречие. Значит, данное ограничение выполнено в состоянии G'k.
Таким образом, пусть состояние G'm получено из состояния G'k с использованием монотонного правила opN: G'k \~oPn G'm. В соответствии с заданными в табл. 1 и 2 результатами применения правил преобразования состояний для состояний Gn и GM выполнены условия 1-5 утверждения.
Выполнение условия 6 утверждения во всех рассмотренных случаях следует из утверждения 1.
Следовательно, условия 1-6 утверждения выполнены для последовательностей состояний длины N, и шаг индукции доказан. ■
Таким образом, в рамках РОСЛ ДП-модели возможно задание ограничений, позволяющих при дальнейшем анализе условий передачи прав доступа ролей, реализации информационных потоков по памяти или по времени использовать только монотонные правила преобразования состояний.
Утверждение 3. Пусть G0 —начальное состояние системы T.(G*,OP,G0), в которой все ограничения инвариантны относительно немонотонных правил преобразования состояний, и op Є OP — правило преобразования состояний. Если в состоянии G0 выполнены ограничения, заданные в условиях применения правила op, то эти ограничения выполнены в состоянии Gn любой траектории системы G0 \~opi G1 \~op2 ... ^~opN Gn , где op1, op2, ... , opN — монотонные правила преобразования состояний и N ^ 1.
Доказательство. Предположим противное. Пусть существуют монотонные правила преобразования состояний op1, op2, ... , opN, где N ^ 1, такие, что G0 \~opi G1 \~op2 ... \~oPN Gn — траектория системы, и в состоянии Gn не выполнены ограничения, заданные в условиях применения правила op. Выберем N минимальной длины, тогда в состоянии Gn-1 выполнены ограничения, заданные в условиях применения правила op. Значит, без ограничения общности можно считать, что существует монотонное
правило преобразования состояний op1, такое, что G0 \~opi G1, в состоянии G1 не выполнены ограничения, заданные в условиях применения правила op, при этом условия применения правила op1 выполнены в состоянии G0. Кроме того, по предположению 6 в состоянии G0 функции UA0, PA0 и roles0 удовлетворяют соответствующим ограничениям Constraintu, Constraintp и Constraints.
Правило op не может являться правилом вида create_hard_link(x,x',y,name, z), rename_entity(x, x', y, name, z), set_container_attr(x, x', y, ccri, t), access_own(x, x',y), access_read(x, x',y), access_write(x,x',y), control(x, y, z), know(x,y), take_access_-own(x,y,z), flow_memory_access(x,y,aa), flow_time_access(x,y), flow(x,y,y',z), find(x,y,z), post(x,y,z), pass(x,y,z) и take_flow(x,y), а также правилом вида de_f acto_op(x, op[(y, y',...)), где op[(y, y',...) — де-юре правило одного из перечисленных видов. Эти правила не изменяют значения функций UA, PA и roles, поэтому после их применения выполнявшиеся в состоянии G0 ограничения, заданные в условиях применения правила op, должны выполняться в состоянии G1. Следовательно, возможны семь случаев.
Первый случай: op1 = take_roles(x,x', {rj : 1 ^ j ^ k}). Положим op2 = remove _roles(x,x', {rj : 1 ^ j ^ k}).
Второй случай: op1 = grant_rights(x,x',r, {(yj,rj) : 1 ^ j ^ k}). Положим op2 = = remove _rights(x, x', r, {(yj ,rj) : 1 ^ j ^ k}).
Третий и четвертый случаи: op1 = create _object(x,x' ,r, y, yi, name, z) или op1 = = create _container (x, x',r,y,yi, ccri, t, name, z). Положим op2 = delete _entity(x, x',y,z).
Пятый и шестой случаи: op1 = create_first_session(x,x',u,r,y, z, zi) или op1 = = create_session(x, x',r,y, z, zi). Положим op2 = delete_session(x, x', z).
Седьмой случай: op1 = de_f acto_op(x, op'^y, y',...)), где op'^y, y',...) — де-юре правило одного из рассмотренных шести видов. Положим op2 = de_facto_op(x,op'2(y, y',...)), где op'2(y, y',...)— соответствующее для каждого из рассмотренных шести случаев немонотонное де-юре правило.
Рассмотрим траекторию G0 \~opi G1 \~op2 G2. Во всех семи случаях выполнены условия применения немонотонного правила op2, в том числе: так как UA0 = UA2, PA0 = PA2, roles0 = roles2, то выполнены ограничения, заданные в условиях применения правила op2. Следовательно, в состоянии G2 выполнены ограничения, заданные в условиях применения правила op. Следовательно, по определению 2 эти ограничения выполнены в состоянии G1. Противоречие.
Утверждение доказано. ■
Таким образом, если в системе заданы ограничения, инвариантные относительно немонотонных правил преобразования состояний, и в ее начальном состоянии выполнены ограничения, заданные в условиях применения некоторого монотонного правила, то эти ограничения будут выполнены в любом состоянии на любой траектории системы, полученной из начального состояния в результате применения монотонных правил преобразования состояний.
6. Способ задания индивидуальных ролей учетных записей пользователей
При реализации в существующих ОС (использующих, как правило, дискреционное управление доступом) ролевого управления доступом, возможно, будет необходимо задание для каждой учетной записи пользователя индивидуальных прав доступа к сущностям. Например, эта необходимость возникает в следующих случаях:
— когда имеются сущности-файлы, принадлежащие только субъект-сессиям, функционирующим от имени учетной записи некоторого пользователя;
— когда субъект-сессия, создавая новую субъект-сессию, должна получить к ней право доступа владения.
Для обеспечения такой возможности в РОСЛ ДП-модели целесообразно для каждой учетной записи пользователя включить во множество ее авторизованных ролей принадлежащие только ей пары (для каждого уровня целостности, не превосходящего уровень целостности учетной записи пользователя) ролей: индивидуальную роль и индивидуальную административную роль, задав соответствующие параметры ограничений. Таким образом, сделаем предположение, дополняющее предположение 1.
Предположение 12. Для каждой учетной записи пользователя u G U, каждого уровня целостности i ^ iu(u) существуют роль u_role_i G R и административная роль u_admin_role_i G AR, которые имеют следующие свойства:
— обладают уровнем целостности i;
— входят во множества авторизованных ролей и авторизованных административных ролей соответственно только учетной записи пользователя u;
— множества параметрически ассоциированных с ними сущностей совпадают с множеством сущностей, параметрически ассоциированных с учетной записью пользователя u.
С использованием административной роли u_admin_role_i разрешено включать или удалять права доступа во множество прав доступа роли u_role_i. При этом не накладываются следующие ограничения:
— из множества Constraintu, требующие наличия во множестве авторизованных ролей учетной записи пользователя u ролей u_role_i и u_admin_role_i;
— из множества ConstraintP, разрешающие получение любой ролью u_role_i права доступа владения к сущности при ее создании субъект-сессией, функционирующей от имени учетной записи пользователя u, или получение любой ролью u_role_i любого права доступа к сущности при наличии у роли u_role_i права доступа владения к этой сущности;
— из множества Constraints, разрешающие обладание субъект-сессиями, функционирующими от имени учетной записи пользователя u, текущими ролями u_role_i и u_admin_role_i.
Таким образом, для каждой учетной записи пользователя u U выполняются условия:
— u_role_i G UA(u), u_admin_role_i G AUA(u);
— ir (u_role_i) = ir (u_admin_role_i) = i;
— )u_role_i[=]u_admm_role_i[=]u[;
— u_role_i G can_manage_rights(u_admin_role_i).
В результате предположение 12 позволяет задать функции авторизованных ролей учетных записей пользователей, текущих ролей субъект-сессий и прав доступа ролей с учетом одной из особенностей реализации управления доступом в ОС.
Заключение
Основным направлением развития РОСЛ ДП-модели стала ее поэтапная адаптация к условиям функционирования реальных ОС семейства AltLinux. При этом в первую очередь элементы модели, правила преобразования состояний были переопределены с целью обеспечения четкого разделения де-юре и де-факто условий функционирования системы. Кроме того, включение в модель механизма ограничений потребова-
ло описания особого их вида — ограничений, инвариантных относительно немонотонных правил преобразования состояний, позволяющих при анализе условий передачи прав доступа ролей, получения доступов и возникновения информационных потоков по памяти или по времени использовать только монотонные правила. Таким образом, были созданы предпосылки для формулирования и обоснования в рамках РОСЛ ДП-модели условий нарушения безопасности системы и практической проверки их корректности на макете реальной ОС.
ЛИТЕРАТУРА
1. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками. Учеб. пособие для вузов. М.: Горячая линия-Телеком, 2011. 320 с.
2. Девянин П. Н., Захаренков П. С. Способ реализации информационного потока по времени в операционных системах с мандатным управлением доступом через clipboard // Методы и технические средства обеспечения безопасности информации: материалы Юбилейной 20-й науч.-техн. конф. 27 июня - 01 июля 2011г. СПб.: Изд-во Политехн. ун-та, 2011. С. 76-77.
3. Колегов Д. Н. ДП-модель компьютерной системы с функционально и параметрически ассоциированными с субъектами сущностями // Вестник Сибирского государственного аэрокосмического университета им. акад. М. Ф. Решетнева. 2009. Вып. 1(22). Ч. 1. С. 49-54.
4. Девянин П. Н. Правила преобразования состояний базовой ролевой ДП-модели управления доступом и информационными потоками в операционных системах // Прикладная дискретная математика. 2011. №1(11). С. 78-95.
5. Девянин П. Н. Моделирование ролевого управления доступом в операционных системах семейства Linux // Проблемы информационной безопасности. Компьютерные системы. 2011. №1. С. 24-43.
