Администрирование системы в рамках мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в оС семейства Linux Текст научной статьи по специальности «Компьютерные и информационные науки»

2013 Математические основы компьютерной безопасности №4(22)

МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ

УДК 004.94

АДМИНИСТРИРОВАНИЕ СИСТЕМЫ В РАМКАХ МАНДАТНОЙ СУЩНОСТНО-РОЛЕВОЙ ДП-МОДЕЛИ УПРАВЛЕНИЯ ДОСТУПОМ И ИНФОРМАЦИОННЫМИ ПОТОКАМИ В ОС СЕМЕЙСТВА LINUX

П. Н. Девянин

Учебно-методическое объединение по образованию в области информационной

безопасности, г. Москва, Россия

E-mail: peter_devyanin@hotmail.com

Рассматриваются де-юре правила администрирования параметров механизма управления доступом системы, заданной в рамках мандатной сущностно-ролевой ДП-модели и ориентированной на реализацию в отечественной защищённой операционной системе Astra Linux Special Edition. Данные правила позволяют администрировать учётные записи пользователей, права доступа, множество ролей, иерархию ролей и административных ролей, уровни конфиденциальности и целостности сущностей, субъект-сессий, ролей и административных ролей.

Ключевые слова: мандатная сущностно-ролевая ДП-модель, операционная система Linux.

Введение

При разработке формальных моделей безопасности управления доступом и информационными потоками часто правилам преобразования состояний системы, задающим порядок её администрирования, уделяется второстепенное внимание. Это объясняется ориентированностью большинства таких моделей только на теоретический анализ условий безопасности системы, при осуществлении которого, как правило, предполагается, что все действия по администрированию системы выполнены её доверенными субъект-сессиями (субъектами) и функционирование системы осуществляется только в результате реализации правил, инициированных недоверенными субъект-сессиями. Однако в разрабатываемой в настоящее время автором мандатной сущностно-ролевой ДП-модели операционных систем (ОС) семейства Linux (МРОСЛ ДП-модели) [1-3] значительное внимание уделяется её адаптации к условиям функционирования механизма управления доступом отечественной защищённой операционной системы Astra Linux Special Edition [4]. Для этого в МРОСЛ ДП-модели детально задаётся порядок реализации её элементов непосредственно в коде программного обеспечения защищённой ОС. Следовательно, целесообразно, кроме типовых правил управления доступом (получения доступа к сущностям, создания, удаления, переименования сущностей или «жёстких» ссылок на них, создания или удаления субъект-сессий), чётко определить правила, позволяющие администрировать учётные записи пользователей, административные права доступа, множества ролей, иерархию ролей и административных ролей, уровни конфиденциальности и целостности сущностей, субъект-сессий, ролей и административных ролей.

1. Основные элементы МРОСЛ ДП-модели

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

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

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

— E = O U C — множество сущностей, где O — множество объектов; C — множество контейнеров; O П C = 0;

— S — множество субъект-сессий учётных записей пользователей, где S П E = 0;

— entity_name : C х E ^ NAMES — функция имён сущностей в составе сущностей-контейнеров, где NAMES — некоторое множество допустимых имён сущностей, включающее элемент «»—пустая строка. При этом, по определению, если e Е HE(c), то entity_name(c, e) = «», иначе entity_name(c, e) = «».

Определение 1. Иерархией сущностей называется заданное на множестве сущностей E отношение частичного порядка ^, удовлетворяющее условию: если для сущности-контейнера e Е C существуют сущности e1,e2 Е C, такие, что e ^ e2, e ^ ei, то e1 ^ e2 или e2 ^ e1. В случае, когда для двух сущностей e1,e2 Е E выполняются условия e1 ^ e2 и e1 = e2, будем говорить, что сущность e1 содержится в сущности-контейнере e2, и будем использовать обозначение e1 < e2. Определим He : E ^ 2E — функцию иерархии сущностей (сопоставляющую каждой сущности e Е E множество сущностей He(e) С E, непосредственно в ней содержащихся), удовлетворяющую следующим условиям:

— если e Е He (c), то e < с, при этом если e Е C, то не существует сущности-контейнера d Е C, такой, что e < d < c;

— для любых сущностей e1,e2 Е E, e1 = e2, выполняется равенство HE(e1) П HE(e2) П

nC = 0;

— если о Е O, то справедливо равенство HE(o) = 0.

Определение 2. Иерархией субъект-сессий называется заданное на множестве сущностей S отношение частичного порядка ^, удовлетворяющее условию: если для субъект-сессии s Е S существуют субъект-сессии S1, s2 Е S, такие, что s ^ s2, s ^ s1, то s1 ^ s2 или s2 ^ s1. В случае, когда для двух субъект-сессий s1 ,s2 Е S выполняются условия s1 ^ s2 и s1 = s2, будем говорить, что субъект-сессия s1 является потомком s2, и будем использовать обозначение s1 < s2. Определим Hs : S ^ 2S — функцию иерархии субъект-сессий (сопоставляющую каждой субъект-сессии s Е S множество субъект-сессий Hs(s) С S, непосредственно в ней содержащихся), удовлетворяющую условиям:

— если s1 Е HS(s2), то s1 < s2 и не существует субъект-сессии s Е S, такой, что s1 < s < s2;

— для любых субъект-сессий s;i_, s2 Е S, s1 = s2, выполняется равенство HS(s1) П nHs (s2) = 0.

В рамках МРОСЛ ДП-модели учтено наличие механизма создания «жёстких» ссылок (hard link) в файловой системе ОС семейства Linux, обеспечивающего возможность

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

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

— U — множество учётных записей пользователей;

— Lu — множество учётных записей доверенных пользователей;

— Nu — множество учётных записей недоверенных пользователей, при этом по определению справедливы равенства Lu U Nu = U, Lu П Nu = 0;

— Ls — множество доверенных субъект-сессий;

— Ns — множество недоверенных субъект-сессий, при этом по определению справедливы равенства Ls U NS = S, Ls П Ns = 0;

— user : S ^ U — функция принадлежности субъект-сессии учётной записи пользователя, задающая для каждой субъект-сессии учётную запись пользователя, от имени которой она активизирована;

— R — множество ролей;

— AR — множество административных ролей, при этом по определению AR П R = 0 (административные роли — особый вид ролей, предназначенный для изменения множеств прав доступа ролей, авторизации на роли, а также выполнения функций по администрированию системы, например, управления мандатными уровнями конфиденциальности сущностей и субъект-сессий);

— Rr = {readr ,writer, executer, ownr} —множество видов прав доступа;

— Ra = {reada, writea} —множество видов доступа;

— Rf = {writem,writet} —множество видов информационных потоков (по памяти и по времени).

Поскольку традиционно в ОС семейства Linux рассматриваются три вида прав доступа к сущностям: на чтение, на запись и на выполнение (или на использование контейнера-каталога), а также при управлении доступом к сущностям и субъект-сессиям учитывается наличие у каждой из них уникального владельца, имеющего право передавать права доступа к ним другим учётным записям пользователей, то в рамках МРОСЛ ДП-модели используются виды прав доступа readr, writer, executer, ownr и виды доступов reada и writea. В отличие от предыдущих ДП-моделей, доступ владения owna исключён из рассмотрения, как не имеющий явной реализации в реальных ОС.

Далее введём следующие обозначения:

— P С (E х Rr) U (S х {ownr}) —множество прав доступа к сущностям и субъект-сессиям;

— AP С (R U AR) х Rr —множество административных прав доступа к ролям или административным ролям;

— A С S х E х Ra — множество доступов субъект-сессий к сущностям;

— AA С S х (R U AR) х Ra — множество доступов субъект-сессий к ролям или административным ролям;

— F С (E U SU RU AR) х (E U SU RU AR) х Rf —множество информационных потоков;

— PA : R U AR ^ 2Р — функция прав доступа к сущностям ролей и административных ролей, при этом для каждого права доступа p Е P существует роль r Е RU AR, такая, что выполняется условие p Е PA(r);

— APA : AR ^ 2AP — функция административных прав доступа к ролям и административным ролям административных ролей, при этом для каждого административного права доступа ap Е AP существует административная роль ar Е AR, такая, что выполняется условие ap Е APA(ar);

— shared_container : C U R U AR ^ {true, false} — функция разделяемых

контейнеров, такая, что сущность-контейнер, роль или административная роль c Е C U R U AR является разделяемой, когда shared_container(c) = true, в противном случае shared_container(c) = false;

— V : E U R U AR ^ {(a1,..., an) : ai Е {0,1}, 1 ^ i ^ n,n ^ 1} U {0} — функция значений сущностей, ролей и административных ролей (как аналогов сущностей-контейнеров), задающая возможность для каждой из них принимать значение любой (в том числе пустой) конечной последовательности бит;

— (LC, ^) — решётка многоуровневой безопасности уровней конфиденциальности (декартово произведение линейной шкалы уровней конфиденциальности данных и множества всех подмножеств конечного множества неиерархических категорий данных);

— (fu, fe, fr, fs) Е FC — четвёрка функций уровней конфиденциальности, при этом:

— fu : U ^ LC — функция, задающая для каждой учётной записи пользователя её уровень доступа — максимальный разрешённый уровень доступа субъект-сессий, функционирующих от её имени;

— fe : E ^ LC — функция, задающая уровень конфиденциальности для каждой сущности;

— fr : R U AR ^ LC — функция, задающая для каждой роли или административной роли её уровень конфиденциальности;

— fs : S ^ LC — функция, задающая для каждой субъект-сессии её текущий уровень доступа;

— FC — множество всех четвёрок функций заданного вида;

— CCR : E U R U AR ^ {true, false} — функция, задающая способ доступа к сущностям внутри контейнеров или ролям в иерархии ролей (с учётом их мандатных уровней конфиденциальности). Если сущность e Е C является контейнером и доступ к сущностям, содержащимся внутри контейнера e, разрешён без учёта уровня конфиденциальности контейнера e, то по определению выполняется равенство CCR(e) = false, в противном случае CCR(e) = true. При этом по определению для каждой сущности-объекта o Е O выполняется равенство CCR(o) = true, для ролей или административных ролей r Е R U AR всегда выполняется равенство CCR(r) = false;

— (LI, ^) —линейная шкала двух уровней целостности данных, где LI = {i_low, i_high}, i_low < i_high;

— (iu,ie,ir,is) Е I — четвёрка функций уровней целостности, при этом:

— iu : U ^ LI — функция, задающая для каждой учётной записи пользователя её уровень целостности — максимальный разрешённый уровень целостности субъект-сессий, функционирующих от её имени;

— ie : E ^ LI — функция, задающая уровень целостности для каждой сущности;

— ir : RUAR ^ LI — функция, задающая для каждой роли или административной роли её уровень целостности;

— is : S ^ LI — функция, задающая для каждой субъект-сессии её текущий уровень целостности;

— I — множество всех четвёрок функций заданного вида;

— CCRI : EURUAR ^ {true, false} — функция, задающая способ доступа к сущностям внутри контейнеров, ролям или административным ролям в иерархии ролей (с учётом их мандатных уровней целостности). Если сущность e Е C является контейнером и доступ к сущностям, содержащимся внутри контейнера e, разрешён без учёта уровня целостности контейнера e, то по определению выполняется равенство CCRI(e) = false, в противном случае CCRI(e) = true. При этом по определению для каждой сущности-объекта o Е O выполняется равенство CCRI(o) = true, для ролей или административных ролей r Е R U AR всегда выполняется равенство CCRI (r) = false.

Определение 3. Иерархией ролей называется заданное на множестве ролей R отношение частичного порядка ^. При этом по определению справедливо: для административной роли ar Е AR, если роли r,r' Е R таковы, что (r, readr) Е APA(ar) и r' ^ r, то выполняется условие (r',readr) Е APA(ar). Иерархией административных ролей называется заданное на множестве ролей AR отношение частичного порядка ^. При этом по определению справедливо: для административной роли ar Е AR, если административные роли r, r' Е AR таковы, что (r, readr) Е APA(ar) и r' ^ r, то выполняется условие (r', readr) Е APA(ar). По определению роли и административные роли несравнимы друг с другом, т. е. их иерархии всегда независимы. В случае, когда для двух ролей или административных ролей r,r' Е R U AR выполняются условия r ^ r' и r = r', будем использовать обозначение r < r'. Определим HR : R U AR ^ 2R U 2AR — функцию иерархии ролей и административных ролей, сопоставляющую каждой роли r Е R U AR множество ролей HR(r) С R U AR и удовлетворяющую условию: если r' Е HR(r), то r' < r и не существует роли r'' Е R U AR, такой, что r' < r'', r'' < r.

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

— role_name : (R U AR) х (R U AR) ^ NAMES — функция имён ролей и административных ролей в составе роли или административной роли (как контейнера). При этом по определению если r Е HR(r'), то role_name(r',r) = «», иначе role_name(r' ,r) = «».

Предположение 2. Для каждой учётной записи пользователя u Е U в зависимости от её уровня целостности задаются следующие индивидуальные административные роли, на которые авторизована только эта учётная запись:

— u_admin_i_low Е AR, ir(u_admin_i_low) = i_low, fr(u_admin_i_low) = ®LC, когда iu(u) = i_low (®LC — минимальный элемент решётки уровней конфиденциальности LC);

— u_admin_i_low, u_admin_i_high Е AR, ir(u_admin_i_low) = i_low, ir(u_ad-min_i_high) = i_high, fr(u_admin_i_low) = fr(u_admin_i_high) = ®LC, u_admin_i_low < u_admin_i_high, когда iu(u) = i_high.

Множество других ролей учётной записи пользователя u задается с использованием административных прав доступа соответственно административной роли u_admin_i_low или административных ролей u_admin_i_low, u_admin_i_high, определяемых функцией APA. Иерархия индивидуальных административных ролей изменяется только при создании, удалении и изменении уровней доступа или целостности соответствующих учётных записей пользователей. На траекториях функционирования системы у этих административных ролей не изменяются имена, уровни конфиденциальности или целостности.

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

В моделях семейства RBAC и других ролевых ДП-моделях предполагалось, что функция авторизованных ролей учётных записей пользователей UA обладает свойством «наследования» подчинённых ролей, т. е. выполняется следующее условие: для учётной записи пользователя u Е U, если роли r,r' Е R таковы, что r Е UA(u) и r' ^ r, то выполняется условие r' Е UA(u). В рамках МРОСЛ ДП-модели с учётом предположения 2 это обеспечивается «наследованием» административной ролью права доступа readr от данной роли ко всем подчинённым ей ролям в иерархии. При этом права доступа writer и ownr таким свойством не обладают, что может позволить гибко задавать «диапазоны» администрируемых ролей по аналогии с моделью ролевого администрирования ARBAC [1]. При реализации иерархий ролей в реальной защищённой ОС по аналогии с файловой системой можно использовать виртуальную структуру сущностей-ролей, отличающуюся от структур для файлов наличием «жёстких» ссылок не только на роли-«объекты» (роли, которым в иерархии не подчинена ни одна другая роль), но и на роли-«контейнеры» (роли, которым в иерархии подчинена хотя бы одна роль).

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

— execute_container : S х E ^ {true, false} — функция доступа субъект-сессии к сущностям в контейнерах, такая, что по определению для субъект-сессии s Е S и сущности e Е E справедливо равенство execute_container(s,e) = true тогда и только тогда, когда существует последовательность сущностей e1,... ,en Е E, где n ^ 1, e = en, удовлетворяющих следующим условиям:

— не существует сущности-контейнера eo Е E, такой, что e1 Е He(eo);

— ei Е He (ei-1), где 1 < i ^ n;

— существует ri Е R U AR, такая, что (s,ri,reada) Е AA и (ei, executer) Е PA(ri), [fe(ei) ^ fs(s) или CCR(ei) = false] и [ie(e,i) ^ is(s) или CCRI(ei) = false], где 1 ^ i < n.

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

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

— APA* — множество всех функций административных прав доступа административных ролей;

— PA* — множество всех функций прав доступа ролей и административных ролей;

— AA* — множество множеств доступов субъект-сессий к ролям или административным ролям;

— CAPA : APA* ^ {true, false} — функция, задающая ограничение на значения множеств административных прав доступа административных ролей, т. е. по определению множества административных прав доступа административных ролей, заданные функцией APA Е APA*, удовлетворяют ограничению CAPA, если выполняется равенство CAPA(APA) = true;

— CPA : PA* ^ {true, false} — функция, задающая ограничение на значения множеств прав доступа ролей и административных ролей, т. е. по определению множества прав доступа ролей и административных ролей, заданные функцией PA Е PA*, удовлетворяют ограничению CPA, если выполняется равенство CPA(PA) = true;

— CAA : AA* ^ {true, false} — функция, задающая ограничение на значение множества административных доступов субъект-сессий к ролям или административным ролям, т. е. по определению множества административных доступов субъект-сессий к ролям или административным ролям, заданные множеством AA Е AA*, удовлетворяют ограничению CAA, если выполняется равенство Caa(AA) = true;

— Constraint APA = {CAPA,..., C^PA } —множество функций, задающих некоторый набор ограничений на значения множеств административных прав доступа административных ролей, где nAPA ^ 0. При этом будем писать ConstraintaPa(APA) = = true тогда и только тогда, когда либо nAPA = 0, либо nAPA > 0 и Capa(APA) = = true для 1 ^ i ^ паРа;

— ConstraintPA = {CpA,... , CpAA } — множество функций, задающих некоторый набор ограничений на значения множеств прав доступа ролей, где пра ^ 0. При этом будем писать ConstraintPa(PA) = true тогда и только тогда, когда либо пРа = 0, либо nPA > 0 и Cpa(PA) = true для 1 ^ i ^ nPA;

— ConstraintAA = {C1AA, ... , CAA} — множество функций, задающих некоторый набор ограничений на значение множества административных доступов субъект-сессий к ролям или административным ролям, где паа ^ 0. При этом будем писать Constraintaa(AA) = true тогда и только тогда, когда либо паа = 0, либо паа > 0 и Caa(AA) = true для 1 ^ i ^ паа.

Механизм ограничений как мощное средство ролевого управления доступом целесообразно реализовать, как минимум, на перспективу. Ограничения, например, вза-

имного исключения ролей, количественные на обладание ролью, могут стать удобным средством администрирования защищённой ОС. Ограничениям на функции UA и roles, заданным в моделях семейства RBAC и других ролевых ДП-моделях, в МРОСЛ ДП-модели соответствуют ограничения на функцию APA и множество AA. Определение 4. Пусть определены:

— множества учётных записей пользователей U, сущностей E, субъект-сессий S, прав доступа к сущностям P, учётных записей доверенных пользователей Lj , доверенных субъект-сессий Ls, доступов субъект-сессий к сущностям A, доступов субъект-сессий к ролям и административным ролям AA, информационных потоков F, ограничений на значения множеств административных прав доступа административных ролей ConstraintaPa, множеств прав доступа ролей ConstraintPa, множеств доступов субъект-сессий к ролям или административным ролям ConstraintAA;

— функции административных прав доступа к ролям административных ролей APA, прав доступа ролей и административных ролей PA, принадлежности субъект-сессий учётным записям пользователей user, уровней конфиденциальности (fu, fe, fr, fs), мандатных атрибутов конфиденциальности CCR, уровней целостности (iu, ie, ir, is), мандатных атрибутов целостности CCRI, иерархии ролей Hr, иерархии сущностей He , иерархии субъект-сессий Hs.

Определим G = (APA, PA, user, (fu, fe, fr, fs), CCR, (iu, ie, ir, is), CCRI, A, AA, F, Hr, He, Hs, ConstraintAPA, ConstraintPA, ConstraintAA, Ljj, Ls) —состояние системы.

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

— T,(G*, OP) — система, где G* — множество всех возможных её состояний; OP — множество правил преобразования её состояний.

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

2. Параметрически ассоциированные сущности.

Специальные административные роли

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

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

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

получить доступ на чтение или на запись ко всем сущностям, параметрически ассоциированным с данной ролью. Множество сущностей, параметрически ассоциированных с ролью или административной ролью, не изменяется в процессе функционирования системы. Множество сущностей, параметрически ассоциированных с каждой индивидуальной административной ролью учётной записи пользователя, совпадает с множеством сущностей, параметрически ассоциированных с данной учётной записью пользователя.

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

С учётом сделанных предположений используем следующие обозначения:

— ]u[E E — множество сущностей, параметрически ассоциированных с учётной записью пользователя u Е U;

— UE = {e E]u[: u Е U} — множество сущностей, каждая из которых параметрически ассоциирована хотя бы с одной учётной записью пользователя;

— ]r[е E — множество сущностей, параметрически ассоциированных с ролью или административной ролью r Е R U AR, при этом для каждой учётной записи пользователя u Е U в соответствии с предположением 4 выполняется условие )u[=]u_admin_i_low[, и если iu(u) = i_high, то ]u[=]u_admin_i_high[;

— RE = {e E]r[: r Е R U AR} —множество сущностей, параметрически ассоциированных хотя бы с одной ролью или административной ролью.

Предположение 5. В рамках МРОСЛ ДП-модели на траекториях функционирования системы не изменяются функции ConstraintаРa, Constraintра и Constraintаа. Новые значения для функций fs и is задаются только при создании соответствующих новых субъект-сессий. В дополнение к предположению 1, недоверенная субъект-сессия всегда может создать недоверенную субъект-сессию с низким уровнем доступа. В начальном состоянии G0 любой системы E(G*, OP) выполняются следующие условия:

— функции APA0, PA0 и множество AA0 удовлетворяют соответствующим ограничениям ConstraintAPA, Constraintра и Constraintаа;

— для любых субъект-сессии s Е S0 и сущности e Е E0, если (s,e,aa) Е A0, где aa Е Ra, то справедливо равенство execute_container0(s,e) = true.

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

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

— ADMIN_ROLES С AR — множество специальных административных ролей, которые не могут создаваться, удаляться, переименовываться, менять свои параметры в процессе функционирования системы. Все административные роли из множества ADMIN_ROLES по определению обладают высоким уровнем целостности: для административной роли ar Е ADMIN_ROLES справедливо равенство ir (ar) = i_high;

— users_admin_role E ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для изменения уровня доступа или целостности, удаления учётной записи пользователя;

— entities_admin_role E ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для изменения ею единственной роли-владельца сущности (роли, обладающей правом доступа владения ownr к сущности), получения данных о ролях или административных ролях, обладающих правами доступа к сущности, получения числа «жёстких» ссылок к сущности, изменения уровня конфиденциальности или целостности сущности, изменения мандатного атрибута конфиденциальности CCR, мандатного атрибута целостности CCRI или метки разделяемости сущности-контейнера, переименования, удаления сущности-контейнера или «жёсткой» ссылки на него с мандатным атрибутом целостности CCRI равным false;

— subjects_admin_role Е ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для изменения единственной роли-владельца другой субъект-сессии, получения данные о ролях или административных ролях, обладающих правами доступа владения к другой субъект-сессии;

— roles_admin_role, admin__roles_admin_role E ADMIN_ROLES — специальные административные роли, являющиеся ролями-владельцами ролей или административных ролей соответственно, доступ субъект-сессии на чтение к каждой из которых требуется для управления доступом к роли или административной роли, изменения её уровней конфиденциальности или целостности, создания, переименования, удаления, получения параметров роли или административной роли, создания, изменения уровня доступа или целостности учётной записи пользователя;

— downgrade_admin_role Е ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для нарушения ею правил мандатного управления доступом.

По определению справедливы равенства

fr(users_admin_role) = fr(entities_admin_role) = fr(subjects_admin_role) =

= fr (roles _admin_role) = fr (admin _roles_admin_role) = ®LC, fr (downgrade _admin _role) = ®LC.

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

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

модели. Правила предназначены для формального описания (спецификации) следующих основных функций механизма управления доступом защищённой ОС:

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

— получения доступов субъект-сессий к сущностям, ролям или административным ролям;

— изменения прав доступа ролей или административных ролей к сущностям, субъект-сессиям, ролям или административным ролям;

— изменения иерархии, уровней конфиденциальности или целостности сущностей, ролей или административных ролей.

В таблице приведено детальное описание де-юре правил администрирования системы, при этом в ней не указываются элементы последующего состояния G', которые не изменяются в результате применения соответствующего правила к исходному состоянию G.

Де-юре правила администрирования системы в рамках МРОСЛ ДП-модели Правило: create_user(x, x', u, uc, ui, ue)

Условия применения: x,x' Є S, u Є U, (x, users_admin_role,reada) Є AA, (x, roles_admin-_role,aa) Є AA, (x, admin_roles_admin_role, aa) Є AA, где aa Є {reada,writea}; ue С UE; [uc = fs(x) или (uc ^ fs(x) и (x,downgrade_admin_role,reada) Є AA)]; ui ^ is(x); [для e Є ue выполняется fe(e) = uc, ie(e) = ui]; Constraintapa(APA') = true; ConstraintPA(PA') = true; [если ui = i_high, то (x', fs(x)_i_entity, writea) Є A]

Результаты применения: U' = U U {u}, ]u[= ue, fu(u) = uc, i’u(u) = ui, если ui = i_high, то Lj = Lj U {u}, иначе Nj = Nj U {u}, для u' Є U выполняется fu(u') = fu(u'), i'u(u') = iu(u'),

AR' = AR U {u_admin_li : li ^ ui}, fr(u_admin_li) = ®LC, i'r(u_admin_li) = li,

shared_container'(u_admin_li) = true, CCR'(u_admin_li) = CCRI'(u_admin_li) = false, role_name'(u_admin_li) =“u_admin_li", где li ^ ui,

Hr(u_admin_i_low) = 0, если ui = i_high, то HR(u_admin_i_high) = {u_admin_i_low},

R' = R U {u_c_l_li : l ^ uc,li ^ ui}, fr (u_c_l_li) = l, i'r (u_c_l_li) = li, shared _contai-ner'(u_c_l_li) = true, CCR'(u_c_l_li) = CCRI'(u_c_l_li) = false, role_name'(u_c_l_li) =

= “u_c_l_li", где l ^ uc, li ^ ui,

AP A' (admin _roles _admin _role)=AP A(admin _roles _admin _role)U{(u _admin _li, ownr ):li^ui}, APA'(roles_admin_role) = APA(roles_admin_role) U {(u_c_l_li, ownr) : l ^ uc, li ^ ui}, для ar Є AR выполняется APA'(ar) = APA(ar) U {(u_admin_li, executer) : li ^ ui} U {(u_c_l_li, executer) : l ^ uc, li ^ ui},

AP A'(u _admin _i _low) = {(u _admin _i _low, ar) : ar Є {readr ,writer ,executer }}U U{(u_c_l_(i_low),ar) : l ^ uc, ar{readr,writer,executer}},

если ui = i_high, то APA'(u_admin_i_high) = {(u_admin_li,ar) : li ^ ui,ar Є {readr, writer, executer}} U {(u_c_l_(i_high),ar) : l ^ uc,ar Є {readr,writer,executer}},

Hr(u_c_l_li) = {u_c_l'_li' : l' < l,li' < li и не существуют l'' Є LC(l' < l'' < l) или li'' Є LI (li' < li'' < li)}, PA'(u_c_l_li) = 0, где l ^ uc, li ^ ui

Правило: set_user_labels(x, x', u, uc, ui, ue)

Условия применения: x,x' Є S, u Є U, user-1(u) = 0, (x, users_admin_role, reada) Є AA, (x, roles_admin_role, aa) Є AA, (x, admin_roles_admin_role, aa) Є AA, где aa Є {reada, writea}, [если fu(u) = uc, то max(fu(u), uc) ^ fs(x) и (x, downgrade_admin_role, reada) Є AA], max(iu(u), ui) ^ is(x), [для e Є ue верно fe(e) = uc, ie(e) = ui], Constraintapa(APA') = true, Constraintpa(PA') = true, [если ui = i_high, то (x', fs(x)_i_entity, writea) Є A]

Продолжение таблицы Результаты применения: ]u[= ue, fU(u) = uc, i'u(u) = ui, если ui = i_high, то LJ = Lu U {u}, NJ = Nu \ {u}, иначе NJ = Nu U {u}, LJ = Lu \ {u}, для u' E U \ {u} верно f (u') = fu(u'), i'u(u') = iu(u'), AR' = (A U {u_admin_li: iu(u) < li ^ ui}) \ {u_admin_li: ui < li ^ iu(u)}, f, (u_admin_li) = ®LC, i'r (u_admin_li) = li, shared _container'(u_admin_li) = true,

CCR'(u_admin_li) = CCRI'(u_admin_li) = false, role_name'(u_admin_li) = “u_admin_li”, где iu(u) < li ^ ui,

если ui = i_high, то H'R(u_admin_i_high) = {u_admin_i_low}, R' = (R U {u_c_l_li : fu(u) <

< l ^ uc,iu(u) < li ^ ui}) \ {u_c_l_li : uc < l ^ fu(u),ui < li ^ iu(u)}, fr(u_c_l_li) = l, i'r(u_c_l_li) = li, shared_container'(u_c_l_li) = true, CCR'(u_c_l_li) = CCRI'(u_c_l_li) = = false, role_name'(u_c_l_li) = “u_c_l_li", где fu(u) < l ^ uc, iu(u) < li ^ ui,

APA'(admin_roles_admin_role) = (APA(admin_roles_admin_role) U {(u_admin_li,ownr) : iu(u) < li ^ ui}) \ {(u_admin_li,ownr) : ui < li ^ iu(u)}, AP A'(roles _admin_role) = = (APA(roles_admin_role) U {(u_c_l_li, ownr) : fu(u) < l ^ uc, iu(u) < li ^ ui})\

\{(u_c_l_li, ownr) : uc < l ^ fu(u), ui < li ^ iu(u)},

для ar E AR выполняется APA'(ar) = (APA(ar) U {(u_admin_li,executer) : iu(u) < li ^ ui} U U{(u_c_l _li, executer) : fu(u) < l ^ uc,iu(u) < li ^ ui}) \ ({(u_admin_li,executer) : ui < li ^

^ iu(u)} U {(u_c_l_li, executer) : uc < l ^ fu(u),ui < li ^ iu (u)}), AP A'(u _admin _i _low) = = (APA'(u_admin_i_low) U {(u_c_l_(i_low), ar) : fu(u) < l ^ uc,ar E {readr,writer,

executer }}) \ {(u _c _l _(i _low), ar) : uc < l ^ fu(u),ar E {readr ,writer ,executer }}, если ui = i_high, то APA'(u_admin_i_high) = (APA(u_admin_i_high) U {(u_admin_li, ar) : li ^ ui,ar E {readr,writer, executer}} U {(u_c_l_(i_high),ar) : fu(u) < l ^ uc,ar E {readr, writer, executer}}) \ {(u_c_l_(i_high), ar) : uc < l ^ fu(u), ar E {readr, writer, executer}},

Hr(u_c_l_li) = {u_c_l'_li' : l' < l, li' < li и не существуют l'' E LC(l' < l'' < l) или li'' E LI (li' < li'' < li)}, PA'(u_c_l_li) = 0, где fu(u) < l ^ uc, iu(u) < li ^ ui Правило: delete_user(x, x', u)

Условия применения: x,x' E S, u E U, user-1(u) = 0, (x,users_admin_role,reada) E AA, (x, users_admin_role,reada) E AA, (x, roles_admin_role,reada) E AA, [fu(u) = fs(x) или (fu(u) ^ fs(x) и (x,downgrade_admin_role,reada) E AA)], iu(u) ^ is(x), Constraintapa(-APA') = = true, ConstraintpA(PA') = true, [если iu(u) = i_high, то (x', fs(x)_i_entity, writea) E A] Результаты применения: U' = U \ {u}, для u' E U' выполняется fu(u') = fu(u'), i’u(u') = iu(u'), AR' = AR \ {u_admin_li : li ^ ui}, R' = R \ {u_c_l_li : l ^ uc, li ^ ui}, для ar E AR' выполняются равенства APA'(ar) = APA(ar) \ ({(u_admin_li, ar) : li ^ ui, ar E Rr} U {(u_c_l_li, ar) : l ^ uc, li ^ ui, ar E Rr})

Правило: get_user _attr(x, u, z)

Условия применения: x E S, u E U, z E O, [fu(u) ^ fs(x) или (x, downgrade_admin_role,

reada) E AA], (x, z,writea) E A

Результаты применения: V'(z) = (fu(u),iu(u), (если user(x) = u или (x, users_admin_role, reada) E AA, то {(r',ar) : (r',ar) E APA(u_admin_li), li ^ iu(u) и (fr(r') ^ fs(x) или (x, downgrade_admin_role,reada) E AA)}, иначе “0”), (если user(x) = u или (x, users_admin_role, reada) E AA, то {s E S: user(s) = u и либо fs(s) ^ fs(x) или (x, downgrade_admin_role,

reada) E AA)}, иначе “0”))

Правило: grant_rights(x, x', r, {(y, arj): 1 ^ j ^ k})

Условия применения: x,x' E S, y E E, r E R U AR, arj E {readr ,writer ,executer }, (x,r,writea) E AA, ie(y) ^ is(x), [существует r' E R U AR ((x,r',reada) E AA, (y,ownr) E PA(r'))], [либо (execute _-container(x,y) = true и fe(y) = fs(x)), либо (x, downgrade_admin_role,reada) E AA], [если arj = writer, то ie(y) ^ ir(r)], ConstraintpA(PA') = true, [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) E A], где 1 ^ j ^ k

Результаты применения: PA'(r) = PA(r) U {(y,arj) : 1 ^ j ^ k} и для r' E (R U AR) \ {r} выполняется равенство PA'(r') = PA(r')

Продолжение таблицы

Правило: remove _rights(x, x', r, {(y, ar.): 1 ^ j ^ k})___________________________________

Условия применения: x,x' E S, y E E, r E R U AR, arj E {readr,writer,executer}, {(y,arj) :

1 ^ j ^ k} С PA(r), (x,r,writea) E AA, ie(y) ^ is(x), [существует r' E R U AR ((x,r', reada) E AA, (y,ownr) E PA(r'))], [либо (execute_container(x,y) = true и fe(y) = fs(x)), либо (x,downgrade_admin_role,reada) E AA], ConstraintpA(PA') = true, [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) E A], где 1 ^ j ^ k

Результаты применения: PA'(r) = PA(r) \ {(y,ar.) : 1 ^ j ^ k}, и для r' E (R U AR) \ {r} выполняется равенство PA'(r') = PA(r')

Правило: set_entity_owner(x, x', r, r', y)

Условия применения: x,x' E S, y E E, r,r' E R U AR, {(x,r,reada), (x,r,writea), (x,r', writea), (x, entities _admin_role,reada)} С AA, (y,ownr) E PA(r), ConstraintpA (PA') = true, ie(y) ^ min(ir(r'),is(x)), [либо (execute_container(x,y) = true и fe(y) = fs(x)), либо ((x,downgrade _admin _role,reada) E AA)], [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) E A] Результаты применения: PA'(r) = PA(r) \ {(y,ownr)}, PA'(r') = PA(r') U {(y,ownr)}, для r'' E (R U AR) \ {r, r'} выполняется равенство PA'(r'') = PA(r'')

Правило: set_subject_owner(x, x', r, r', y)

Условия применения: x,x' E S, y E S, r,r' E R U AR, {(x,r,reada), (x,r,writea), (x,r',writea), (x, subjects _admin_role,reada)} С AA, (y,ownr) E PA(r), ConstraintpA (PA') = true, is(y) ^

^ min(ir(r'),is(x)), [либо fs(y) = fs(x), либо (x, downgrade_admin_role,reada) E AA], [если is(y) = i_high, то (x', fs(x)_i_entity, writea) E A]

Результаты применения: PA'(r) = PA(r) \ {(y,ownr)}, PA'(r') = PA(r') U {(y,ownr)}, для r'' E (R U AR) \ {r, r'} выполняется равенство PA'(r'') = PA(r'')

Правило: grant_admin_rights(x, x', ar, {(r, arj): 1 ^ j ^ k})

Условия применения: x,x' E S, r E R U AR, ar E AR, ar. E {writer ,readr}, (x, ar,writea) E AA, ir(r) ^ ir(ar), ir(r) ^ is(x), [если r E R, то (x,roles_admin_role,reada) E AA, если r E AR, то (x, admin_roles_admin_role, reada) E AA], [либо fr(r) = fs(x), либо (x, downgrade_admin_-role,reada) E AA], Constraintapa(APA') = true, [если ir(r) = i_high, то (x', fs(x)_i_entity,

writea ) E A], где 1 < j < k_______________________________________________________________

Результаты применения: APA'(ar) = APA(ar) U {(r,ar.) : ar. = writer, 1 ^ j ^ k} U {(r',ar.): arj = readr, r' ^ r, 1 ^ j ^ k}, для ar' E AR \ {ar} выполняется равенство APA'(ar') = APA(ar')

Правило: remove_admin_rights(x, x', ar, {(r, ar.): 1 ^ j ^ k})_____________________________

Условия применения: x,x' E S, r E R U AR, ar E AR, arj E {writer ,readr}, {(r,arj) : arj = writer, 1 ^ j ^ k} С APA(ar), (x,ar,writea) E AA, ir(r) ^ is(x), [если r E R, то (x, roles_admin_role, reada) E AA, если r E AR, то (x, admin_roles_admin_role,reada) E AA], [либо fr (r) = fs(x), либо (x, downgrade _admin_role,reada) E AA], Constraint ap a (APA') = true, [если ir (r) = i_high, то (x', fs(x)_i_entity, writea) E A], где 1 ^ j ^ k

Результаты применения: APA'(ar) = APA(ar) \ ({(r, arj) : arj = writer, 1 ^ j ^ k} U {(r', arj): ar. = readr, r ^ r', 1 ^ j ^ k}), для ar' E AR \ {ar} верно равенство APA'(ar') = APA(ar')_

Правило: create_role(x, x', r, rc, ri, re, name, rz)

Условия применения: x,x' E S, r E R U AR, [если rz E R, то (x, roles_admin_role, aa) E AA, если rz E AR, то (x,admin_roles_admin_role,aa) E AA, где aa E {reada, writea}], (x,rz, writea) E AA, re С RE, name E NAME\ {«»}, [либо r = fr(rz) = fs(x), либо r ^ fr(rz) и (x, downgrade_admin_role,reada) E AA], ri ^ min(ir(rz), is(x)), [для e E re выполняется fe(e) = rc, ie(e) = ri], Constraint apa( APA') = true, ConstraintpA (PA') = true, [если ir (rz) = i_high, то (x', fs(x)_i_entity, writea) E A]

Результаты применения: если rz E R, то R' = RU{r}, APA'(roles_admin_role) = APA(roles_-admin_role) U {(r,ownr), (r,executer)} U {(r,readr) : (rz,readr) E APA(roles_admin_role)}, если rz AR, то AR' = AR U {r}, APA'(admin_roles_admin_role) = APA(admin_roles_-

admin_role) U {(r,ownr), (r,executer)} U {(r,readr) : (rz,readr) E APA(admin_roles_admin_-role)}, для ar E AR \ {admin_roles_admin_role, roles_admin_role} выполняется APA'(ar) = = APA(ar) U {(r, executer)} U {(r, readr) : (rz, readr) E APA(ar)},

fr(r) = rc, i'r(r) = ri, CCR'(r) = false, CCRI'(r) = false, role_name'(rz,r) = name, ]r[= re, shared_container'(r) = true, PA'(r) = 0, H'R(rz) = He(z) U {r}, H'R(r) = 0, для r E (RU AR) \ {r} выполняется равенство HR' (r) = HR(r)

Окончание таблицы

Правило: delete_role(x, x', r, rz)

Условия применения: x,x' E S, r E (R U AR) \ ({u_admin_li : u EU,li ^ iu(u)} U {u_c_l_li : u E U, l ^ fu(u), li ^ iu(u)} U ADMIN_ROLES), [если r E R, то rz E R, (x, roles_admin_-role,aa) E AA, если r E AR, то rz E AR, (x, admin_roles_admin_role,aa) E AA, где aa E E {reada,writea}], r E H'(rz), HR(r) = 0, [не существует rz' E R U AR, такой, что rz' = rz и r E HR(rz')], [(x,rz,writea) E AA, Constraintaa(AA') = true, Constraintapa(APA') = = true, Constraintpa(P'A') = true], [либо fr(r) = fs(x), либо fr(r) ^ fs(x) и (x, downgrade_-admin_role, reada) E AA], ir (r) ^ is(x), [если ie(z) = i_high, то (x',fs(x)_i_entity, writea) E A] Результаты применения: R' = R \ {r}, AR' = AR \ {r}, H'R(rz) = HR(rz) \ {r}, для всех r' E (R'UAR')\{rz} выполняется равенство H'R(r') = HR(r'), для ar E AR' выполняются равенства APA'(ar) = APA(ar) \ {(r, ar) : ar E R}, AA' = AA \ {(s, r, aa) : s E S, aa E Ra}

Правило: create_hard_link_role(x, x', r, name, rz)

Условия применения: x,x' E S, r E (R U AR) \ ({u_admin_li : u EU,li ^ iu(u)} U {u_c_l_li : u E U,l ^ fu(u), li ^ iu(u)} U ADMIN_ROLES), не выполняется условие rz ^ r,

Constraintapa(APA') = true, [если rz E R, то (x, roles_admin_role,aa) E AA, если rz E AR, то (x, admin_roles_admin_role,aa) E AA, где aa E {reada,writea}], (x,rz,writea) E AA, name E E N AM E\{«»}, [либо fr (r) = fr (rz) = fs (x), либо fr (r) ^ fr (rz) и (x, downgrade _admin_role, reada) E AA], ir(r) ^ min(ir (rz),is(x)), [если ir(rz) = i_high, то (x', fs(x)_i_entity, writea) E A] Результаты применения: role_name'(rz,r) = name, H'R(rz) = H'(rz) U {r}, H'R(r) = 0, для r' E (R U AR) \ {r} выполняется равенство H'R(r') = H'(r'), для ar E AR, таких, что (rz,readr) E E APA(ar), выполняется APA'(ar) = APA(ar) U {(r', readr) : r' ^ r}

Правило: delete_hard_link_role(x, x', r, rz)

Условия применения: x,x' E S, r E (R U AR) \ ({u_admin_li : u EU,li ^ iu(u)} U {u_c_l_li : u E U,l ^ fu(u), li ^ iu(u)} U ADMIN_ROLES), [если rz E R, то (x, roles_admin_role, aa) E AA, если rz E AR, то (x, admin_roles_admin_role,aa) E AA, где aa E {reada,writea}], r E H'(rz), [существует rz' E RUAR, такая, что rz' = rz и r E H'(rz')], (x, rz, writea) E AA, [либо fr(r) = fs(x), либо fr(r) ^ fs(x) и (x, downgrade_admin_role, reada) E AA], ir(r) ^ is(x), [если ie(z) = i_high, то (x', fs(x)_i_entity, writea) E A]

Результаты применения: HR (rz) = HR(rz) \ {y}, для r' E (R U AR) \ {r} верно HR (r') = HR(r') Правило: set_container_attr(x, x', y, ccr, ccri, t)

Условия применения: x,x' E S, y E C, ccr, ccri,t E {true, false}, ie(y) ^ is(x), [либо существует r E R U AR ((x,r,reada) E AA, (y,ownr) E PA(r)), либо (x, entities_admin_role,reada) E AA], [либо (execute_container(x,y) = true и fe(y) = fs(x)), либо (x, downgrade_admin_role,reada) E E AA], [(x, entities_admin_role,reada) E AA или (x, downgrade_admin_role,reada) E AA], [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) E A]

Результаты применения: CCR'(y) = ccr, CCRI'(y) = ccri, shared_container'(y) = t Правило: set_entity_labels(x, x', y, yc, yi)

Условия применения: x,x' E S, y E E, y / UE U RE, (x, entities_admin_role, reada), (x, downgrade _admin_role,reada) E AA, {(s,y,aa) : s E S,aa E Ra} П A = 0, max(fe(y),yc) ^ fs(x), max(ie(y),yi) < is(x), [yc < fe(z), yi < ie(z) для всех z E E, таких, что y E He(z)], [fe(z) < yc, ie(z) ^ yi для всех z E E, таких, что z E He(y)\, [если ie(y) = i_high или yi = i_high, то

(x', fs(x)_i_entity, writea) E A]

Результаты применения: fe(y) = yc, i'e(y) = yi Правило: set_role_labels(x, x', r, rc, re)

Условия применения: x,x' E S, r E (R U AR) \ ({u_admin_li : u EU,li ^ iu(u)} U {u_c_l_li : u E U,l ^ fu(u), li ^ iu(u)} U ADMIN_ROLES), (x, downgrade_admin_role, reada) E AA,

[если r E R, то (x, roles_admin_role, reada) E AA, если r E AR, то (x, admin_roles_admin_role, reada) E AA], max(fr(r),rc) E fs(x), {(s,r,aa) : s E S,aa E Ra} П AA = 0, [rc ^ fr(rz) для всех rz E R U AR, таких, что r E Hr (rz)], [fr (rz) ^ rc для всех rz E R U AR, таких, что rz E E H'(r)], re С RE, [для e E re выполняется fe(e) = rc, ie(e) = ir(r)], [если ir(r) = i_high, то (x', fs(x)_i_entity, writea) E A]

Результаты применения: fr (r) = rc, ]r[= re

Рассмотрим условия и результаты применения де-юре правил преобразования состояний.

Де-юре правила create_user(x, x',u,uc,ui,ue), set_user_labels(x,x',u,uc,ui,ue), delete_user(x, x',u) и get_user_attr(x,u,z) позволяют субъект-сессии x создать, изменить уровни конфиденциальности и целостности, удалить или получить параметры учётной записи пользователя u с уровнем доступа, равным текущему уровню доступа субъект-сессии x (за исключением случая, когда субъект-сессия x обладает административным доступом на чтение к специальной административной роли downgrade_admin_role), и уровнем целостности, не превосходящим текущего уровня целостности субъект-сессии x (кроме случая получения параметров). Во всех случаях, кроме получения параметров, требуется наличие у субъект-сессии x доступа на чтение к специальной административной роли users_admin_role, а также в последующем состоянии системы — выполнение ограничений на значения множеств административных прав доступа административных ролей ConstraintAPA (с учётом создания или удаления индивидуальных административных ролей и индивидуальных ролей учётной записи пользователя u), а если осуществляются действия над учётной записью пользователя u с высоким уровнем целостности, то необходимо обладание некоторой кооперирующей с x (либо самой x) субъект-сессией x' доступом на запись к сущности fs (x)_i_entity, что моделирует ситуацию подачи сигнала системе (нажатия со-

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

Следует заметить, что эти действия осуществляются без явного получения субъект-сессией x административного доступа на запись ко всем административным ролям, административные права доступа которых модифицируются, что сделано, во-первых, для удобства реализации правил в реальной защищённой ОС, во-вторых, для использования правил требуются специальные административные роли roles_admin_role и admin_roles_admin_role, доступные только доверенным субъект-сессиям, не участвующим в реализации запрещённых информационных потоков по времени. Для создания, удаления и изменения уровней конфиденциальности и целостности учётной записи пользователя требуется наличие у субъект-сессии x доступов на чтение и запись к специальным административным ролям roles_admin_role и admin_roles_admin_role, так как именно эти роли получают права доступа владения к создаваемым при применении правил индивидуальным административным ролям и индивидуальным ролям учётной записи пользователя u, при этом (в том числе при изменении параметров) задаются множества сущностей, параметрически ассоциированных с учётной записью пользователя u.

В случае изменения параметров учётной записи пользователя или её удаления требуется, чтобы в этот момент времени от её имени в системе не функционировала ни одна субъект-сессия. При получении параметров в сущность z, к которой субъект-сессия x должна иметь доступ на запись, всегда записываются уровни доступа и целостности учётной записи пользователя u (т. е. если в системе не предъявляются дополнительные требования к анонимности, то самые общие данные о зарегистрированных учётных записях пользователей должны предоставляться всем субъект-сессиям с соответствующим уровнем доступа), а также, когда x функционирует от имени u или обладает текущим административным доступом на чтение к роли users_admin_role, записываются роли (с учётом их уровней конфиденциальности и уровня доступа x) и права доступа к ним, которыми обладают индивидуальные административные роли u, и записываются субъект-сессии (в реальной защищённой ОС — идентификаторы

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

Де-юре правила grant_rights(x, x', r, {(y, arj) : 1 ^ j ^ k}) и remove_rights(x, x', r, {(y, arj) : 1 ^ j ^ k}) позволяют субъект-сессии x добавить или удалить соответственно права доступа к сущности y, имеющей уровень целостности не выше, чем у x, из множества прав доступа (за исключением права доступа владения) роли или административной роли r. Возможность с использованием правил одновременного изменения нескольких прав доступа к одной сущности соответствует возможностям типовых для реальных защищённых ОС функций администрирования прав доступа (например, функции chmod). Для применения правил необходимо наличие у субъект-сессии x доступа на запись к роли r и наличие текущей роли, обладающей правом доступа владения к сущности у. Во всех случаях (за исключением наличия у субъект-сессии x текущей административной роли downgrade_admin_role) требуется, чтобы x могла получить доступ к сущности y с учётом прав доступа к сущностям-контейнерам, содержащим у, и чтобы уровень конфиденциальности у равнялся уровню доступа x. Кроме того, если осуществляется добавление права доступа на запись, то требуется, чтобы уровень целостности сущности у не превосходил уровня целостности роли r. Также необходимо выполнение ограничений на значения множеств прав доступа ролей или административных ролей ConstraintpA в последующем состоянии системы (с учётом изменения у роли r прав доступа к у). При этом в случае, когда уровень целостности сущности у равняется i_high, требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Де-юре правила set_entity_owner(x,x',r,r',у) и set_subject_owner(x, x',r,r',у) позволяют субъект-сессии x изменить единственную роль-«владельца» (имеющую право доступа владения) к сущности или субъект-сессии у соответственно с роли или административной роли r на роль или административную роль r'. Для этого субъект-сессии x необходимо иметь административные доступы на чтение и запись к r и на запись к r' (чтобы иметь возможность менять права доступа данных ролей), а также иметь административный доступ на чтение соответственно либо к административной роли entities_admin_role, либо к subjects_admin_role. При этом уровень целостности у не должен превосходить уровней целостности r' и x ив последующем состоянии системы должны выполняться ограничения на значения множеств прав доступа ролей или административных ролей ConstraintpA (с учётом изменения прав доступа ролей r и r'). За исключением случая наличия у субъект-сессии x текущей административной роли downgrade_admin_role, когда изменяется роль-«владелец» сущности у, требуется, чтобы x могла получить доступ к сущности у с учётом прав доступа к сущностям-контейнерам, содержащим у, и чтобы уровень конфиденциальности у равнялся уровню доступа x; когда изменяется роль-«владелец» субъект-сессии у, требуется, чтобы x и у имели равные уровни доступа. При этом в случае, когда уровень целостности у равняется i_high, требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Де-юре правила grant_admin_rights(x, x',ar, {(r,arj) : 1 ^ j ^ k}) и remove_ad-min_rights(x,x',ar, {(r,arj) : 1 ^ j ^ k}) позволяют субъект-сессии x добавить или удалить соответственно права доступа на чтение или запись к роли или административной роли r, имеющей уровень целостности не выше, чем у x, из множества прав доступа административной роли ar, к которой x должна иметь административный до-

ступ на запись. Для изменения прав доступа к роли r требуется наличие у x текущей административной роли roles_admin_role, а если r является административной ролью, то к роли admin_roles_admin_role. Во всех случаях (за исключением наличия у субъект-сессии x текущей административной роли downgrade_admin_role) требуется, чтобы уровень конфиденциальности r равнялся уровню доступа x. Также необходимо выполнение ограничений на значения множеств административных прав доступа административных ролей Constraintapa в последующем состоянии системы (с учётом изменения у административной роли ar прав доступа к r). При добавлении прав доступа к роли r её уровень целостности должен быть не выше уровня целостности административной роли ar. В случае, когда уровень целостности роли или административной роли r равняется i_high, требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Де-юре правила create_role(x, x',r,rc,ri, re, name, rz), create_hard_link_role(x, x',r,name,rz), delete_role(x, x',r,rz) и delete_hard_link_role(x, x',r,rz) позволяют субъект-сессии x создать или удалить роль или административную роль r или «жёсткую» ссылку на неё (изменить иерархию ролей), входящую в состав роли или административной роли rz, к которой субъект-сессия x должна иметь доступ на запись. При этом нельзя удалять или создавать роли или административные роли, «жёсткие» ссылки на них, являющиеся индивидуальными ролями и индивидуальными административными ролями учётных записей пользователей, а также специальными административными ролями из множества ADMIN_ROLES. Для применения правил необходимо наличие у субъект-сессии x административных доступов на чтение и запись к административным ролям roles_admin_role или admin_roles_admin_role для действий ролями или административными ролями соответственно. При этом доступ на запись к этим административным ролям следует требовать, так как создание, удаление ролей или «жёстких» ссылок на них являются существенными преобразованиями параметров безопасности системы. При реализации правил в последующем состоянии иерархия ролей модифицируется (назначаются или удаляются административные права доступа), при этом должны выполняться ограничения на значения множеств административных прав доступа административных ролей Constraint apa, а при удалении ролей или административных ролей — на значение множества административных доступов ConstraintAA.

Аналогично правилам администрирования учётных записей пользователей, при реализации правил создания или удаления ролей права доступа к ним могут изменяться у административных ролей без явного получения к ним субъект-сессией x административного доступа на запись. Так же, как при удалении сущностей или «жёстких» ссылок на них, при удалении роли или административной роли проверяется, что ей в иерархии не подчинены другие роли, а при удалении «жёсткой» ссылки на роль — что эта ссылка не последняя. Однако при создании «жёсткой» ссылки на роль (так как, в отличие от сущностей, могут создаваться «жёсткие» ссылки на роли-контейнеры, содержащие подчинённые роли) проверяется, что это не приведёт к возникновению в иерархии циклов, т. е. нарушению отношения частичного порядка. При применении правил уровень конфиденциальности роли или административной роли r должен равняться уровню доступа субъект-сессии x (за исключением случая, когда x имеет административный доступ на чтение к административной роли downgrade_admin_role), уровень целостности r должен быть не выше уровня целостности x, а при создании роли или «жёсткой» ссылки на неё уровень конфиденциальности роли r должен равняться уровню конфиденциальности роли-контейнера rz (за исключением случая, когда x имеет ад-

министративный доступ на чтение к административной роли downgrade_admin_role), в котором она создаётся, и уровень целостности r не должен превосходить уровня целостности rz. При создании роли или административной роли уровни конфиденциальности и целостности сущностей, параметрически ассоциированных с нею, устанавливаются равными её уровням конфиденциальности и целостности соответственно. Если осуществляются действия над ролями или административными ролями с высоким уровнем целостности i_high, то требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Де-юре правило set_container_attr(x,x',y,ccr,ccri,t) позволяет субъект-сессии x задать сущности-контейнеру у, обладающей уровнем целостности не выше, чем у x, либо её мандатный атрибут конфиденциальности CCR, либо уровень целостности CCRI, либо признак — является она разделяемой или нет. Для этого требуется наличие у субъект-сессии административного доступа на чтение к роли entities_admin_role или downgrade_admin_role. При этом субъект-сессия x должна иметь либо административный доступ на чтение к роли-«владельцу» контейнера у, либо к административной роли entities_admin_role, а также требуется (за исключением случая, когда x имеет административный доступ на чтение к административной роли downgrade_admin_role), чтобы доступ к у мог быть предоставлен x с учётом её прав доступа к сущностям-контейнерам, содержащим у, и уровень доступа x равнялся уровню конфиденциальности у. Если сущность-контейнер обладает высоким уровнем целостности i_high, то требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Де-юре правило set_entity_labels(x, x', у, yc, yi) позволяет субъект-сессии x задать сущности у (к которой на момент применения правила ни одна субъект-сессия системы не имеет доступов) её новые уровни конфиденциальности и целостности, для чего требуется наличие у x административного доступа на чтение к административным ролям entities_admin_role и downgrade_admin_role. При этом текущие и устанавливаемые уровни конфиденциальности и целостности сущности у не должны превосходить соответственно текущих уровней доступа и целостности субъект-сессии x. Кроме того, устанавливаемые уровни конфиденциальности и целостности сущности у не должны превосходить соответственно уровней конфиденциальности и целостности всех сущностей-контейнеров, в которых непосредственно находится у, и наоборот, должны быть не ниже уровней конфиденциальности и целостности соответственно всех сущностей, непосредственно входящих в у. Если либо текущий, либо устанавливаемый уровень целостности сущности у является высоким уровнем целостности i_high, то требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Де-юре правило set_role_labels(x,x',r,rc,re) позволяет субъект-сессии x задать роли или административной роли у (не являющейся индивидуальной ролью или индивидуальной административной ролью учётных записей пользователей, а также специальной административной ролью из множества ADMIN_ROLES, и к которой на момент применения правила ни одна субъект-сессия системы не имеет доступов) её новый уровень конфиденциальности, для чего требуется наличие у x административного доступа на чтение к административным ролям roles_admin_role, admin_roles_admin_role соответственно и к административной роли downgrade_admin_role. При этом текущие и устанавливаемые уровни конфиденциальности роли r не должны превосходить соответственно текущего уровня доступа субъект-сессии x. Кроме того, устанавливаемый уровень конфиденциальности

роли r не должен превосходить уровня конфиденциальности всех ролей или административных ролей, в которых непосредственно находится r, и наоборот, должен быть не ниже уровней конфиденциальности всех ролей или административных ролей, непосредственно входящих в r. При применении правила уровни конфиденциальности и целостности сущностей, параметрически ассоциированных с ролью или административной ролью r, должны быть соответственно равными уровням конфиденциальности и целостности r. Если уровень целостности роли r является высоким уровнем целостности i_high, то требуется наличие у кооперирующей субъект-сессии x' доступа на запись к сущности fs(x)_i_entity.

Заключение

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

ЛИТЕРАТУРА

1. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учебн. пособие для вузов. 2-е изд., испр. и доп. М.: Горячая линия-Телеком, 2013. 338 с.

2. Девянин П. Н. Корректность правил преобразования состояний системы в рамках мандатной сущностно-ролевой ДП-модели ОС семейства Linux // Прикладная дискретная математика. Приложение. 2013. №6. С. 58-59.

3. Девянин П. Н. Об опыте внедрения мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в защищенную ОС Astra Linux Special Edition // Методы и технические средства обеспечения безопасности информации. Материалы 22-й науч.-технич. конф. 08-11 июля 2013 г. СПб.: Изд-во Политехн. ун-та, 2013. С. 78-80.

4. Операционные системы Astra Linux. http://www.astra-linux.ru/.