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

2011 Математические основы компьютерной безопасности №1(11)

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

УДК 004.94

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

П. Н. Девянин

Институт криптографии, связи и информатики, г. Москва, Россия E-mail: peter_devyanin@hotmail.com

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

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

1. Описание модели

Существующие дискреционные, мандатные и ролевые ДП-модели [1,2] предоставляют достаточно развитые механизмы моделирования управления доступом и информационными потоками в компьютерных системах. В то же время современные операционные системы (ОС) обладают существенными особенностями (например, мандатным контролем целостности в ОС семейства Microsoft Windows), обуславливающими необходимость адаптации существующих формальных моделей для обеспечения условий анализа безопасности ОС, а реализуемые в ОС механизмы защиты достаточно сложны, что затрудняет непосредственно разработку формальной модели, детально им соответствующей. В связи с этим в работе строится ролевая ДП-модель, которую целесообразно считать промежуточным шагом на пути формирования ролевой модели управления доступом и информационными потоками в ОС, направленным на совершенствование техники формального описания данного механизма защиты. Она основана на базовой ролевой ДП-модели (БР ДП-модели) [2], ДП-модели с функционально или параметрически ассоциированными с субъектами сущностями (ФПАС ДП-модели) [3], при этом для обеспечения возможности теоретического анализа условий обеспечения целостности программной среды ОС в ней использованы элементы модели мандатной политики целостности информации Биба и модели мандатного ролевого управления доступом [2]. Построенную ДП-модель будем называть базовой ро-

хРабота выполнена при поддержке гранта МД-2.2010.10.

левой ДП-моделью управления доступом и информационными потоками в ОС (или, сокращенно, БРОС ДП-моделью).

С учетом специфики реализации управления доступом и информационными потоками в ОС сделаем предположения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S Ç E — множество субъект-сессий учетных записей пользователей;

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

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

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

AR — множество административных ролей (AR П R = 0);

] r[ С E \ S — множество сущностей, параметрически ассоциированных с ролью или административной ролью r G R U AR;

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

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

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

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

P Ç E х Rr — множеств прав доступа к сущностям;

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

F Ç E х E х Rf — множество информационных потоков;

UA : U ^ 2r — функция авторизованных ролей учетных записей пользователей;

AUA : U ^ 2ar — функция авторизованных административных ролей учетных записей пользователей;

PA : R ^ 2Р — функция прав доступа ролей;

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

roles : S ^ 2r U 2ar — функция текущих ролей субъект-сессий;

can_manage_rights : AR ^ 2r — функция администрирования прав доступа ролей;

[s] С E U U — множество сущностей, функционально ассоциированных с субъект-сессией s (при этом по определению выполняется условие s G [s]), и учетных записей

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

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

] s [ С E \ S — множество сущностей, параметрически ассоциированных с субъект-сессией s Е S;

fp : U х E ^ 2е — функция, задающая множества сущностей, параметрически ассоциированных с субъект-сессией при ее создании из сущности от имени учетной записи пользователя. По определению выполняется условие: для каждой субъект-сессии s Е S существует единственная сущность es Е E, такая, что справедливы равенства fp(user(s),es) = ]s[ и fa(user(s),es) = [s];

He : E ^ 2е — функция иерархии сущностей;

Hr : R ^ 2r — функция иерархии ролей;

Har : AR ^ 2ar — функция иерархии административных ролей.

Определение 1. Доверенную субъект-сессию y назовем функционально корректной, когда во множество функционально ассоциированных с ней сущностей [y] не входят недоверенные субъект-сессии.

Определение 2. Доверенную субъект-сессию y назовем функционально корректной относительно доверенной субъект-сессии y1 и сущности e, когда субъект-сессия y не реализует информационный поток по памяти от сущности e к некоторой сущности e!, функционально ассоциированной с доверенной субъект-сессией y1. При этом используем обозначение yf (E) С Ls х E — множество пар вида (доверенная субъект-сессия, сущность), относительно которых функционально корректна доверенная субъект-сессия y.

Определение 3. Доверенную субъект-сессию y назовем параметрически корректной относительно доверенной субъект-сессии y' и сущности e, когда субъект-сессия y не реализует информационный поток по памяти к сущности e от некоторой сущности e', параметрически ассоциированной с доверенной субъект-сессией y'. При этом используем обозначение yp(E) С Ls х E — множество пар вида (доверенная субъект-сессия, сущность), относительно которых параметрически корректна доверенная субъект-сессия y.

Определение 4. Доверенную субъект-сессию назовем корректной относительно информационных потоков по времени, когда она не участвует в их реализации. При этом используем обозначения: LFs С Ls — множество доверенных субъект-сессий, корректных относительно информационных потоков по времени; NFs С Ls — множество доверенных субъект-сессий, некорректных относительно информационных потоков по времени, при этом по определению справедливы равенства LFs П NFs = 0, LFs U NFs = Ls.

В ОС семейств Microsoft Windows Vista/7/2008 реализуется механизм мандатного контроля целостности (MIC — Mandatory Integrity Control), предназначенный для обеспечения контроля целостности программной среды ОС. Данный механизм является перспективным и эффективным средством повышения безопасности управления доступом и информационными потоками в ОС. Таким образом, целесообразно, помимо ролевого управления доступом, при построении БРОС ДП-модели включить в нее элементы, позволяющие анализировать механизм мандатного контроля целостности. При этом без ограничения общности можно рассматривать только два уровня целостности,

предоставляющие возможность обеспечить целостность доверенных субъект-сессий системы. Также имеет смысл учесть наличие в ОС специального механизма защиты от несанкционированного повышения уровней целостности процессов (например, механизм User Account Control — UAC в ОС семейств Microsoft Windows Vista/7/2008). Данный механизм предусматривает выполнение специальных процедур для активизации процессов или получения доступа к сущностям с высоким уровнем целостности. Используем следующие обозначения:

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

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

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

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

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

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

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

Определение 5. Доверенную субъект-сессию y назовем корректной в смысле целостности относительно сущности e, обладающей высоким уровнем целостности i_high, если субъект-сессия y не реализует информационный поток по памяти к сущности e от некоторой сущности e!, обладающей низким уровнем целостности i_low. При этом используем обозначение yi(E) С E — множество сущностей, относительно которых корректна в смысле целостности доверенная субъект-сессия y.

В рамках БРОС ДП-модели определим состояние системы.

Определение 6. Пусть определены:

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

— функции авторизованных ролей учетных записей пользователей UA, авторизованных административных ролей учетных записей пользователей AUA, прав доступа ролей PA, принадлежности субъект-сессий учетным записям пользователей user, текущих ролей субъект-сессий roles, уровней целостности (iu,ie,ir,is), иерархии ролей Hr, иерархии административных ролей Har, иерархии сущностей He.

Определим G = (UA, AUA, PA, user, roles, (iu, ie,ir,is),A, F, Hr, Har, He,Lj, LS) — состояние системы.

Заметим, что, так же как в БР ДП-модели, механизм статических и динамических ограничений рассматриваться не будет.

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

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

G \~ap G' — переход системы T,(G*, OP) из состояния G в состояние G' с использованием правила преобразования состояний op Е OP;

T,(G*, OP, G0) — система T,(G*, OP) с начальным состоянием G0.

В существующих компьютерных системах, в том числе в ОС, параметры системы управления доступом (списки прав доступа к файлам, списки прав доступа или привилегий пользователей или ролей), как правило, достаточно надежно защищены. Возможность изменения этих параметров нарушителем часто является следствием преодоления (взлома) им системы защиты. Кроме того, уровень целостности процессов ОС, например в ОС семейств Microsoft Windows Vista/7/2008, устанавливается только при их активизации. При необходимости повышения уровня целостности процесса осуществляется его перезапуск. Таким образом, в первую очередь усилия нарушителя могут быть направлены на несанкционированное повышение им своих полномочий (в том числе, уровня целостности) за счет получения контроля над доверенными процессами ОС. С учетом сказанного в рамках БРОС ДП-модели можно не рассматривать действия по администрированию параметров целостности системы, задаваемых функциями (iu,ie,ir,is). Таким образом, по аналогии с БР ДП-моделью используем следующие предположения, при этом дополним предположение 2.

Предположение 6. В рамках БРОС ДП-модели на траекториях функционирования системы не изменяются: значения множеств U, Lu, R, функции UA, AUA, Hr, Har, iu, ir и значения множеств сущностей, параметрически ассоциированных с каждой ролью или административной ролью. Новые значения для функций ie и is задаются только при создании соответствующих новых сущностей или субъект-сессий. Таким образом, будем использовать следующее сокращенное обозначение для состояния системы: G = (PA, user, roles, A, F, He).

Предположение 7. Уровень целостности роли не превосходит уровней целостности ролей, которым она подчинена в иерархии ролей. Уровень целостности сущности, входящей в состав сущности-контейнера и не являющейся субъект-сессией, не превосходит уровня целостности сущности-контейнера. Уровни целостности сущностей, параметрически ассоциированных с учетной записью пользователя, совпадают с ее уровнем целостности. Текущий уровень целостности субъект-сессии не превосходит уровня целостности учетной записи пользователя, от имени которой она функционирует, и текущего уровня субъект-сессии, которой она подчинена в иерархии. Уровень целостности роли не может быть выше уровня целостности учетной записи пользователя, которая на нее может быть авторизована, и текущего уровня целостности субъект-сессии, во множество текущих ролей которой она входит. Права доступа владения ownr, на запись writer и запись в конец appendr к сущности, не являющейся субъект-сессией, могут принадлежать только ролям, имеющим уровень целостности не ниже, чем уровень целостности сущности. Право доступа владения ownr к субъект-сессии может принадлежать только ролям, имеющим уровень целостности не ниже, чем уровень целостности субъект-сессии. Таким образом, выполняются условия:

— для ролей r,r' Е R U AR: если r ^ r', то ir(r) ^ ir(r');

— для сущностей e,e' Е E \ S: если e ^ e', то ie(e) ^ ie(e');

— для субъект-сессий s, s' Е S: если s ^ s', то is(s) ^ is(s');

— для каждой сущности e Е ]u[, где u Е U, справедливо равенство ie(e) = iu(u);

— для субъект-сессии s Е S верно неравенство is(s) ^ iu(user(s));

— для учетной записи пользователя u Е U и роли r Е R: если r Е UA(u), то

ir(r) ^ iu(u);

— для субъект-сессии s Е S и роли r Е R: если r Е roles(s), то ir(r) ^ is(s);

— для права доступа к сущности (e,a) G P, где a G {ownr,writer,appendr}, и роли r G R: если (e, a) G PA(r), то или e G E \ S и ie(e) ^ ir(r), или e G S, a = ownr и is(e~) ^ ir(r).

Предположение 8. Учетные записи доверенных субъект-сессий имеют высокий уровень целостности i_high, а недоверенных субъект-сессий — низкий i_low. Во множестве сущностей имеется сущность i_entity G E, обладающая высоким уровнем целостности, реализация информационного потока по памяти к которой от субъект-сессии является необходимым (в дополнение, в том числе, к требованиям предположения 2) в следующих случаях:

— когда субъект-сессия создает новую субъект-сессию с высоким уровнем целостности;

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

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

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

Таким образом, выполняются условия:

— для учетной записи доверенного пользователя u G Lj верно равенство iu(u) = = i_high;

— для учетной записи недоверенного пользователя u G Nj верно равенство iu(u) = = i_low;

— верно равенство ie(i_entity) = i_high.

Предположение 9. Субъект-сессии могут иметь друг к другу только доступ владения owna. Роли могут обладать к субъект-сессиям только правом доступа владения ownr. Таким образом, для каждой роли r G R во множестве ее прав доступа PA(r) отсутствуют права доступа вида (s,a), где s G S и a = ownr.

Предположение 10. Если субъект-сессия s реализовала информационный поток по памяти от себя к сущности, функционально ассоциированной с другой субъект-сессией s', или субъект-сессия s реализовала информационный поток по памяти к себе от всех сущностей, параметрически ассоциированных с другой субъект-сессией s', то субъект-сессия s получает доступ владения owna к субъект-сессии s'.

Предположение 11. Если субъект-сессия s имеет доступ владения owna к субъект-сессии s', то субъект-сессия s получает следующие возможности:

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

— изменять множество текущих ролей субъект-сессии s';

— использовать текущий уровень целостности субъект-сессии s';

— использовать доступы субъект-сессии s';

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

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

— использовать информационные потоки, в реализации которых участвует субъект-сессия s'.

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

de_facto_roles : S ^ 2RuAR — функция фактических текущих ролей субъект-сессий, при этом по определению в каждом состоянии системы G = (PA,user, roles, A,

F, Не) для каждой субъект-сессии s Е S верно равенство

de_facto_roles(s\) = roles(s) U{rЕRU AR: существует s^S, такая, что (s,s',owna)ЕA и rЕroles(s')};

de_facto_rights : S ^ 2P — функция фактических текущих прав доступа субъект-сессий, при этом по определению в каждом состоянии системы G = (PA, user, roles, A, F, He) для каждой субъект-сессии s Е S верно равенство

de_facto_rights(s) = {pЕP: существует rЕde_facto_roles(s), такая, что pЕPA(r)};

de_facto_accesses : S ^ 2A — функция фактических доступов субъект-сессий, при этом по определению в каждом состоянии системы G = (PA, user, roles, A, F, He) для каждой субъект-сессии s Е S верно равенство

de_facto_accesses(s) = {(s,e,aa) : (s,e,aa)ЕA}U{(s',e,aa) : (s,s',owna), (s',e,aa)ЕA};

de_facto_actions : S ^ S х U х 2P х 2R — функция фактических возможных действий субъект-сессий, при этом по определению в каждом состоянии системы G = (PA, user, roles, A, F, He) для каждой субъект-сессии s Е S верно равенство de _ facto _actions(s) = ({s} х {user(s)} х PA(roles(s)) х can _manage _rights(roles(s) П nAR)) U {(s',u', PA(roles(s')),can_manage_rights(roles(s') П AR)) : (s,s',owna) Е A, либо u' = 0, либо u' = user(s') и для каждой сущности e Е ]u'[ выполняется условие (e, s, writem) Е F}.

Определение 7. Будем говорить, что субъект-сессия s фактически обладает ролью r, когда она принадлежит множеству de_facto_roles(s). При этом роль r будем называть фактической ролью субъект-сессии s. Права доступа из множества de_facto_rights(s) будем называть фактическими текущими правами доступа субъект-сессии s. Доступы из множества de_facto_accesses(s) будем называть фактическими доступами субъект-сессии s.

Заметим, что фактические доступы субъект-сессий в рамках БР ДП-модели не рассматривались.

Определение 8. Будем говорить, что субъект-сессия s обладает фактической возможностью осуществить от имени субъект-сессии s' (с учетной записью пользователя u') действие над сущностью y и ролью r с применением права доступа ar, когда выполняется условие (s',u', (y,ar),r) Е de_f acto_actions(s). При этом в случае, когда выполняется условие (s', 0, 0, 0) Е de_facto_actions(s), будем говорить, что субъект-сессия s обладает фактическим текущим уровнем целостности is(s').

В случае, когда для осуществления субъект-сессией s от имени субъект-сессии s' действия над сущностью y и ролью r с применением права доступа ar не требуется наличия информационных потоков по памяти от всех сущностей e Е ]user(s') [, может быть достаточным выполнение условия (s', 0, (y, ar), r) Е de_f acto_actions(s).

2. Правила преобразования состояний

В рамках БРОС ДП-модели используются правила преобразования состояний из множества OP, приведенные в следующей таблице.

Правила преобразования состояний БРОС ДП-модели

Правило Исходное состояние G = (PA, user, roles, A, F, He) Результирующее состояние G' = (PA', user', roles', A', F', H'E)

1 2 3

take role(x,w,r) x,w G S, (w,user(w), 0, 0) € G de facto actions(x), rGU A(user(w))UAU A(user(w)), для e G ]r[ выполняется условие (e, x, writem) G F, ir (r) ^ is(w), и если ir (r) = i high, то (x,i entity, writem) G F S' = S, E' = E, PA' = PA, user' = user, A' = A, F' = F, H'E = HE, roles'(w) = roles(w) U {r} и для s G S \ {w} выполняется равенство roles'(s) = roles(s), если x G (NS U NFS) П S, то F' = F U {(x, s, writet): s G (NsUNFs) П S, x = s и или s = w, или (w, owna) G de facto accesses(s)}, если x G LFS П S, то F' = F

remove role(x, w, r) x, w G S, r G roles(w), (w,user(w), 0,0) G de facto actions (x), для e G]r[ выполняется условие (e, x, writem) G F, и если ir (r) = i high, то (x, i entity, writem) G F S' = S, E' = E, PA' = PA, user' = user, A' = A, F' = F, HE' = HE, roles'(w) = roles(w) \ {r} и для s G S \ {w} выполняется равенство roles'(s) = roles(s), если x G (Ns U NFs) П S, то F' = F U {(x, s, writet): s G (Ns U NFs ) П S, x = s и или s = w, или (w, owna) G de facto accesses(s)}, если x G LFS П S, то F' = F

grant right(x,r, (y, ar)) x G S, y G E, (y,ar ) G P, (w, 0, (y,ownr),r) G de facto actions(x), ir(r) ^ is(w), если y G S, то ar = ownr и is(y)^ir(r); если yGE\S и arG{ownr,writer,appendr}, то ie(y)<ir(r); если ie(y)=i_ high, то (x, i entity, writem) G F S' = S, E' = E, user' = user, roles' = roles, A' = A,H'e = He, PA'(r) = PA(r) U {(y, ar)}, и для r' G R \ {r} выполняется равенство PA'(r') = PA(r'), если xg(NsUNFs^S, то F' = F U {(x, s, writet) : s G (Ns U NFs) П S, x = s и r G de facto roles(s)}, если x G LFS П S, то F' = F

remove right(x, r, (У, ar)) xGS, yGE, (y, ar)GPA(r) и (w, 0, (y,ownr),r)Gde facto -actions(x), ir(r) ^ is(w), и если ie(y) = i high, то (x, i entity, writem) G F S' = S, E' = E, user' = user, roles' = roles, A' = A, HE' = HE, PA'(r) = PA(r) \ {(y, ar)}, и для r' G R \ {r} выполняется равенство PA'(r') = PA(r'), если x G (Ns U NFs) П S, то F' = F U {(x, s, writet): s G (Ns U NFs) П S, x = s и r G de facto roles(s)}, если x G LFS П S, то F' = F

create entity (x, r, y, yi, z) x G S, yGE, z G E \ S, (w, 0, (z,ar),r) G de facto -actions (x), где ar G {writer, appendr}, ir(r) ^ is(w), ie(z) < is(w), yi < ie(z), yi ^ ir(r), если ie(z) = i high, то (x,i entity, writem) G F S' = S, E ' = E U {y}, при этом y GUE U RE, user' = user, roles' = roles, A' = A, i'e (У)=Уi, HE (z) = HE (z) U {y} HE (y) = 0, для e G E \ {z} выполняется равенство H'E(e) = He (e), PA'(r) = PA(r) U {(y, ownr )}, и для r' G R \ {r} выполняется равенство PA'(r') = PA(r'), если xg(NsUNFs^S, то F' = F U {(x, e,writet) : e G E и y ^ e}U U{(x, s, writet) : s G (Ns U NFs) П S, x = s и r G de facto roles(s)}, если x G LFS П S, то F' = F

rename entity(x, y, z) x G S, y, z G E \ S, y G He(z), (w, 0, (z,ar),r) G de facto -actions (x), где ar G {writer, appendr}, ir(r) ^ is(w), ie(z) ^ ^ is(w), если ie(z) = i high, то (x, i entity, writem) G F S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'E = HE, если x G (Ns U NFs) П S, то F' = F U U{(x, e, writet) : e G E,x = e,e ^ z}U U{(x, s,writet) : s G (Ns U NFs) П S,x = s, (e,aa) G de facto accesses(s), где e G E, e ^ y, aa G Ra}, если x G LFS П S, то F' = F

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

1 2 3

delete entity (x, y, z) x G S, y, z G E\S, y G He (z), {eGE : e < y}n(UEURE) = 0, (w, 0, (z,writer),r) G de facto actions(x) и ir (r)^is(w), ie(z)^is(w), если ie(z) = i high, то (x,i entity, writem) G F S' = S, E' = E \ {eGE: e ^ y}, user' = user, roles' = roles, H'E (z) = He (z) \ {y}, для всех eGE' \ {z} выполняется равенство H'E (e) = He (e), для r R выполняется равенство PA'(r) = PA(r) \ {(e, ar): e ^ y, ar G Rr}, A' = A \ {(s, e, aa): s G S, eGE, e ^ y, aa G Ra}, если x G (Ns U NFs) П S, то F' = (F U {(x, e, writet) : e G E,x = ez ^ e}U U{(x, s, writet) : s G (Ns U NFs) П S', x = s и (e, aa ) G de facto accesses(s), где eGE, e < y и aa G Ra}) \ ({(e, e', af): e, e' G E, e' ^ y, af G Rf} U {(e', e, af): e, e' G E, e' < y, af G Rf}), если x G LFS П S, то F' = F

create first session(x, u, r, y, z, zi) x G S, u G U, y G E, z G E, (y,executer) G PA(UA(u)) и r G can manage -rights (AU A(u)), zi ^ iu(u), zi ^ ir(r), {(e,x,writem) : e G]u[} С F, если zi = i high, то (x, i entity, writem) G F S' = S U {z}, E' = E U {z}, A' = A, i's(z) = zi, user' (z) = u, roles'(z) = 0, для s S выполняются равенства user' (s) = user(s), roles'(s) = roles(s), [z] = fa(u, y), ]z[= fp(u,y), HE (z) = 0, для eGE выполняется равенство H'E (e) = He (e), PA'(r) = PA(r)U{(z, ownr)}, и для r' G R\{r} выполняется равенство PA'(r') = PA(r'), если x G (Ns U NFs) П S, то F' = FU U{(z, x, writet), (x, z, writet)} U {(x, e, writet) : eGE и y ^ e}U {(x, s,writet) : s G (NsU UNFs) П S, x = s и r G de facto roles(s)}, если x G LFS П S, то F' = F

create session(x, w, r, y, z, zi) x,w G S, y G E, z G E, (w, 0, (y,executer),r)G de facto actions (x), zi ^ ir(r) ^ is(w) S' = S U {z}, E' = E U {z}, A' = A, i's(z) = zi, user'(z) = user(w), roles'(z) = 0, для s S выполняются равенства user' (s) = user(s), roles'(s) = roles(s), [z] = fa(user(w),y), ]z[= fp(user(w),y), H'E (w) = He (w) U {z}, HE (z) = 0, для eGE \ {w} выполняется равенство H'E (e) = = HE(e), PA'(r) = PA(r) U {(z, ownr)}, и для r' R \ {r} выполняется равенство PA'(r')=PA(r'), если xg(Ns U NFs) П S, то F' = F U {(z,x,writet), (x, z,writet)}U U{(x, e, writet) : e G E и y^e} U {(x, s, writet) : s G (Ns U NFs) П S,x = s и r G de facto roles(s)}, если x G LFS П S, то F' = F

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

1 2 3

delete session(x, w, z) x, w, z S, (w, 0, (z,ownr), 0) G de facto actions (x) S' = S\{z}, E' = E\{z}, для s G S' выполняются равенства user'(s) = user(s), roles'(s) = = roles(s), для z' G S, такого, что z G He (z'), справедливо равенство HE' (z') = (HE(z') \ \{z}) U He (z), при этом выполняется условие: для e G E' \ {z'} выполняется равенство H'e(e) = HE(e), PA'(r) = PA(r) \ {(z, ownr)}, и для r' R \ {r} выполняется равенство PA'(r') = PA(r'), A' = A \ ({(z, e, aa): e G E, aa G Ra} U {(s, z, owna): s G S}), если x G (Ns U NFs ) П S, то F' = (F U U{(x, s,writet) : e G E, x = e и z<e}U u{(x, s, writet) : s G (Ns U NFs) П S, x = s и (z,owna) G de facto accesses(s)})\ \({(z, e, a.f ) : e G E, af G Rf} U {(e, z, af ): e G E, af G Rf}), если x G LFS П S, то F' = F

control(x, y, z) x, y G S, x = y, z G [y] и или x = z, или (x, z, writem) G F, или z G S и (x, z, owna) G A S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(x, y, owna)}, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e и y ^ e}, если x G LFS П S, то F' = F

know(x, y) x, y G S, x = y, и для каждой e G ]y[ существует (e, x, writem) G F S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(x, y, owna)}, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e и y ^ e}, если x G LFS П S, то F' = F

take access own(x, y, z) x, y, z G S, x = z, {(x, y, owna), (y, z, owna)} С A S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(x, z, owna)}, если x G (Ns U NFs) П S, то F' = F U {(x, e, writet): e G E, x = e и z ^ e}, если x G LFS П S, то F' = F

access own(x, w, y) x, w, y S, w = y, (w, 0, (y,ownr), 0) G de facto actions (x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(w, y, owna)}, если x G (Ns U NFs) П S, то F' = F U U{(x, e,writet) : e G E,x = e и y ^ e}U U{(x, s,writet) : s G (Ns U NFs) П S, x = s и (y,owna) G de facto accesses (s)}, если x G LFS П S, то F' = F

access read(x, w, y) x,w G S, y G E \ S, (w, 0, (y,readr), 0) G de facto actions (x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(w, y, reada)}, если x G (Ns U NFs) П S, то F' = F U {(y, w, writem)} U {(x, e, writet): e G E, x = e и y < eL если x G LFS П S, то F' = F U {(y, w, writem)}

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

1 2 3

access write(x, w, y) x, w S, y E \ S, (w, 0, (y,writer), 0) G de facto actions(x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(w, y, writea)}, если x G (Ns U NFs) П S, то F' = F U {(w, y, writem)} U {(x, e, writet): e G E, x = e и y < e} если x G LFS П S, то F' = F U {(w, y, writem)}

access append(x, w, y) x, w S, y E \ S, (w, 0, (y, appendr), 0) G de -facto actions(x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE' = HE, A' = A U {(w, y, appenda)}, если x G (Ns U NFs) П S, то F' = F U {(w, y, writem)} U {(x, e, writet): e G E, x = e и y < e} если x G LFS П S, то F' = F U {(w, y, writem)}

flow(x, y, y', z) x,z G S, y,y' G E, x = z, y ^ y', [или x = y, или (y, aa) G de facto accesses (x)], [или z = s', или (y',ßa) G G de facto accesses (z)], где aa, ßa G Ra S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE' = HE, если x, z G (Ns U NFs) П S, то F' = F U {(x, z, writet), (z, x, writet)}, если {x,z} П LFS П S) = 0, то F' = F

find(x, y, z) x, y S, z E, x = z, (x,y,a) G F, где a G {writem, writet}, и [или (z,ß) G de facto accesses(y), где ß G {writea, appenda}], [или (y,z,ß) G F, где ß G {writem, writet}\ S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE' = HE, если writet G {a, в}, то F' = F U {(x, z, writem)}, если writet G {a, в} и x, y G (Ns U NFs) П S, то F' = F U {(x, z, writet)}, если writet G {a, в} и {x, y} П (LFS П S) = 0, то F' = F

post(x, y, z) x, z S, y E, x = z, (y,reada) G de facto accessess(z) и [или (y,a) G de facto accesses (x), где a G {writea,appenda}], [или (x,y,a) G F, где a G {writem, writet}] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'E = HE, если a = writet, то F' = F U {(x, z, writem)}, если a = writet и x, z G (Ns U NFs) П S, то F' = F U {(x, z, writet)}, если a = writet и {x, z} П (LFs П S) = 0, то F' = F

pass(x, y, z) y S, x, z E, x = z, (x,reada ) G de facto accessess (y) и [или (z,a) G de facto accesses (y), где a G {writea,appenda}], [или (y,z,a) G F, где a G {writem, writet}] S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'E = He, если a = writet, то F' = F U {(x, z, writem)}, если a = writet и y G (Ns U NFs ) П S, то F' = F U {(x, z, writet)}, если a = writet и y G LFs П S то F' = F

take flow(x, y) x,y G S,x = y, (x, y, owna) G A S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, H'E = He, если x G (Ns U NFs) П S, то F' = F U {(x, e, a): (y, e, a) G F, e G E, a G {writem, writet}}, если x G LFs П S, то F' = F U {(x, e, writem): (y, e, writem) G F, e G E}

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

Рис. 1. Зависимость условий и результатов применения правил преобразования состояний БРОС ДП-модели

Правила take_role(x,w,r) и remove_role(x,w, r) позволяют субъект-сессии х добавить (удалить) роль r, на которую субъект-сессия может быть авторизована, либо в множество своих текущих ролей, либо, при наличии доступа владения к другой субъект-сессии w, в множество её текущих ролей. При этом в соответствии с предположением 7 при добавлении роли необходимо, чтобы ее уровень целостности не превосходил текущего уровня целостности субъект-сессии, которая ее получает. Таким образом, если в БР ДП-модели предполагалось, что изменять множество текущих ролей субъект-сессии может только сама субъект-сессия, то в рамках БРОС ДП-модели в соответствии с предположением 11 субъект-сессия может изменять множество своих фактических ролей. Для этого требуется, чтобы субъект-сессия х, получившая контроль над субъект-сессией w, реализовала к себе информационные потоки по памяти от всех сущностей учетной записи пользователя субъект-сессии w; в случае, когда

уровень целостности роли r равняется i_high, в соответствии с предположением 8 требуется реализация субъект-сессией x информационного потока по памяти от себя

к сущности i__entity. Также при добавлении или удалении роли дополнительно (по

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

Правила grant _right(x,r, (y,ar)) и remove _right(x,r, (y,ar)) позволяют субъект-сессии x добавить или удалить соответственно право доступа ar к сущности у из множества прав доступа роли r. В соответствии с предположением 11 для применения правил необходимо наличие у субъект-сессии x фактической возможности осуществить действие над сущностью у и ролью r с применением права доступа владения ownr. Кроме того, в соответствии с предположением 7 для применения правил требуется, чтобы уровень целостности роли не превосходил текущего уровня целостности субъект-сессии, от имени которой добавляется или удаляется право доступа. Если осуществляется добавление права доступа ownr, writer или appendr к сущности, то требуется, чтобы уровень целостности сущности у (если у является субъект-сессией, то текущий уровень целостности y) не превосходил уровня целостности роли r. При этом в случае, когда уровень целостности сущности у равняется i_high, в соответствии с предположением 8 требуется реализация субъект-сессией x информационного потока по памяти от себя к сущности i_entity. Так как добавление или удаление права доступа из множества прав доступа роли r может быть использовано для передачи данных, то в результате применения правил могут возникнуть информационные потоки по времени от субъект-сессии x к субъект-сессиям, фактически обладающим ролью r.

Правила create_entity(x,r, у, yi,z), rename_entity(x, у, z) и delete_entity(x, у, z) позволяют субъект-сессии x создать, переименовать или удалить соответственно сущность y, не являющуюся субъект-сессией и входящую в состав контейнера z. При этом нельзя удалять или создавать сущности, входящие в состав учетных записей пользователей, или сущности, параметрически ассоциированные с ролями, и в отличие от БР ДП-модели для применения правил в соответствии с предположением 7 требуется, чтобы уровень целостности роли, используемой для создания, переименования или удаления сущности, и уровень целостности сущности-контейнера z, в котором содержится сущность у, не превосходили текущего уровня целостности субъект-сессии, от имени которой данные действия осуществляются. Если выполняется создание, переименование или удаление сущности у с уровнем целостности i_high, то в соответствии с предположением 8 требуется реализация субъект-сессией x информационного потока по памяти от себя к сущности i_entity. Кроме того, в соответствии с предположением 7 при создании сущности требуется, чтобы уровень целостности yi сущности у не превосходил уровня целостности сущности-контейнера z и уровня целостности роли r, которая получает право доступа владения к сущности у. Также следует заметить, что при применении правил rename_entity(x, у, z) или delete_entity(x, у, z) возникают информационные потоки по времени от субъект-сессии x к субъект-сессиям, имеющим текущие фактические доступы (а не фактические текущие права доступа, как в БР ДП-модели) к сущностям, подчиненным в иерархии сущности у.

Правило create_first_session(x, u, r, y, z, zi) позволяет субъект-сессии x с использованием сущности у и учетной записи пользователя u создать от имени u новую субъект-сессию z с текущим уровнем целостности zi (в БР ДП-модели создание субъект-сессии осуществлял пользователь u). При этом в соответствии с предположением 2 для применения правила необходима реализация субъект-сессией x к себе информационных потоков по памяти от всех сущностей, параметрически ассоциированных с учетной записью пользователя u. Кроме того, в соответствии с предположением 7 требуется, чтобы текущий уровень целостности zi создаваемой субъект-сессии z не превосходил уровня целостности учетной записи пользователя u и уровня целостности роли г, которая получает право доступа владения к субъект-сессии z. Однако уровень целостности субъект-сессии z может превосходить уровень целостности субъект-сессии х, что соответствует подходу, реализованному, например, в ОС семейств Microsoft Windows Vista/7/2008. В случае, когда субъект-сессия z создается с уровнем целостности i_high, в соответствии с предположением 8 требуется реализация субъект-сессией х информационного потока по памяти от себя к сущности i_entity.

Правила create_session(x,w,r,y,z, zi) и delete_session(x,w, z) позволяют субъект-сессии x непосредственно либо от имени субъект-сессии w, к которой субъект-сессия x имеет доступ владения, создать или удалить соответственно субъект-сессию z. При этом в соответствии с предположением 7 требуется, чтобы текущий уровень целостности zi субъект-сессии z не превосходил уровня целостности роли r, получающей право доступа владения к субъект-сессии z, который, в свою очередь, не должен превосходить текущего уровня целостности субъект-сессии w, осуществляющей создание субъект-сессии z. Правило delete_session(x, w, z) не рассматривалось в БР ДП-модели (кроме того, в дискреционных или мандатных ДП-моделях также отсутствовало правило удаления субъектов), для удаления субъект-сессий в этой модели использовалось правило удаления сущностей delete_entity(x,y, z). Условия применения правила delete_session(x,w, z) позволяют учесть, что удаление субъект-сессии z может быть осуществлено субъект-сессией x от имени субъект-сессии w, обладающей правом доступа владения к субъект-сессии z.

Правила control(x,y,z) и know(x,y) в рамках предположений 3 и 4 позволяют субъект-сессии x получить доступ владения к субъект-сессии y с использованием соответственно либо информационного потока по памяти от себя к сущности z, функционально ассоциированной с субъект-сессией y, либо информационных потоков по памяти к себе от всех сущностей, параметрически ассоциированных с субъект-сессией y. Параметрически ассоциированные сущности и правило know(x,y) не рассматривались в БР ДП-модели (они анализировались в дискреционных ФПАС и ФС ДП-моделях [3, 4]).

Условия и результаты применения правила take_access_own(x, y,z) не изменились по сравнению с БР ДП-моделью. Оно позволяет субъект-сессии x получить доступ владения к субъект-сессии z (при этом требуется, чтобы субъект-сессия x обладала доступом владения к субъект-сессии y, имеющей, в свою очередь, доступ владения к субъект-сессии z).

Правила access_own(x,w,y), access_read(x,w,y), access_write(x,w,y) и access_-append(x, w, y) позволяют субъект-сессии x, обладающей фактической возможностью осуществить от имени субъект-сессии w с соответствующим правом доступа действие над сущностью y, либо получить самой (когда x = w), либо инициировать получение субъект-сессией w соответствующего доступа к сущности y. Данные правила отличаются от аналогичных правил БР ДП-модели тем, что субъект-сессия x не непосред-

ственно сама получает доступ к сущности y, а это делает субъект-сессия w, доступ владения к которой имеет субъект-сессия x.

Правила flow(x,y,y', z), find(x,y,z), post(x,y, z), pass(x,y, z) и take_flow(x,y) позволяют субъект-сессиям создавать информационные потоки по памяти или по времени. Отличие условий применения данных правил от их аналогов в БР ДП-модели заключается в том, что вместо обладания фактическими текущими правами доступа для реализации информационных потоков от субъект-сессий требуется наличие соответ-ствуютттих фактических доступов. Кроме того, при применении правила flow(x, y, y', z) для создания информационных потоков по времени допускаются равенства x = y или

y' = z.

3. Монотонные и немонотонные правила преобразования состояний

По аналогии с дискреционными и мандатными ДП-моделями, а также с БР ДП-моделью дадим определение.

Определение 9. Монотонное правило преобразования состояний — это правило преобразования состояний из множества OP, применение которого не приводит к удалению из состояний

— ролей из множества текущих ролей субъект-сессий;

— прав доступа ролей к сущностям;

— субъект-сессий или сущностей;

— доступов субъект-сессий к сущностям;

— информационных потоков.

По определению 9 и в соответствии с условиями и результатами применения правил преобразования состояний, заданных в таблице, монотонными являются следующие правила: take_role(x,w,r), grant_right(x,r, (y,ar)), create_entity(x,r,y,yi, z), rename_entity(x, y, z), create_first_session(x, u,r,y, z, zi), create_session(x, w,r,y, z,zi), control(x,y, z), know(x,y), take_access_own(x,y,z), access_own(x,w,y), access _read(x, w, y), access_write(x, w, y), access _append(x, w, y), flow(x, y, y', z), find(x, y,z), post(x,y, z), pass(x,y,z) и take_flow(x,y). Немонотонными правилами преобразования состояний являются remove_role(x,w,r), remove_right(x,r, (y,ar)), delete_-entity(x, y, z), delete_session(x, w, z).

Поскольку в рамках БРОС ДП-модели условия и результаты применения правил преобразования состояний по сравнению с БР ДП-моделью претерпели существенные изменения, целесообразно обосновать следующее утверждение.

Утверждение 1. Пусть G0 = (PA0,user0,roles0, A0, F0, HEo) —начальное состояние системы E(G*, OP, Go). Пусть также существуют состояния системы Gi, ..., GN = (PAn,userN, rolesN, An, Fn, HEn) и правила преобразования состояний op1, ... , opN, такие, что G0 \~ор1 G1 \~op2 ■ ■ ■ ^opN Gn , где N ^ 0. Тогда существуют состояния Gi, ... , G'M = (PA'M,user'M,roles'M, A'M, F'M, H'Em), где M ^ 0, и монотонные правила преобразования состояний opi, ..., op'M, такие, что G0 \~op^ Gi \~op>2 ■■■ ^op'M G'M, и

выполняются следующие условия.

1. Верно включение Sn С S'm и для каждой субъект-сессии s G Sn выполняются условия: userN(s) = user'M(s), rolesN(s) С roles'M(s)■

2. Верно включение En С E'M, для каждой сущности e G En \ Sn , не являющейся субъектом, выполняется условие HEn(e) С H'Em(e), и для любых сущностей e,e' G En если в состоянии Gn выполняется условие e < e', то данное условие выполняется в состоянии G'm .

3. Для каждой роли r G R выполняется условие PAN (r) С PAM (r).

4. Верно включение AN С A'M.

5. Верно включение FN С F'M.

Доказательство. Пусть существуют состояния Go, G\, ..., GN системы E(G*, OP, G0) и правила преобразования состояний op1, ..., opN, такие, что G0 \~opi G1 \~op2 ... \~opN Gn , где N ^ 0. Докажем утверждение индукцией по длине N последовательности состояний.

Пусть N = 0. Тогда положим M = 0, G'0 = G0 и для состояний G0 и G'0 условия 1-5 утверждения выполнены.

Пусть N > 0 и условия утверждения выполнены для всех последовательностей состояний длины 0 ^ L < N. Докажем, что условия 1-5 утверждения выполнены для последовательностей состояний длины N. По предположению индукции, для последовательности состояний G0, Gi, ... , Gn-1 существует последовательность G0, Gi, ..., G'K = (PA!K ,user'K, roles'K ,A!K ,F'K ,H'E ), где K ^ 0, и для состояний GN -1 и G'K выполнены условия 1-5 утверждения. Рассмотрим правило преобразования состояний opN. Если условия его применения не выполняются в состоянии Gn-1, то по определению справедливо равенство Gn-1 = Gn . Положим M = K ; для состояний Gn и G'm выполнены условия 1-5 утверждения. Пусть условия применения правила opN выполняются в состоянии Gn-1. Тогда возможны два случая.

Первый случай: правило преобразования состояний opN является монотонным. Так как для состояний Gn-1 и G' выполнены условия 1-5 утверждения и, по предположению 6, на траекториях системы не изменяются значения функций, задающих уровни целостности сущностей или субъект-сессий, существовавших в предшествующих состояниях системы, то в состоянии G'k выполняются условия применения правила opN. Тогда положим M = K + 1, op'M = opN, и пусть состояние G'M получено из состояния G' применением к нему правила opN : GK \~opN G'm . В соответствии с заданными в таблице результатами применения правил преобразования для состояний Gn и G'm выполнены условия 1-5 утверждения.

В т о р о й с л у ч а й: правило преобразования состояний opN является немонотонным.

Пусть opN = remove_role(x,w,r). Так как для состояний GN-1 и G’K выполнены условия 1-5 утверждения, то выполняются условия (w,user'K(w), 0,0) G G de_facto_actions'K(x), для e G]r[ выполняется условие (e,x,writem) G F'K, и если ir (r) = i_high, то (x, i_entity,writem) G F'K. Кроме того, так как в состоянии GN-1 выполняется условие r G rolesN-1(w), то по предположению 7 в состоянии G'k справедливо r G UA'K(user'K(w)) U AUA'K(user'K(w)) и ir(r) ^ is(w). Следовательно, в состоянии G' выполнены условия применения правила take_role(x,w,r). Тогда положим M = K + 1, op'M = take_role(x, w,r), и пусть состояние G'M получено из состояния G'K применением к нему правила opM: G'k ^op'M GM. В соответствии с заданными в таблице результатами применения правил преобразования состояний remove_role(x, w, r) и take_role(x,w,r) для состояний Gn и G'm выполнены условия 1-5 утверждения.

Пусть opN = remove_right(x,r, (y,ar)). Так как для состояний GN-1 и G'K выполнены условия 1-5 утверждения, то выполняются условия (w, 0, (y,ownr), r) G G de_f acto_actions'K(x), ir(r) ^ is(w), и если ie(y) = i_high, то (x, i_entity, writem) G G F'K. При этом если ar G {ownr,writer,appendr}, то по предположению 7 в состоянии G' выполняется условие ir(r) ^ is(w). Следовательно, в состоянии G' выполнены условия применения правила grant_right(x, r, (y, ar)). Тогда положим M = K + 1, op'M = grant_right(x, r, (y, ar)), и пусть состояние G'M получено из состояния G'K при-

менением к нему правила op'M : G'K \~ор'м G'M. В соответствии с результатами применения правил преобразования remove_right(x,r, (y,ar)) и grant_right(x,r, (y,ar)) для состояний Gn и GM выполнены условия 1-5 утверждения.

Пусть opN = delete_entity(x, у, z). Так как для состояний GN_1 и G'K выполнены условия 1-5 утверждения, то выполняются условия (w, 0, (z,writer),r) Е de_-facto_actions'K(x), ir(r) ^ is(w), ie(z) ^ is(w), и если ie(z) = i_high, то (x,i_entity, writem) Е F'k. Следовательно, в состоянии GK выполнены условия применения правил rename_entity(x, у, z) и access_write(x, w, z). Тогда положим M = K + 2, op'M_ 1 = = rename_entity(x,y, z), op'M = access_write(x,w,z), и пусть состояние G'M получено из состояния G'K применением к нему правил op'M_1,op'M: G'K \~op'M_1 G'M_1 \~opM G'M. В соответствии с заданными в таблице результатами применения правил преобразования состояний delete_entity(x, у, z), rename_entity(x, y, z) и access_write(x,w, z) для состояний Gn и GM выполнены условия 1-5 утверждения.

Пусть opN = delete_session(x, w, z). Так как для состояний GN_1 и GK выполнены условия 1-5 утверждения, то выполняется условие (w, 0, (z,ownr), 0) Е Е de_facto_actionsK(x). Следовательно, в состоянии G'K выполнены условия применения правила access_own(x,w, z). Тогда положим M = K + 1, opM = access_-own(x,w,z), и пусть состояние GM получено из состояния G'k применением к нему правила opM: GK ^op'M GM. В соответствии с заданными в таблице результатами применения правил преобразования состояний delete_session(x,w, z) и access_own(x,w, z) для состояний Gn и GM выполнены условия 1-5 утверждения.

Следовательно, условия 1-5 утверждения выполнены для последовательностей состояний длины N, и шаг индукции доказан. Утверждение доказано. ■

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

ЛИТЕРАТУРА

1. Девянин П. Н. Анализ в рамках базовой ролевой ДП-модели безопасности систем с простыми траекториями функционирования // Прикладная дискретная математика. 2010. №1(7). С. 16-36.

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

3. Колегов Д. Н. ДП-модель компьютерной системы с функционально и параметрически ассоциированными с субъектами сущностями // Вестник Сибирского государственного аэрокосмического университета им. акад. М. Ф. Решетнева. 2009. Вып. 1(22). Ч. 1. С. 49-54.

4. Буренин П. В. Подходы к построению ДП-модели файловых систем // Прикладная дискретная математика. 2009. №1(3). С. 93-112.