Уровень запрещающих ролей иерархического представления МРОСЛ ДП-модели Текст научной статьи по специальности «Компьютерные и информационные науки»

2018 Математические основы компьютерной безопасности №39

УДК 004.94

УРОВЕНЬ ЗАПРЕЩАЮЩИХ РОЛЕЙ ИЕРАРХИЧЕСКОГО ПРЕДСТАВЛЕНИЯ МРОСЛ ДП-МОДЕЛИ

П. Н. Девянин

Федеральное учебно-методическое объединение в сфере высшего образования по УГСН 10.00.00 Информационная безопасность, г. Москва, Россия

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

Ключевые слова: компьютерная безопасность, ролевое управление доступом, запрещающая роль.

DOI 10.17223/20710410/39/5

THE LEVEL OF NEGATIVE ROLES OF THE HIERARCHICAL REPRESENTATION OF MROSL DP-MODEL

P. N. Devyanin

Federal Educational and Methodological Association in Information Security, Moscow, Russia

E-mail: [email protected]

MROSL DP-model is widely used as a mandatory entity-role model of access and information flows security control in Linux-type OS. To make the model to be more adequate for a number of special security features of the Russian OS Astra Linux Special Edition, it has been decided to extend MROSL DP-model by adding to it so called negative roles. In contrast to the ordinary roles, these ones contain access rights which prohibit entities or subject-sessions from getting some access. In this paper, an order of using negative roles in MROSL DP-model is defined, the corresponding changes of conditions and application results for state transformation de-jure rules in MROSL DP-model with negative roles are described, and the correctness of these modified rules are stated, namely: let G and G' be some states of MROSL DP-model with negative roles, G' be a result of transformation de-jure rules application to G, and G be satisfying all the conditions for mandatory role access control; then G' also satisfies all these conditions.

Keywords: computer security, role-based access control, negative role.

Введение

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

Однако практика использования МРОСЛ ДП-модели при реализации механизма управления доступом в отечественной защищенной операционной системе специального назначения (ОССН) Astra Linux Special Edition [5, 6] показала, что в ряде случаев применение только ролей, обладающих правами доступа к сущностям, разрешающим субъект-сессиям получение соответствующих доступов к ним, является недостаточным и создаёт неудобство при администрировании ОССН. В работе [7] описываются такие ситуации, когда, например, только одну учётную запись пользователя системы необходимо лишить права доступа, предоставляемого ей через роль, которой обладают все учётные записи пользователей системы, при этом все другие права доступа этой роли должны быть оставлены без изменений. Чтобы упростить администрирование ролевого управления доступом в подобных ситуациях, в этой же работе, а также в [8, 9] было предложено использование запрещающих ролей. Запрещающие роли, в отличие от «обычных», содержат права доступа к сущностям или субъект-сессиям, которые не разрешают, а наоборот, запрещают получение соответствующих доступов.

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

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

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

1. Состояние системы

С базового уровня МРОСЛ ДП-модели (его элементы и обозначения в целом соответствуют заданным в неиерархическом представлении МРОСЛ ДП-модели [2, 3]) на её уровне запрещающих ролей без изменений использованы следующие множества: U — учётных записей пользователей, S — субъект-сессий, O — объектов, C — контейнеров, E — сущностей, NAMES — имён сущностей, R — ролей, AR — административных ролей, SAR — специальных административных ролей, Rr —видов прав доступа, Ra — видов доступа, P — прав доступа к сущностям и субъект-сессиям, A — доступов субъект-сессий к сущностям, G* —всех возможных состояний системы, OP — правил преобразования состояний системы, U_ADMIN, U_ROLES — индивидуальных административных ролей и индивидуальных ролей учётных записей пользователей соответственно, COMMON_ROLES — общих ролей; функции: user : S ^ U — принадлежности субъект-сессии учётной записи пользователя, entity_name : C х E ^ 2NAMES — имён сущностей, HE : E ^ 2E — иерархии сущностей, HS : S ^ 2s — иерархии субъект-сессий, APA : AR ^ 2AP — административных прав доступа, direct : E U R U AR ^ {true, false} — вида метки; обозначения: users_admin_role, entities_admin_role, subjects_admin_role, roles_admin_role, admin_roles_admin_role — специальные административные роли, позволяющие администрировать учётные записи пользователей, сущности, субъект-сессии, роли или административные роли соответственно, u_admin, u_c, common_role — индивидуальные административные роли, роли и общие роли учётных записей пользователей, G \~ap G' — переход системы из состояния G в состояние G' в результате применения правила op, T,(G*, OP) — система, T,(G*, OP, G0) — система с начальным состоянием Go-Используем следующие дополнительные обозначения или переопределим некоторые обозначения базового уровня МРОСЛ ДП-модели:

— NR — множество запрещающих ролей, при этом по определению AR П NR = = R П NR = 0;

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

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

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

— shared_container : C U R U NR U AR ^ {true, false} — функция разделяемых контейнеров, такая, что сущность-контейнер, роль, запрещающая роль или административная роль c Е C U R U NR U AR является разделяемой, когда shared_container(c) = true, в противном случае shared_container(c) = false;

— role_name : (R U NR U AR) х (R U NR U AR) ^ NAMES — функция имён ролей, запрещающих ролей и административных ролей в составе роли, запрещающей роли или административной роли (как контейнера);

— HR : RUNRU AR ^ 2RU2NRU2AR — функция иерархии ролей, запрещающих ролей или административных ролей, для задания которой по аналогии с базовым уровнем модели используется отношение частичного порядка ^ на множестве R U NR U AR;

— execute_container : S х C х E ^ {true, false} — функция доступа субъект-сессии к сущностям в контейнерах, такая, что по определению для субъект-

сессии s Е S, контейнера c Е C и сущности e Е E справедливо равенство execute_container(s, c, e) = true тогда и только тогда, когда существует последовательность сущностей e1,... ,en Е E, где либо n =1 и c = e = e\, либо n ^ 2, c = en-1, e = en и выполняются следующие условия:

Условие 1. Не существует сущности-контейнера eo Е E, такой, что e1 Е He (eo) (без изменений по сравнению с базовым уровнем).

Условие 2. Верно ei Е HE (ei-1), где 1 < i ^ n (без изменений по сравнению с базовым уровнем).

Условие 3. Существует роль или административная роль ri Е R U AR, такая, что (s,ri,reada) Е AA и (ei,executer) Е PA(ri), где 1 ^ i < n (без изменений по сравнению с базовым уровнем).

Условие 4. Не существует запрещающей роли nr Е NR и i, 1 ^ i < n, таких, что (s,nr,reada) Е AA и (ei, executer) Е PA(nr).

Для обеспечения применения запрещающих ролей с использованием модели RBAC [1, 2] зададим механизм ограничений (Constraints) необходимого обладания запрещающей ролью с помощью следующей функции:

— constraint nr : R U AR ^ 2NR — функция необходимого обладания запрещающей ролью, задающая для каждой роли или административной роли множество запрещающих ролей, которые должна иметь субъект-сессия как текущие в случае обладания ею как текущей соответствующей ролью или административной ролью.

Пусть определена функция constraintNR необходимого обладания запрещающей ролью. Переопределим G = (APA, PA, user, A, AA, HR, HE,HS, constraintNR) — состояние системы.

2. Дополнительные условия реализации ролевого управления доступом

с запрещающими ролями

Зададим порядок предоставления прав доступа и доступов к запрещающим ролям, основанный на порядке реализации ролевого управления доступом, определённом на базовом уровне МРОСЛ ДП-модели.

Предположение 1. В системе на уровне запрещающих ролей МРОСЛ ДП-модели выполняются следующие условия:

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

— все запрещающие роли являются «разделяемыми контейнерами»: для каждой запрещающей роли nr Е NR справедливо равенство shared_container(nr) = true;

— у каждой административной роли есть права доступа executer ко всем запрещающим ролям: для каждой административной роли ar Е AR и запрещающей роли nr Е NR выполняется условие (nr,executer) Е APA(ar);

— существует единственная специальная административная роль negative_roles_-admin_role, обладающая к каждой запрещающей роли административным правом доступа владения: для каждой запрещающей роли nr Е NR выполняется условие {ar' Е AR : (nr,ownr) Е APA(ar')} = {negative_roles_admin_role}, где negative_roles_admin_role Е SAR;

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

пы на чтение и запись (кроме случая переименования) к административной роли negative _roles _admin _role;

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

Условие 2 (администрирование функции необходимого обладания запрещающей ролью, получение её значения):

— для специальных административных ролей из множества SAR не задаются запрещающие роли: для ar Е SAR верно constraintNR(ar) = 0;

— для изменения значения функции необходимого обладания запрещающей ролью constraint^R субъект-сессия должна иметь административный доступ на чтение к административной роли negative_roles_admin_role, а также в зависимости от того, является параметр функции ролью или административной ролью, субъект-сессия должна иметь административный доступ на чтение к административной роли roles_admin_role или admin_roles_admin_role соответственно;

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

— для получения субъект-сессией запрещающих ролей, заданных с помощью функции constraintnr для роли или административной роли, или, наоборот, ролей или административных ролей, для которых задана запрещающая роль, субъект-сессия должна иметь административный доступ на чтение к административной роли negative _roles_admin_role.

Условие 3 (доступы и права доступа запрещающих ролей):

— к запрещающим ролям субъект-сессии могут иметь любые виды административных доступов из множества Ra;

— в случае, когда для некоторой роли или административной роли задано непустое множество запрещающих ролей, административный доступ на чтение субъект-сессии к такой роли или административной роли предоставляется только при получении ею административного доступа на чтение ко всем соответствующим запрещающим ролям: если существуют субъект-сессия s Е S, роль или административная роль r Е R U AR, запрещающая роль nr Е NR, такие, что nr Е constraint NR(r), (s,r,reada) Е AA, то (s,nr,reada) Е AA;

— запрещающие роли могут обладать к субъект-сессиям только правом доступа владения: для запрещающей роли nr Е NR и субъект-сессии s Е S если (s,ar) Е Е PA(nr), то ar = ownr;

— запрещающие роли могут иметь к сущностям любые права доступа из множества Rr, только административные роли могут иметь к запрещающим ролям права доступа из множества Rr;

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

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

— для получения субъект-сессией любого доступа к сущности, создания «жёсткой» ссылки на неё, получения или изменения параметров, прав доступа к ней, активизации из неё субъект-сессии требуется существование последовательности непосредственно вложенных друг в друга сущностей-контейнеров, начинающейся с некоторой сущности-«корневой контейнер» (например, корневой контейнер «/» в ОССН) и заканчивающейся сущностью-контейнером, в состав которой непосредственно входит сама сущность, и наличие у субъект-сессии текущих ролей или административных ролей, обладающих в совокупности правами доступа executer ко всем сущностям-контейнерам этой последовательности, а также отсутствие у субъект-сессии запрещающей роли, обладающей правом доступа executer хотя бы к одной сущности-контейнеру этой последовательности: для состояний системы G и G', правила преобразования состояний системы op G OP, таких, что G \~op G', если s G S, e G E, (s,e,aa) G A и (s,e,aa) G A', где aa G Ra, то существует контейнер c G C и execute _container(s,c,e) = true.

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

ссылки на неё, получение её параметров):

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

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

— при изменении метки разделяемости сущности-контейнера в случае, когда субъект-сессия не имеет доступа на чтение к административной роли entities_admin_role, она не должна иметь текущую запрещающую роль, обладающую правом доступа владения к этой сущности-контейнеру;

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

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

Условие 6 (создание и удаление субъект-сессии):

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

— при удалении субъект-сессией субъект-сессии первая субъект-сессия не должна иметь текущую запрещающую роль, обладающую правом доступа владения ко второй субъект-сессии.

Условие 7 (вид метки):

— переопределяется функция direct : E U RU NRUAR ^ {true, false} и для каждой запрещающей роли вид её метки задаётся прямой: для nr G NR верно direct(nr) = = true;

— для каждой сущности с косвенной меткой существует единственная старшая её в иерархии сущность-контейнер с прямой меткой, для которой все сущности, находящиеся ниже её в иерархии, имеют косвенные метки, а права доступа всех запрещающих ролей к ним равны правам доступа к этой сущности-контейнеру: для каждой сущности e G E, такой, что direct(e) = false, существует единственная сущность-контейнер c G C, такая, что direct(c) = true, e < C и для любой сущности e' G E, такой, что e' < c, верно direct(e') = false и выполняется (e',ar) G PA(nr) тогда и только тогда, когда (c, ar) G PA(nr), где nr G NR.

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

— если для индивидуальной административной роли или индивидуальной роли учётной записи пользователя заданы запрещающие роли, то индивидуальная административная роль должна обладать административными правами доступа на чтение ко всем таким запрещающим ролям и при создании от имени этой учётной записи пользователя субъект-сессии она получает доступ на чтение ко всем соответствующим запрещающим ролям: если для учётной записи пользователя u G U выполняется nr G constraintNR(u_admin) U Uconstraint nnr(u_c), то (nr, readr) G APA(u_admin); если для субъект-сессии s G S верно nr G constraintNR(user (s) _admin)U constraint NR(user(s) _c), то (s, nr, reada) G G AA;

— если для общей роли заданы запрещающие роли, то индивидуальная административная роль каждой учётной записи пользователя должна обладать административными правами доступа на чтение ко всем таким запрещающим ролям и при создании любой субъект-сессии она получает доступ на чтение ко всем соответствующим запрещающим ролям: если выполняется nr G constraintNR(common_role), то для всех учётных записей пользователей u G U верно (nr, readr) G APA(u_admin) и для всех субъект-сессий s G S верно (s, nr, reada) G AA;

— при удалении субъект-сессии удаляются все её административные доступы к запрещающим ролям.

Рассмотрим особенности реализации в реальной защищённой ОССН условий сформулированного предположения.

Условие 1 содержит требования к запрещающим ролям и их иерархии, аналогичные требованиям к «обычным» ролям. Для создания, удаления, переименования, управления правами доступа запрещающих ролей, получения их параметров задаётся специальная административная роль negative_roles_admin_role.

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

В условии 3 основным является описание порядка использования функции необходимого обладания запрещающей ролью constraint nr, заключающегося в обязатель-

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

В условии 4 дополнительно при переопределении функции доступа к сущностям в иерархии сущностей execute_container учитывается требование отсутствия даже одной текущей запрещающей роли, обладающей правом доступа на выполнение к сущности-контейнеру, через которую соответствующая субъект-сессия делает попытку получить какой-либо доступ к сущности-

Условия 5 и 6 раскрывают содержание ограничений, которые накладываются правами доступа («запрещающими» правами доступа) запрещающих ролей при попытке осуществления субъект-сессиями соответствующих доступов к сущностям, а также при создании или удалении субъект-сессий- При этом учитывается, что наличие запрещающих ролей не накладывает ограничений на использование специальных административных ролей entities _admin_role и subjects _admin_r ole.

В условии 7 по аналогии с ролями и административными ролями определяется порядок задания прав доступа запрещающих ролей к сущностям, обладающим косвенной меткой-

Выполнение условия 8 обеспечивает возможность получения субъект-сессией заданной запрещающей роли как текущей в случае, если эта роль соответствует индивидуальной роли или индивидуальной административной роли учётной записи пользователя этой субъект-сессии- Правом доступа на чтение к такой запрещающей роли должна обладать индивидуальная административная роль учётной записи пользователя. В этом случае при создании субъект-сессии она сразу получает соответствующую запрещающую роль. Аналогично в случае, когда запрещающая роль задана для общей роли, то правом доступа на чтение к запрещающей роли должны обладать все учётные записи пользователей- Таким образом, условие обеспечивает согласованность задания значений функции необходимого обладания запрещающей ролью constraintnr с правами доступа индивидуальных административных ролей учётных записей пользователей. Кроме того, условие не указывает, какой административной роли должно быть дано право доступа на чтение к запрещающей роли, заданной для какой-то роли или административной роли. Это означает, что для того, чтобы получить эту роль или административную роль как текущую, субъект-сессии необходимо иметь право доступа на чтение к запрещающей роли через индивидуальную административную роль учётной записи пользователя субъект-сессии или через любую другую административную роль, которую как текущую должна предварительно получить субъект сессия. В противном случае субъект-сессия не сможет получить роль или административную роль как текущую.

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

ролью и активизировать из исполняемого файла новый процесс, который «наследует» от родительского и запрещающую роль.

3. Де-юре правила преобразования состояний системы и их корректность

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

Таблица

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

Параметры Исходное состояние G Результирующее состояние G'

create user(x,u)

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} U' = U U {u}, AR' = AR U {u _ admin}, PA'(u admin) = 0, direct'(u admin) = = shared container'(u admin) = true, role name'(u admin) = "u admin", H'R(u admin) = 0, R' = R U {u c}, PA'(u_ c) = 0, direct'(u_ c) = = shared container'(u c) = true, role name'(u c) = "u c", H'R(u c) = 0, APA'(admin roles admin role) = = APA(admin roles admin role) U U {(u admin, ownr)}, APA' (roles admin role) = = APA(roles admin role) U{(u c,ownr)}, для ar € AR выполняется APA'(ar) = APA(ar) U U {(u admin, executer), (u c, executer)}

APA'(u admin) = {(u admin, ar) : ar € {readr, writer,executer}} U U {(u c, ar), (common role,ar): ar € {readr,writer,executer}} U U {(r, executer) : r € R' U NR U AR'} U U {(nr, readr) : nr € constraintnr(common role)}}

access write(x,y)

x,y x € S, существует r € R U AR : (x, r, reada) € AA, [если y € E, то (y,writer) € PA(r), существует контейнер c € C, такой, что execute container(x, c,y) = true], [если y € R U AR, то (y,writer) € APA(r)] если y € E, то A' = A U {(x, y, writea)}, AA' = AA, если y € R U AR, то AA' = AA U {(x, y, writea)}, A' = A

y € E U R U NR U AR, [если y € E, то не существует запрещающей роли nr € NR, такой, что (x, nr, reada) € AA и (y,writer) € PA(nr)], [если y € NR, то (y,writer) € APA(r)]

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

Параметры

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

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

add_negative_owner(x, nr, y)

x, nr, y

x G S, y G E U S, (x, nr, writea) G AA, [существует r' G R U AR : (x,r',reada) G AA, (y,ownr) G PA(r')], [не существует запрещающей роли nr' G NR, такой, что (x,nr' ,reada) G G AA и (y,ownr) G PA(nr')], [если y G E, то direct(y) = true, существует контейнер c G C, такой, что execute _container(x,c,y) = true]

PA'(nr) = PA(nr) U {(y, ownr)}, если y Е E и He (y) = {y' Е He (y) : direct(y') = false}, то для всех y' < y верно PA'(r) = PA(r) U {(y', ownr)}

add_negative_role(x, r, nr)

x Е S, r Е (R U AR) \ SAR, nr Е NR, [не существует s Е S, такого, что (s,r,reada) Е AA], (x, negative_roles_-admin_role,reada) Е AA, [если r Е R, то (x,roles_admin_role,reada) Е AA, если r Е AR, то (x, admin_roles_-admin_role,reada) Е AA], [если существует u Е U, такая, что r Е {u_admin, u_c}, то (nr,readr) Е APA(u_admin)], [если r = common_role, то для всех u Е U ((nr,readr) Е APA(u_admin))\

constraint'NR(r) = constraintNn(r) U {nr}

create_hard_link(x, y, name, z)

x, y, name, z

x G S, y G O, z G C, [существует c G C : execute _container(x,c,y) = true], [(x, z,writea) G A, существует r G R U AR, такая, что (x, r, reada) G G AA и (z, executer) G PA(r)], name G G NAME \ ({""} U {entity_name(z, y'): y' G He(z)}), He(z) = {y' G He(z): direct(y') = direct(y)}, [если direct(y) = true, то direct(z) = true], [если direct(y) = false, то существует z' G C, такая, что direct(z) = true, y < z', z ^ z' и для всех y' < z' верно direct(y') = false]

entity_name'(z, y) = entity_name(z, y) U U {name},

HE (z) = He (z) U {y}

не существует запрещающей роли nr Е Е NR, такой, что (x,nr,reada) Е AA и (z,executer) Е PA(nr)

rename_role(x, ry, name)

x, ry, name

x Е S, name Е NAME \ ({""} U U{role_name(rz,ry') : ry',rz Е RUAR, ry' Е HR(rz)}), [если ry Е R, то (x, roles_admin_role, reada) Е AA, если ry Е AR, то (x, admin_roles_admin_role, reada)ЕAA]

для rz Е R U AR, таких, что ry Е HR(rz), выполняется role_name'(rz, ry) = name

ry G (R U NR U AR) \ (U_ADMIN U U U_ROLES U COMMON_ROLES U U SAR), name G {role_name(nr',nr'') : nr',nr''gNR}, [если ry G NR, то (x, negative_roles_admin_role, reada)GAA [для rzGR U NR U AR : ryGHR(rz), выполняется (x,rz,writea) G AA]

для rz Е NR, таких, что ry Е HR(rz), выполняется role_name'(rz, ry) = name

x, r, nr

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

Параметры Исходное состояние G Результирующее состояние G'

create first session(x,u,y, z)

x, u, y, z x € S, u € U, y € E, z € S, существует r € R U AR, такая, что (x, r, reada) € € AA и (y, executer) € PA(r), существует контейнер c C, такой, что execute container(x, c, y) = true S' = S U {z}, user'(z) = u, Hs(z) = 0, PA'(u_ c) = PA(u_ c) U {(z, ownr)}

[не существует запрещающей роли nr € NR: (x, nr, reada) € AA и (y,executer) € PA(nr)], [для всех nr € constraintnr(u admin) U U constraintnr (u c) U U constraintnr (common role) верно (nr,readr) € APA(u admin)] AA' = AA U{(z,u admin, reada), (z,u c,writea), (z, common role,writea), (z,u c,reada), (z, common role,reada)}U U{(z, nr, reada): nr € constraintnr(u admin) U U constraintnr(u c) U U constraintnr(common role)}

Всего в рамках уровня запрещающих ролей иерархического представления МРОСЛ ДП-модели задано 35 де-юре правил преобразования состояний, из которых четыре правила вида add_negative_owner(x,nr,y), remove _negative_owner(x,nr,y), add _negative _role(x, r, nr) и remove _negative_role(x, r, nr) отсутствовали на базовом уровне, так как предназначены для добавления или удаления запрещающим ролям права доступа владения к сущностям или субъект-сессиям, а также для управления множествами запрещающих ролей и административных ролей, задаваемых функцией constraintNR. При этом так же, как на базовом уровне, на текущем уровне не анализируются информационные потоки, поэтому на нём также не задаются де-факто правила преобразования состояний.

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

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

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

Де-юре правило вида add_negative_owner(x,nr,y) является новым и во многом аналогичным правилам вида grant_rights(x,r, {(y,arj) ■ 1 ^ j ^ k}), set_entity_-owner(x, r, r',y) и set_subject_owner(x,r,r',y). Оно позволяет субъект-сессии x, обладающей ролью или административной ролью, имеющей право доступа владения к сущности или субъект-сессии y, а также не обладающей запрещающей ролью, имеющей это право доступа к y, добавить запрещающей роли nr (к которой субъект-сессия x должна иметь административный доступ на запись) право доступа владения к y. При этом запрещающая роль не становится ролью-«владельцем» или ро-лью-«антивладельцем» сущности или субъект-сессии y, допускается, что запрещаю-

щих ролей, обладающих правом доступа владения к сущности или субъект-сессии, может быть несколько. С этим связано добавление этого правила на рассматриваемом уровне модели и неиспользование для этого правил вида set_entity_owner (x, r, r', y) и set_subject_owner(x, r, r',y).

Де-юре правило вида add_negative_role(x, r, nr) также является новым и позволяет субъект-сессии x добавить для роли или административной роли r запрещающую роль nr. Для этого субъект-сессия x должна обладать текущей специальной административной ролью negative_roles_admin_role, а также соответственно либо специальной административной ролью roles_admin_role, либо admin_roles_admin_role. При этом нельзя задавать запрещающие роли для любых специальных административных ролей из множества SAR и для упрощения администрирования системы ни одна субъект-сессия не должна иметь к роли или административной роли r административных доступов на чтение.

В де-юре правиле вида create_hard_link(x, y, name, z) добавлена проверка отсутствия у субъект-сессии x текущей запрещающей роли, обладающей правом доступа на выполнение к сущности-контейнеру z, в которой создаётся «жёсткая» ссылка на сущность y.

Переименование запрещающих ролей осуществляется аналогично «обычным» ролям, поэтому дополнительным условием де-юре правила вида rename _role(x, ry, name) является наличие у субъект-сессии x административного доступа на чтение к специальной административной роли negative_roles_admin_role. Требуется также исключение совпадения нового имени name с именем какой-либо запрещающей роли.

В де-юре правиле вида create _f ir st _session(x, u, y, z) дополнительно требуется отсутствие у субъект-сессии x текущей запрещающей роли, обладающей правом доступа на выполнение к сущности y, из которой активизируется новая субъект-сессия. Кроме того, чтобы создаваемая субъект-сессия z могла получить в качестве текущих все запрещающие роли для индивидуальной административной роли, индивидуальной роли её учётной записи пользователя и для общей роли, проверяется наличие права доступа на чтение ко всем таким запрещающим ролям у индивидуальной административной роли учётной записи пользователя субъект-сессии z. После применения правила созданная субъект-сессия z получает административный доступ на чтение ко всем этим запрещающим ролям.

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

Утверждение 1. Пусть G0 — начальное состояние системы T.(G*,OP,G0), удовлетворяющее условиям предположений, задающих порядок реализации ролевого управления доступом на базовом уровне и уровне запрещающих ролей (предположение 1) МРОСЛ ДП-модели. Тогда на любой траектории G0 \~opi G1 \~op2 ■ ■ ■ ^~oPN GN, где N ^ 1, состояние GN и переход GN_1 \~opN GN удовлетворяют условиям этих предположений.

Заключение

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

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

ЛИТЕРАТУРА

1. Sandhu R. Role-Based Access Control. Advanced in Computers. Academic Press, 1998. V. 46.

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

3. Буренин П. В., Девянин П. Н., Лебеденко Е. В. и др. Безопасность операционной системы специального назначения Astra Linux Special Edition: учеб. пособие для вузов / под ред. П. Н. Девянина. 2-е изд., стереотип. М.: Горячая линия — Телеком, 2016. 312 с.

4. Девянин П. Н. О результатах формирования иерархического представления МРОСЛ ДП-модели // Прикладная дискретная математика. Приложение. 2016. №9. С. 83-87.

5. www.astralinux.com — Операционные системы Astra Linux. 2017.

6. ru.wikipedia.org/wiki/Astra_Linux — Astra Linux. 2017.

7. Тележников В. Ю. Правила преобразования состояний системы в рамках ДП-модели управления доступом в компьютерных сетях, построенных на основе ОС семейства Linux // Прикладная дискретная математика. 2016. №1(31). С. 67-85.

8. Armando A. and Ranise S. Automated and efficient analysis of role-based access control with attributes // LNCS. 2012. V.7371. P. 25-40.

9. Kuijper W. and Ermolaev V. Sorting out role based access control // Proc. SACMAT'14. N.Y.: ACM, 2014. P. 63-74.

10. Девянин П. Н. Реализация невырожденной решётки уровней целостности в рамках иерархического представления МРОСЛ ДП-модели // Прикладная дискретная математика. Приложение. 2017. №10. С. 111-114.

REFERENCES

1. Sandhu R. Role-Based Access Control. Advanced in Computers, Academic Press, 1998, vol. 46.

2. Devyanin P. N. Modeli bezopasnosti kompyuternyh sistem. Upravlenie dostupom i informacionnymi potokami [Security Models of Computer Systems. Access Control and Information Flows]. Moscow, Goryachaya liniya — Telekom, 2013. 338p. (in Russian)

3. Burenin P. V., Devyanin P. N., Lebedenko E. V., et al. Bezopasnost' operacionnoy sistemy special'nogo naznacheniya Astra Linux Special Edition [Security of Operating System Astra Linux Special Edition]. Moscow, Goryachaya liniya — Telekom, 2016. 312 p. (in Russian)

4. Devyanin P. N. O rezultatah formirovaniya ierarhiceskogo predstavleniya MROSL DP-modeli [About results of design hierarchical representation of MROSL DP-model]. Prikladnaya Diskretnaya Matematika. Prilozhenie, 2016, no. 9, pp. 83-87. (in Russian)

5. www.astralinux.com — Operating System Astra Linux, 2017.

6. ru.wikipedia.org/wiki/Astra_Linux — Astra Linux, 2017.

7. Telezhnikov V. Y. Pravila preobrazovaniya sostoyaniy sistemy v ramkah DP-modeli upravleniya dostupom v komp'yuternyh setyah, postroennyh na osnove OS semeystva Linux [System state transformation rules in DP-model of access control in computer networks based on operating systems of Linux]. Prikladnaya Diskretnaya Matematika, 2016, no. 1(31), pp. 67-85. (in Russian)

8. Armando A. and Ranise S. Automated and efficient analysis of role-based access control with attributes. LNCS, 2012, vol.7371, pp.25-40.

9. Kuijper W. and Ermolaev V. Sorting out role based access control. Proc. SACMAT'14, New York, ACM, 2014, pp. 63-74.

10. Devyanin P. N. Realizaciya nevyrozhdennoy reshyotki urovney celostnosti v ramkah ierarhiceskogo predstavleniya MROSL DP-modeli [Implementation of a non-degenerate lattice integrity levels within the hierarchical representation of MROSL DP-model]. Prikladnaya Diskretnaya Matematika. Prilozhenie, 2017, no. 10, pp. 111-114. (in Russian)