Администрирование системы в рамках мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в ОС семейства Linux | ПДМ. 2013. № 4(22).

Администрирование системы в рамках мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в ОС семейства Linux

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

System administration in MROSL DP-model.pdf Введение При разработке формальных моделей безопасности управления доступом и информационными потоками часто правилам преобразования состояний системы, задающим порядок её администрирования, уделяется второстепенное внимание. Это объясняется ориентированностью большинства таких моделей только на теоретический анализ условий безопасности системы, при осуществлении которого, как правило, предполагается, что все действия по администрированию системы выполнены её доверенными субъект-сессиями (субъектами) и функционирование системы осуществляется только в результате реализации правил, инициированных недоверенными субъект-сессиями. Однако в разрабатываемой в настоящее время автором мандатной сущностно-ролевой ДП-модели операционных систем (ОС) семейства Linux (МРОСЛ ДП-модели) [1-3] значительное внимание уделяется её адаптации к условиям функционирования механизма управления доступом отечественной защищённой операционной системы Astra Linux Special Edition [4]. Для этого в МРОСЛ ДП-модели детально задаётся порядок реализации её элементов непосредственно в коде программного обеспечения защищён-ной ОС. Следовательно, целесообразно, кроме типовых правил управления доступом (получения доступа к сущностям, создания, удаления, переименования сущностей или «жёстких» ссылок на них, создания или удаления субъект-сессий), чётко определить правила, позволяющие администрировать учётные записи пользователей, административные права доступа, множества ролей, иерархию ролей и административных ролей, уровни конфиденциальности и целостности сущностей, субъект-сессий, ролей и административных ролей. 1. Основные элементы МРОСЛ ДП-модели Так как формирование МРОСЛ ДП-модели ещё не окончено и её элементы, определения, предположения корректируются с учётом опыта их практической реализации в защищённой ОС, приведём актуальное описание модели в объёме, достаточном для рассмотрения правил администрирования системы. Предположение 1. В рамках МРОСЛ ДП-модели пользователям соответствуют их учётные записи. Каждая учётная запись пользователя является учётной записью либо доверенного, либо недоверенного пользователя. Каждая субъект-сессия является либо доверенной, либо недоверенной и функционирует от имени учётной записи доверенного или недоверенного пользователя соответственно. Используем следующие обозначения: — E = O U C — множество сущностей, где O — множество объектов; C — множество контейнеров; O П C = 0; — S — множество субъект-сессий учётных записей пользователей, где S П E = 0; — entity_name : C х E ^ NAMES — функция имён сущностей в составе сущностей-контейнеров, где NAMES — некоторое множество допустимых имён сущностей, включающее элемент «»—пустая строка. При этом, по определению, если e G HE(c), то entity _name(c, e) = «», иначе entity_name(c, e) = «». Определение 1. Иерархией сущностей называется заданное на множестве сущностей E отношение частичного порядка удовлетворяющее условию: если для сущности-контейнера e G C существуют сущности e',e2 G C, такие, что e ^ e2, e ^ ei, то ei ^ e2 или e2 ^ ei. В случае, когда для двух сущностей e',e2 G E выполняются условия ei ^ e2 и ei = e2, будем говорить, что сущность ei содержится в сущности-контейнере e2, и будем использовать обозначение ei < e2. Определим He : E ^ 2E — функцию иерархии сущностей (сопоставляющую каждой сущности e G E множество сущностей He(e) С E, непосредственно в ней содержащихся), удовлетворяющую следующим условиям: — если e G He (c), то e < c, при этом если e G C, то не существует сущности-контейнера d G C, такой, что e < d < c; — для любых сущностей e', e2 G E, e' = e2, выполняется равенство HE(e') П HE(e2) П nC = 0; — если o G O, то справедливо равенство HE(o) = 0. Определение 2. Иерархией субъект-сессий называется заданное на множестве сущностей S отношение частичного порядка удовлетворяющее условию: если для субъект-сессии s G S существуют субъект-сессии si, s2 G S, такие, что s ^ s2, s ^ si, то si ^ s2 или s2 ^ si. В случае, когда для двух субъект-сессий si, s2 G S выполняются условия si ^ s2 и si = s2, будем говорить, что субъект-сессия si является потомком s2, и будем использовать обозначение si < s2. Определим Hs : S ^ 2S — функцию иерархии субъект-сессий (сопоставляющую каждой субъект-сессии s G S множество субъект-сессий Hs(s) С S, непосредственно в ней содержащихся), удовлетворяющую условиям: — если s' G HS(s2), то s' < s2 и не существует субъект-сессии s G S, такой, что si < s < s2; — для любых субъект-сессий s',s2 G S, s' = s2, выполняется равенство HS(s') П nHs (s2) = 0. В рамках МРОСЛ ДП-модели учтено наличие механизма создания «жёстких» ссылок (hard link) в файловой системе ОС семейства Linux, обеспечивающего возможность размещения сущностей-объектов одновременно в нескольких сущностях-контейнерах. Для всех сущностей заданы их имена в составе сущностей-контейнеров, что позволяет описать правила предоставления содержимого контейнеров (например, списков файлов и каталогов, выдаваемых в реальной защищённой ОС по команде ls) с учётом параметров мандатного управления доступом. Впервые, по сравнению с предыдущими ДП-моделями, определено, что множество субъект-сессий не входит в множество сущностей. Это связано с тем, что в реальной защищённой ОС функции управления доступом к субъект-сессиям (процессам) и сущностям (файлам, каталогам) реализуются раздельно. Таким образом, иерархия на множестве субъект-сессий определяется независимо от иерархии сущностей и при реализации в ОС может быть задана двумя способами. Первый способ, когда существует явная связь между родительскими субъект-сессиями и их потомками (например, когда при завершении работы родительской субъект-сессии завершают работу её субъект-сессии — потомки, подчинённые родительской). Второй способ, когда порождённая субъект-сессией другая субъект-сессия функционирует независимо, в этом случае подчинение её в иерархии родительской субъект-сессии нецелесообразно. Также определим: — U — множество учётных записей пользователей; — Lu — множество учётных записей доверенных пользователей; — Nu — множество учётных записей недоверенных пользователей, при этом по определению справедливы равенства Lu U Nu = U, Lu П Nu = 0; — Ls — множество доверенных субъект-сессий; — Ns — множество недоверенных субъект-сессий, при этом по определению справедливы равенства LS U NS = S, LS П NS = 0; — user : S ^ U — функция принадлежности субъект-сессии учётной записи пользователя, задающая для каждой субъект-сессии учётную запись пользователя, от имени которой она активизирована; — R — множество ролей; — AR — множество административных ролей, при этом по определению AR П R = 0 (административные роли — особый вид ролей, предназначенный для изменения множеств прав доступа ролей, авторизации на роли, а также выполнения функций по администрированию системы, например, управления мандатными уровнями конфиденциальности сущностей и субъект-сессий); — Rr = {readr, writer, executer, ownr} —множество видов прав доступа; — Ra = {reada, writea} —множество видов доступа; — Rf = {writem, writet} —множество видов информационных потоков (по памяти и по времени). Поскольку традиционно в ОС семейства Linux рассматриваются три вида прав доступа к сущностям: на чтение, на запись и на выполнение (или на использование контейнера-каталога), а также при управлении доступом к сущностям и субъект-сессиям учитывается наличие у каждой из них уникального владельца, имеющего право передавать права доступа к ним другим учётным записям пользователей, то в рамках МРОСЛ ДП-модели используются виды прав доступа readr, writer, executer, ownr и виды доступов reada и writea. В отличие от предыдущих ДП-моделей, доступ владения owna исключён из рассмотрения, как не имеющий явной реализации в реальных ОС. Далее введём следующие обозначения: — P С (E х Rr) U (S х {ownr}) —множество прав доступа к сущностям и субъект-сессиям; — AP С (R U AR) х Rr —множество административных прав доступа к ролям или административным ролям; — A С S х E х Ra — множество доступов субъект-сессий к сущностям; — AA С S х (R U AR) х Ra — множество доступов субъект-сессий к ролям или административным ролям; — F С (E U SU RU AR) х (E U SU RU AR) х Rf —множество информационных потоков; — PA : R U AR ^ 2P — функция прав доступа к сущностям ролей и административных ролей, при этом для каждого права доступа p G P существует роль r G RU AR, такая, что выполняется условие p G PA(r); — APA : AR ^ 2ap — функция административных прав доступа к ролям и административным ролям административных ролей, при этом для каждого административного права доступа ap G AP существует административная роль ar G AR, такая, что выполняется условие ap G APA(ar); — shared_container : C U R U AR ^ {true, false} — функция разделяемых контейнеров, такая, что сущность-контейнер, роль или административная роль c G C U R U AR является разделяемой, когда shared_container(c) = true, в противном случае shared_container(c) = false; — V : E U R U AR ^ {(ab...,an) : a G {0,1}, 1 ^ i ^ n, n ^ 1} U {0} — функция значений сущностей, ролей и административных ролей (как аналогов сущностей-контейнеров), задающая возможность для каждой из них принимать значение любой (в том числе пустой) конечной последовательности бит; — (LC, — решётка многоуровневой безопасности уровней конфиденциальности (декартово произведение линейной шкалы уровней конфиденциальности данных и множества всех подмножеств конечного множества неиерархических категорий данных); — (/«, /е, /r, /s) G FC — четвёрка функций уровней конфиденциальности, при этом: — / : U ^ LC — функция, задающая для каждой учётной записи пользователя её уровень доступа — максимальный разрешённый уровень доступа субъект-сессий, функционирующих от её имени; — /е : E ^ LC — функция, задающая уровень конфиденциальности для каждой сущности; — /r : R U AR ^ LC — функция, задающая для каждой роли или административной роли её уровень конфиденциальности; — /s : S ^ LC — функция, задающая для каждой субъект-сессии её текущий уровень доступа; — FC — множество всех четвёрок функций заданного вида; — CCR : E U R U AR ^ {true, false} — функция, задающая способ доступа к сущностям внутри контейнеров или ролям в иерархии ролей (с учётом их мандатных уровней конфиденциальности). Если сущность e G C является контейнером и доступ к сущностям, содержащимся внутри контейнера e, разрешён без учёта уровня конфиденциальности контейнера e, то по определению выполняется равенство CCR(e) = false, в противном случае CCR(e) = true. При этом по определению для каждой сущности-объекта o G O выполняется равенство CCR(o) = true, для ролей или административных ролей r G R U AR всегда выполняется равенство CCR(r) = false; — (LI, —линейная шкала двух уровней целостности данных, где LI = {i_/ow, i_high}, i_/ow < i_high; — (iu,ie,ir,is) G I — четвёрка функций уровней целостности, при этом: — iu : U ^ LI — функция, задающая для каждой учётной записи пользователя её уровень целостности — максимальный разрешённый уровень целостности субъект-сессий, функционирующих от её имени; — ie : E ^ LI — функция, задающая уровень целостности для каждой сущности; — ir : RUAR ^ LI — функция, задающая для каждой роли или административной роли её уровень целостности; — is : S ^ LI — функция, задающая для каждой субъект-сессии её текущий уровень целостности; — I — множество всех четвёрок функций заданного вида; — CCRI : EURUAR ^ {true, false} — функция, задающая способ доступа к сущностям внутри контейнеров, ролям или административным ролям в иерархии ролей (с учётом их мандатных уровней целостности). Если сущность e G C является контейнером и доступ к сущностям, содержащимся внутри контейнера e, разрешён без учёта уровня целостности контейнера e, то по определению выполняется равенство CCRI(e) = false, в противном случае CCRI(e) = true. При этом по определению для каждой сущности-объекта o G O выполняется равенство CCRI(o) = true, для ролей или административных ролей r G R U AR всегда выполняется равенство CCRI (r) = false. Определение 3. Иерархией ролей называется заданное на множестве ролей R отношение частичного порядка При этом по определению справедливо: для административной роли ar G AR, если роли r, r' G R таковы, что (r, readr) G APA(ar) и r' ^ r, то выполняется условие (r',readr) G APA(ar). Иерархией административных ролей называется заданное на множестве ролей AR отношение частичного порядка ^. При этом по определению справедливо: для административной роли ar G AR, если административные роли r, r' G AR таковы, что (r, readr) G APA(ar) и r' ^ r, то выполняется условие (r', readr) G APA(ar). По определению роли и административные роли несравнимы друг с другом, т. е. их иерархии всегда независимы. В случае, когда для двух ролей или административных ролей r, r' G R U AR выполняются условия r ^ r' и r = r', будем использовать обозначение r < r'. Определим : R U AR ^ 2R U 2AR — функцию иерархии ролей и административных ролей, сопоставляющую каждой роли r G R U AR множество ролей HR(r) С R U AR и удовлетворяющую условию: если r' G HR(r), то r' < r и не существует роли r'' G R U AR, такой, что r' < r'', r'' < r. Используем следующее обозначение: — ro1e_name : (R U AR) x (R U AR) ^ NAMES — функция имён ролей и административных ролей в составе роли или административной роли (как контейнера). При этом по определению если r G HR(r'), то ro/e_name(r',r) = «», иначе ro/e_name(r', r) = «». Предположение 2. Для каждой учётной записи пользователя u G U в зависимости от её уровня целостности задаются следующие индивидуальные административные роли, на которые авторизована только эта учётная запись: — u_admin_i_/ow G AR, ir(u_admin_i_/ow) = i_/ow, /r(u_admin_i_/ow) = ®LC, когда iu(u) = i_/ow (®LC — минимальный элемент решётки уровней конфиденциальности LC); — u_admin_i_/ow, u_admin_i_high G AR, ir(u_admin_i_/ow) = i_/ow, ir(u_ad-min_i_high) = i_high, /r(u_admin_i_/ow) = /r(u_admin_i_high) = ®LC, u_admin_i_/ow < u_admin_i_high, когда i«(u) = i_high. Множество других ролей учётной записи пользователя u задается с использованием административных прав доступа соответственно административной роли u_admin_i_/ow или административных ролей u_admin_i_/ow, u_admin_i_high, определяемых функцией APA. Иерархия индивидуальных административных ролей изменяется только при создании, удалении и изменении уровней доступа или целостности соответствующих учётных записей пользователей. На траекториях функционирования системы у этих административных ролей не изменяются имена, уровни конфиденциальности или целостности. В рамках МРОСЛ ДП-модели, в отличие от моделей семейства RBAC и других ролевых ДП-моделей, впервые вместо функций UA и AUA для задания авторизованных ролей и административных ролей учётных записей пользователей используются права доступа их индивидуальных административных ролей, задаваемых функцией APA. Такой подход, с одной стороны, позволяет реализовать ролевое управление доступом — назначение прав доступа учётным записям пользователей только через роли, с другой стороны, он направлен на обеспечение приоритетности и «монолитности» мандатного управления доступом как при управлении доступом к сущностям, так и при использовании или администрировании ролей. Достигается также большая совместимость со штатными механизмами управления доступом реальной защищённой ОС. Минимальный уровень конфиденциальности административных ролей обеспечивает возможность получения их в качестве текущих (получения доступа reada) субъект-сессией с любым текущим уровнем доступа. В моделях семейства RBAC и других ролевых ДП-моделях предполагалось, что функция авторизованных ролей учётных записей пользователей UA обладает свойством «наследования» подчинённых ролей, т. е. выполняется следующее условие: для учётной записи пользователя u G U, если роли r, r' G R таковы, что r G UA(u) и r' ^ r, то выполняется условие r' G UA(u). В рамках МРОСЛ ДП-модели с учётом предположения 2 это обеспечивается «наследованием» административной ролью права доступа readr от данной роли ко всем подчинённым ей ролям в иерархии. При этом права доступа writer и ownr таким свойством не обладают, что может позволить гибко задавать «диапазоны» администрируемых ролей по аналогии с моделью ролевого администрирования ARBAC [1]. При реализации иерархий ролей в реальной защищён-ной ОС по аналогии с файловой системой можно использовать виртуальную структуру сущностей-ролей, отличающуюся от структур для файлов наличием «жёстких» ссылок не только на роли-«объекты» (роли, которым в иерархии не подчинена ни одна другая роль), но и на роли-«контейнеры» (роли, которым в иерархии подчинена хотя бы одна роль). Используем следующее обозначение: — execute_container : S х E ^ {true, false} — функция доступа субъект-сессии к сущностям в контейнерах, такая, что по определению для субъект-сессии s G S и сущности e G E справедливо равенство execute_container(s, e) = true тогда и только тогда, когда существует последовательность сущностей ei,..., en G E, где n ^ 1, e = en, удовлетворяющих следующим условиям: — не существует сущности-контейнера e0 G E, такой, что e' G He(e0); — ei G He(ei-i), где 1 < i ^ n; — существует r G R U AR, такая, что (s,r^,reada) G AA и (ei,executer) G PA(r^), i/e(ej) ^ /s(s) или CCR(e^) = false] и [ie(ei) ^ is(s) или CCRI(e^) = false], где 1 ^ i < n. Данная функция используется для краткости и удобства описания элементов модели с учётом мандатного управления доступом и мандатного контроля целостности и не требует непосредственной реализации в реальной защищённой ОС (она «реализуется» путём последовательной проверки прав доступа к сущностям-контейнерам, содержащим данную сущность, на которую указывает её полное имя, начиная с корневой сущности-контейнера). Зададим в рамках МРОСЛ ДП-модели механизм ограничений (Constraints), при этом используем следующие обозначения: — APA* — множество всех функций административных прав доступа административных ролей; — PA* — множество всех функций прав доступа ролей и административных ролей; — AA* — множество множеств доступов субъект-сессий к ролям или административным ролям; — CAPA : APA* ^ {true, false} — функция, задающая ограничение на значения множеств административных прав доступа административных ролей, т. е. по определению множества административных прав доступа административных ролей, заданные функцией APA G APA*, удовлетворяют ограничению CAPA, если выполняется равенство Capa(APA) = true; — CPA : PA* ^ {true, false} — функция, задающая ограничение на значения множеств прав доступа ролей и административных ролей, т. е. по определению множества прав доступа ролей и административных ролей, заданные функцией PA G PA*, удовлетворяют ограничению CPA, если выполняется равенство CPA(PA) = true; — CAA : AA* ^ {true, false} — функция, задающая ограничение на значение множества административных доступов субъект-сессий к ролям или административным ролям, т. е. по определению множества административных доступов субъект-сессий к ролям или административным ролям, заданные множеством AA G AA*, удовлетворяют ограничению CAA, если выполняется равенство Caa(AA) = true; — Constraint APA = {CAPA,...,CAPA} —множество функций, задающих некоторый набор ограничений на значения множеств административных прав доступа административных ролей, где пара ^ 0. При этом будем писать Constraintapa(APA) = = true тогда и только тогда, когда либо nAPA = 0, либо nAPA > 0 и Capa(APA) = = true для 1 ^ i ^ пара; — ConstraintPA = {CPA,... , CpA} — множество функций, задающих некоторый набор ограничений на значения множеств прав доступа ролей, где Пра ^ 0. При этом будем писать Constraints (PA) = true тогда и только тогда, когда либо пра = 0, либо nPA > 0 и CPA(PA) = true для 1 ^ i ^ nPA; — ConstraintAA = {CAA,... , C^A} — множество функций, задающих некоторый набор ограничений на значение множества административных доступов субъект-сессий к ролям или административным ролям, где Паа ^ 0. При этом будем писать Constraintaa(AA) = true тогда и только тогда, когда либо Паа = 0, либо Паа > 0 и Caa(AA) = true для 1 ^ i ^ nAA. Механизм ограничений как мощное средство ролевого управления доступом целесообразно реализовать, как минимум, на перспективу. Ограничения, например, взаимного исключения ролей, количественные на обладание ролью, могут стать удобным средством администрирования защищённой ОС. Ограничениям на функции UA и ro/es, заданным в моделях семейства RBAC и других ролевых ДП-моделях, в МРОСЛ ДП-модели соответствуют ограничения на функцию APA и множество AA. Определение 4. Пусть определены: — множества учётных записей пользователей U, сущностей E, субъект-сессий S, прав доступа к сущностям P, учётных записей доверенных пользователей Lu , доверенных субъект-сессий Ls, доступов субъект-сессий к сущностям A, доступов субъект-сессий к ролям и административным ролям AA, информационных потоков F, ограничений на значения множеств административных прав доступа административных ролей Constraint^pA, множеств прав доступа ролей Constraints, множеств доступов субъект-сессий к ролям или административным ролям ConstraintAA; — функции административных прав доступа к ролям административных ролей APA, прав доступа ролей и административных ролей PA, принадлежности субъект-сессий учётным записям пользователей user, уровней конфиденциальности (/„, /е, /r, /s), мандатных атрибутов конфиденциальности CCR, уровней целостности (iu, ie, ir, is), мандатных атрибутов целостности CCRI, иерархии ролей Hr, иерархии сущностей He , иерархии субъект-сессий Hs . Определим G = (APA, PA, user, / /е, /г, /s), CCR, (iu, ie, ir, is), CCRI, A, AA, F, Hr, HE, HS, ConstraintAPA, ConstraintPA, ConstraintAA, L^, LS) —состояние системы. Используем обозначение: — E(G*, OP) — система, где G* — множество всех возможных её состояний; OP — множество правил преобразования её состояний. Используемые в МРОСЛ ДП-модели правила преобразования состояний из множества OP классифицированы на де-юре правила, реализуемые в реальной защи-щённой ОС, т.е. приводящие к «реальным» изменениям её параметров (изменению множеств прав доступа ролей, получению доступов субъект-сессий к сущностям или ролям и т. д.), и де-факто правила, не требующие реализации в ОС, так как используются в модели для отражения факта получения субъект-сессией де-факто владения субъект-сессиями или факта реализации информационного потока по памяти или по времени. 2. Параметрически ассоциированные сущности. Специальные административные роли Сформулируем предположения, позволяющие учесть наличие в реальных защи-щённых ОС сущностей, параметрически ассоциированных с учётными записями пользователей или ролями. Предположение 3. Для каждой учётной записи пользователя задаётся множество сущностей, параметрически с ней ассоциированных, получение доступов на чтение или на запись к которым субъект-сессией позволяет ей создать субъект-сессию от имени данной учётной записи пользователя. Множество сущностей, параметрически ассоциированных с учётной записью пользователя, не изменяется в процессе функционирования системы. Предположение 4. Для каждой роли или административной роли задаётся (возможно, пустое) множество сущностей, параметрически с ней ассоциированных. При этом для получения или удаления субъект-сессией доступа к роли, кроме наличия к данной роли соответствующего права доступа, этой субъект-сессии необходимо получить доступ на чтение или на запись ко всем сущностям, параметрически ассоциированным с данной ролью. Множество сущностей, параметрически ассоциированных с ролью или административной ролью, не изменяется в процессе функционирования системы. Множество сущностей, параметрически ассоциированных с каждой индивидуальной административной ролью учётной записи пользователя, совпадает с множеством сущностей, параметрически ассоциированных с данной учётной записью пользователя. Примерами параметрически ассоциированных с учётными записями пользователей или ролями сущностей являются файлы паролей, cookies или ключей и т.д., т.е. то, «знание» (получение доступа на чтение) или «подмена» (получение доступа на запись) чего позволяет недоверенной субъект-сессии создать в системе субъект-сессию от имени данной учётной записи пользователя. Лишь у небольшого числа ролей могут быть такие сущности, их наличие позволяет обеспечить дополнительную защиту при получении субъект-сессией доступа к роли, например, потребовав дополнительно повторно ввести пароль. С учётом сделанных предположений используем следующие обозначения: — ] u[G E — множество сущностей, параметрически ассоциированных с учётной записью пользователя u G U; — UE = {e G]u[: u G U} — множество сущностей, каждая из которых параметрически ассоциирована хотя бы с одной учётной записью пользователя; — ]r[G E — множество сущностей, параметрически ассоциированных с ролью или административной ролью r G R U AR, при этом для каждой учётной записи пользователя u G U в соответствии с предположением 4 выполняется условие ]u[=]u_admin_i_1ow[, и если iu(u) = i_high, то ]u[=]u_admin_i_high[; — RE = {e G]r[: r G R U AR} —множество сущностей, параметрически ассоциированных хотя бы с одной ролью или административной ролью. Предположение 5. В рамках МРОСЛ ДП-модели на траекториях функционирования системы не изменяются функции Constraintара, Constraintра и ConstraintAA. Новые значения для функций /s и is задаются только при создании соответствующих новых субъект-сессий. В дополнение к предположению 1, недоверенная субъект-сессия всегда может создать недоверенную субъект-сессию с низким уровнем доступа. В начальном состоянии G0 любой системы S(G*,OP) выполняются следующие условия: — функции APA0, PA0 и множество AA0 удовлетворяют соответствующим ограничениям ConstraintAPA, Constraintра и ConstraintAA; — для любых субъект-сессии s G S0 и сущности e G E0, если (s,e,aa) G A0, где aa G Ra, то справедливо равенство execute_container0(s, e) = true. В предположении 5 требуется, чтобы в начальном состоянии выполнялись ограничения и доступы субъект-сессий к сущностям соответствовали мандатному управлению доступом и мандатному контролю целостности. Кроме того, для строгого задания правил преобразования состояний системы, ориентированных на реализацию в реальной защищённой ОС, впервые по сравнению с предшествующими ДП-моделями в рамках МРОСЛ ДП-модели допускается администрирование существенных параметров системы, влияющих на её безопасность (множеств учётных записей пользователей, ролей или административных ролей, значений уровней доступа, конфиденциальности или целостности учётных записей пользователей, ролей, административных ролей, сущностей). Для этого в модель включены специальные административные роли. Используем следующие обозначения: — ADMIN_ROLES С AR — множество специальных административных ролей, которые не могут создаваться, удаляться, переименовываться, менять свои параметры в процессе функционирования системы. Все административные роли из множества ADMIN_ROLES по определению обладают высоким уровнем целостности: для административной роли ar G ADMIN_ROLES справедливо равенство ir (ar) = i_high; — users_admin_ro/e G ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для изменения уровня доступа или целостности, удаления учётной записи пользователя; — entities_admin_ro/e G ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для изменения ею единственной роли-владельца сущности (роли, обладающей правом доступа владения ownr к сущности), получения данных о ролях или административных ролях, обладающих правами доступа к сущности, получения числа «жёстких» ссылок к сущности, изменения уровня конфиденциальности или целостности сущности, изменения мандатного атрибута конфиденциальности CCR, мандатного атрибута целостности CCRI или метки разделяемости сущности-контейнера, переименования, удаления сущности-контейнера или «жёсткой» ссылки на него с мандатным атрибутом целостности CCRI равным false; — subjects_admin_ro/e G ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для изменения единственной роли-владельца другой субъект-сессии, получения данные о ролях или административных ролях, обладающих правами доступа владения к другой субъект-сессии; — ro/es_admin_ro/e, admin_ro/es_admin_ro/e G ADMIN_ROLES — специальные административные роли, являющиеся ролями-владельцами ролей или административных ролей соответственно, доступ субъект-сессии на чтение к каждой из которых требуется для управления доступом к роли или административной роли, изменения её уровней конфиденциальности или целостности, создания, переименования, удаления, получения параметров роли или административной роли, создания, изменения уровня доступа или целостности учётной записи пользователя; — downgrade_admin_ro/e G ADMIN_ROLES — специальная административная роль, доступ субъект-сессии на чтение к которой требуется для нарушения ею правил мандатного управления доступом. По определению справедливы равенства /r (users_admin_ro/e) = /r (entities_admin_ro/e) = /r (subjects_admin_ro/e) = = /r (ro/es_admin_ro/e) = /r (admin_ro/es_admin_ro/e) = ®LC, /r (downgrade_admin_ro/e) = ®LC. 3. Де-юре правила администрирования системы Всего в рамках МРОСЛ ДП-модели заданы 34 де-юре правила преобразования состояний, условия и результаты применения которых соответствуют предположениям модели. Правила предназначены для формального описания (спецификации) следующих основных функций механизма управления доступом защищённой ОС: — создания, удаления, переименования, получения или изменения параметров учётных записей пользователей, ролей, административных ролей, сущностей или «жёстких» ссылок на них, субъект-сессий; — получения доступов субъект-сессий к сущностям, ролям или административным ролям; — изменения прав доступа ролей или административных ролей к сущностям, субъект-сессиям, ролям или административным ролям; — изменения иерархии, уровней конфиденциальности или целостности сущностей, ролей или административных ролей. В таблице приведено детальное описание де-юре правил администрирования системы, при этом в ней не указываются элементы последующего состояния G', которые не изменяются в результате применения соответствующего правила к исходному состоянию G. Де-юре правила администрирования системы в рамках МРОСЛ ДП-модели Правило: create_user(x, x', u, uc, ui, ue) Условия применения: ж, ж' G S, u G U, (x, users_admin_role, reada) G AA, (x, roles_admin-_role,aa) G AA, (x, admin_roles_admin_role, aa) G AA, где aa G {reada,writea}; ue С UE; [uc = fs(x) или (uc ^ fs(x) и (x, downgrade_admin_role,reada) G AA)]; ui ^ is(x); [для e G ue выполняется fe(e) = uc, ie(e) = ui]; Constraintapa(-APA') = true; ConstraintpA(PA') = true; [если ui = i_high, то (x', fs(x)_i_entity, writea) G A] Результаты применения: U' = U U {u}, ]u[= ue, fU(u) = uc, i'u(u) = ui, если ui = i_high, то L'u = Lu U {u}, иначе N' = Nu U {u}, для u' G U выполняется f'(u') = fu(u'), i'u(u') = iu(u'), AR' = AR U {u_admin_li : li ^ ui}, f'r(u_admin_li) = ®LC, i'r(u_admin_li) = li, shared_container'(u_admin_li) = true, CCR'(u_admin_li) = CCRI'(u_admin_li) = false, role_name'(u_admin_li) ="u _admin _li", где li ^ ui, HR(u_admin_i_low) = 0, если ui = i_high, то H'R(u_admin_i_high) = {u_admin_i_low}, R' = R U {u_c_l_li : l ^ uc, li ^ ui}, fr (u_c_l_li) = l, ir (u_c_l_li) = li, shared_contai-ner'(u_c_l_li) = true, CCR'(u_c_l_li) = CCRI'(u_c_l_li) = false, role_name'(u_c_l_li) = = "u_c_l_li", где l ^ uc, li ^ ui, APA'(admin_roles_admin_role)=APA(admin_roles_admin_role)U{(u_admin_li, ownr):li^ui}, APA'(roles_admin_role) = APA(roles_admin_role) U {(u_c_l_li, ownr) : l ^ uc, li ^ ui}, для ar G AR выполняется APA'(ar) = APA(ar) U {(u_admin_li, executer) : li ^ ui} U {(u_c_l_li, executer) : l ^ uc, li ^ ui}, AP A'(u _admin _i _low) = {(u _admin _i _low, ar) : ar G {readr ,writer ,executer }}U U{(u_c_l_(i_low), ar) : l ^ uc, ar {readr ,writer ,executer }}, если ui = i_high, то APA'(u_admin_i_high) = {(u_admin_li,ar) : li ^ ui,ar G {readr, writer, executer}} U {(u_c_l_(i_high),ar) : l ^ uc,ar G {readr,writer,executer}}, HR(u_c_l_li) = {u_c_l'_li' : l' < l,li' < li и не существуют l'' G LC(l' < l'' < l) или li'' G LI (li' < li'' < li)}, PA'(u_c_l_li) = 0, где l < uc, li < ui Правило: set_user_labels(x, x', u, uc, ui, ue) Условия применения: x,x' G S, u G U, user-1(u) = 0, (x, users_admin_role, reada) G AA, (x, roles_admin_role, aa) G AA, (x, admin_roles_admin_role, aa) G AA, где aa G {reada, writea}, [если fu(u) = uc, то max(fu(u), uc) ^ fs(x) и (x, downgrade_admin_role, reada) G AA], max(iu(u), ui) ^ is(x), [для e G ue верно fe(e) = uc, ie(e) = ui], Constraintapa(APA') = true, Constraintpa(PA') = true, [если ui = i_high, то (x', fs(x)_i_entity, writea) G A] Продолжение таблицы Результаты применения: ]u[= ue, fU(u) = uc, i'u(u) = ui, если ui = i_high, то ЬЦ = Ьц U {u}, N' = Nu \ {u}, иначе NЦ = N' U {u}, ЬЦ = Ьц \ {u}, для u' G U \ {u} верно f'(u') = fu(u'), i'(u') = iu(u'), AR' = (A U {u_admin_li: iu(u) < li ^ ui}) \ {u_admin_li: ui < li ^ iu(u)}, fr (u_admin_li) = ®LC, i'r (u_admin_li) = li, shared _container' (u_admin_li) = true, CCR'(u_admin_li) = CCRI'(u_admin_li) = false, role_name'(u_admin_li) = "u_admin_li', где iu(u) < li ^ ui, если ui = i_high, то H'R(u_admin_i_high) = {u_admin_i_low}, R' = (R U {u_c_l_li : fu(u) < < l ^ uc,iu(u) < li ^ ui}) \ {u_c_l_li : uc < l ^ fu(u),ui < li ^ iu(u)}, fr(u_c_l_li) = l, ir(u_c_l_li) = li, shared_container'(u_c_l_li) = true, CCR'(u_c_l_li) = CCRI'(u_c_l_li) = = false, role_name'(u_c_l_li) = "u_c_l_li", где fu(u) < l ^ uc, iu(u) < li ^ ui, APA'(admin_roles_admin_role) = (APA(admin_roles_admin_role) U {(u_admin_li,ownr) : iu(u) < li ^ ui}) \ {(u_admin_li,ownr) : ui < li ^ iu(u)}, APA'(roles_admin_role) = = (APA(roles_admin_role) U {(u_c_l_li, ownr) : fu(u) < l ^ uc, iu(u) < li ^ ui})\ \{(u_c_l_li, ownr) : uc < l ^ fu(u), ui < li ^ iu(u)}, для ar G AR выполняется APA'(ar) = (APA(ar) U {(u_admin_li, executer) : iu(u) < li ^ ui} U U{ (u_c_l _li, executer) : fu(u) < l ^ uc,iu(u) < li ^ ui}) \ ({(u_admin_li,executer) : ui < li ^ ^ iu(u)} U {(u_c_l_li, executer) : uc < l ^ fu(u),ui < li ^ iu (u)}), AP A'(u _admin _i _low) = = (APA'(u_admin_i_low) U {(u_c_l_(i_low), ar) : fu(u) < l ^ uc,ar G {readr,writer, executer }}) \ {(u_c_l _(i_low), ar) : uc < l ^ fu(u),ar G {readr ,writer ,executer }}, если ui = i_high, то APA'(u_admin_i_high) = (APA(u_admin_i_high) U {(u_admin_li, ar) : li ^ ui,ar G {readr,writer, executer}} U {(u_c_l_(i_high), ar) : fu(u) < l ^ uc,ar G {readr, writer, executer}}) \ {(u_c_l_(i_high), ar) : uc < l ^ fu(u), ar G {readr, writer, executer}}, HR(u_c_l_li) = {u_c_l'_li' : l' < l, li' < li и не существуют l'' G LC(l' < l'' < l) или li'' G LI (li' < li'' < li)}, PA'(u_c_l_li) = 0, где fu(u) < l < uc, iu(u) < li < ui Правило: delete_user(x, x', u) Условия применения: x,x' G S, u G U, user-1(u) = 0, (x,users_admin_role,reada) G AA, (x, users_admin_role,reada) G AA, (x, roles_admin_role,reada) G AA, [fu(u) = fs(x) или (fu(u) ^ fs(x) и (x,downgrade_admin_role,reada) G AA)], iu(u) ^ is(x), Constraintapa(-APA') = = true, ConstraintpA(PA') = true, [если iu(u) = i_high, то (x', fs(x)_i_entity,writea) G A] Результаты применения: U' = U \ {u}, для u' G U' выполняется f (u') = fu(u'), iu(u') = iu(u'), AR' = AR \ {u_admin_li : li ^ ui}, R' = R \ {u_c_l_li : l ^ uc, li ^ ui}, для ar G AR' выполняются равенства APA'(ar) = APA(ar) \ ({(u_admin_li, ar) : li ^ ui, ar G Rr} U {(u_c_l_li, ar) : l ^ uc, li ^ ui, ar G Rr}) Правило: get_user_attr(x, u, z) Условия применения: x G S, u G U, z G O, [fu(u) ^ fs(x) или (x, downgrade_admin_role, reada) G AA], (x, z,writea) G A Результаты применения: V'(z) = (fu(u),iu(u), (если user(x) = u или (x, users_admin_role, reada) G AA, то {(r',ar) : (r',ar) G APA(u_admin_li), li ^ iu(u) и (fr(r') ^ fs(x) или (x, downgrade_admin_role,reada) G AA)}, иначе "0"), (если user(x) = u или (x, users_admin_role, reada) G AA, то {s G S: user(s) = u и либо fs(s) ^ fs(x) или (x, downgrade_admin_role, reada) G AA)}, иначе "0")) Правило: grant_rights(x, x', r, {(y, arj): 1 ^ j ^ k}) Условия применения: x,x' gS, yGE, rGR U AR, arj G{readr ,writer ,executer}, (x,r,writea)GAA, ie(y) ^ is(x), [существует r' G R U AR ((x,r',reada) G AA, (y,ownr) G PA(r'))], [либо (execute_-container(x,y) = true и fe(y) = fs(x)), либо (x, downgrade_admin_role,reada) G AA], [если arj = writer, то ie(y) ^ ir(r)], ConstraintpA(PA') = true, [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) G A], где 1 ^ j ^ k Результаты применения: PA'(r) = PA(r) U {(y, arj) : 1 ^ j ^ k} и для r' G (R U AR) \ {r} выполняется равенство PA'(r') = PA(r') Продолжение таблицы Правило: remove _rights(x, x', r, {(y, a.r.): 1 ^ j ^ k})_ Условия применения: x,x' G S, y G E, r G R U AR, arj G {readr,writer,executer}, {(y, arj) : 1 ^ j ^ k} С PA(r), (x,r,writea) G AA, ie(y) ^ is(x), [существует r' G R U AR ((x,r', reada) G AA, (y,ownr) G PA(r'))], [либо (execute _container(x,y) = true и fe(y) = fs(x)), либо (x,downgrade_admin_role,reada) G AA], ConstraintpA(PA') = true, [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) G A], где 1 ^ j ^ k Результаты применения: PA'(r) = PA(r) \ {(y, arj) : 1 ^ j ^ k}, и для r' G (R U AR) \ {r} выполняется равенство PA'(r') = PA(r') Правило: set_entity_owner(x, x', r, r', y) Условия применения: x,x' G S, y G E, r,r' G R U AR, {(x,r,reada), (x,r,writea), (x,r', writea), (x, entities _admin_role,reada)} С AA, (y,ownr) G PA(r), ConstraintpA (PA') = true, ie(y) ^ min(ir(r'),is(x)), [либо (execute _container(x,y) = true и fe(y) = fs(x)), либо ((x,downgrade _admin _role,reada) G AA)], [если ie(y) = i_high, то (x',fs(x)_i_entity,writea) G A] Результаты применения: PA'(r) = PA(r) \ {(y, ownr)}, PA'(r') = PA(r') U {(y, ownr)}, для r'' G (R U AR) \ {r, r'} выполняется равенство PA'(r'') = PA(r'') Правило: set_subject_owner(x, x', r, r', y) Условия применения: x, x' G S, y G S, r, r' G R U AR, {(x,r,reada), (x,r,writea), (x,r',writea), (x, subjects _admin_role,reada)} С AA, (y,ownr) G PA(r), ConstraintpA (PA') = true, is(y) ^ ^ min(ir(r'),is(x)), [либо fs(y) = fs(x), либо (x, downgrade_admin_role,reada) G AA], [если is(y) = i_high, то (x', fs(x)_i_entity,writea) G A] Результаты применения: PA'(r) = PA(r) \ {(y, ownr)}, PA'(r') = PA(r') U {(y, ownr)}, для r'' G (R U AR) \ {r, r'} выполняется равенство PA'(r'') = PA(r'') Правило: grant_admin_rights(x, x', ar, {(r, arj): 1 ^ j ^ k}) Условия применения: x,x' G S, r G RU AR, ar G AR, arj G {writer,readr}, (x, ar,writea) G AA, ir(r) ^ ir(ar), ir(r) ^ is(x), [если r G R, то (x,roles_admin_role,reada) G AA, если r G AR, то (x, admin_roles_admin_role, reada) G AA], [либо fr(r) = fs(x), либо (x, downgrade_admin_-role,reada) G AA], Constraintapa(APA') = true, [если ir(r) = i_high, то (x', fs(x)_i_entity, writea) G A], где 1 ^ j ^ k Результаты применения: APA'(ar) = APA(ar) U {(r,arj) : ar. = writer, 1 ^ j ^ k} U {(r',arj): arj = readr, r' ^ r, 1 ^ j ^ k}, для ar' G AR \ {ar} выполняется равенство APA'(ar') = APA(ar') Правило: remove_admin_rights(x, x', ar, {(r, arj): 1 ^ j ^ k})_ Условия применения: x,x' G S, r G R U AR, ar G AR, arj G {writer ,readr}, {(r,arj) : arj = writer, 1 ^ j ^ k} С APA(ar), (x,ar,writea) G AA, ir(r) ^ is(x), [если r G R, то (x, roles_admin_role,reada) G AA, если r G AR, то (x, admin_roles_admin_role,reada) G AA], [либо fr (r) = fs(x), либо (x, downgrade _admin_role,reada) G AA], Constraint ap a (APA') = true, [если ir (r) = i_high, то (x', fs(x)_i_entity, writea) G A], где 1 ^ j ^ k Результаты применения: APA'(ar) = APA(ar) \ ({(r, arj) : arj = writer, 1 ^ j ^ k} U {(r', arj): arj = readr, r ^ r', 1 ^ j ^ k}), для ar' G AR \ {ar} верно равенство APA'(ar') = APA(ar')_ Правило: create_role(x, x', r, rc, ri, re, name, rz) Условия применения: x,x' G S, r G R U AR, [если rz G R, то (x, roles_admin_role, aa) G AA, если rz G AR, то (x,admin_roles_admin_role,aa) G AA, где aa G {reada, writea}], (x,rz, writea) G AA, re С RE, name G NAME\ {«»}, [либо r = fr(rz) = fs(x), либо r ^ fr(rz) и (x, downgrade_admin_role,reada) G AA], ri ^ min(ir(rz), is(x)), [для e G re выполняется fe(e) = rc, ie(e) = ri], Constraint apa( APA') = true, ConstraintpA (PA') = true, [если ir (rz) = i_high, то (x', fs(x)_i_entity, writea) G A] Результаты применения: если rz G R, то R' = RU{r}, APA'(roles_admin_role) = APA(roles_-admin_role) U {(r,ownr), (r,executer)} U {(r,readr) : (rz,readr) G APA(roles_admin_role)}, если rz G AR, то AR' = AR U {r}, APA'(admin_roles_admin_role) = APA(admin_roles_-admin_role) U {(r,ownr), (r,executer)} U {(r,readr) : (rz,readr) G APA(admin_roles_admin_-role)}, для ar G AR \ {admin_roles_admin_role, roles_admin_role} выполняется APA'(ar) = = APA(ar) U {(r,executer)} U {(r,readr) : (rz,readr) G APA(ar)}, fr(r) = rc, i'r(r) = ri, CCR'(r) = false, CCRI'(r) = false, role_name'(rz,r) = name, ]r[= re, shared_container'(r) = true, PA'(r) = 0, H'R(rz) = He(z) U{r}, H'R(r) = 0, для r G (RU AR) \{r} выполняется равенство H'R(r) = HR(r) Окончание таблицы Правило: delete_role(x, x', r, rz) Условия применения: x,x' G S, r G (R U AR) \ ({u_admin_li : u G U,li ^ iu(u)} U {u_c_l_li : u G U, l < fu(u), li < iu(u)} U ADMIN_ROLES), [если r G R, то rz G R, (x, roles_admin_-role,aa) G AA, если r G AR, то rz G AR, (x, admin_roles_admin_role,aa) G AA, где aa G G {reada, writea}], r G H'(rz), HR(r) = 0, [не существует rz' G R U AR, такой, что rz' = rz и r G HR(rz')], [(x,rz,writea) G AA, Constraintaa(AA') = true, Constraintapa(APA') = = true, ConstraintpA(PA') = true], [либо fr(r) = fs(x), либо fr(r) ^ fs(x) и (x, downgrade_-admin_role, reada) G AA], ir (r) ^ is(x), [если ie(z) = i_high, то (x',fs(x)_i_entity, writea) G A] Результаты применения: R' = R \ {r}, AR' = AR \ {r}, H'R(rz) = HR(rz) \ {r}, для всех r' G (R'UAR')\{rz} выполняется равенство H'R(r') = HR(r'), для ar G AR' выполняются равенства APA'(ar) = APA(ar) \ {(r, ar) : ar G Rr}, AA' = AA \ {(s,r,aa) : s G S,aa G Ra} Правило: create_hard_link_role(x, x', r, name, rz) Условия применения: x, x' G S, r G (R U AR) \ ({u_admin_li : u G U,li ^ iu(u)} U {u_c_l_li : u G U,l ^ fu(u), li ^ iu(u)} U ADMIN_ROLES), не выполняется условие rz ^ r, Constraintapa(APA') = true, [если rz G R, то (x, roles_admin_role,aa) G AA, если rz G AR, то (x, admin_roles_admin_role,aa) G AA, где aa G {reada,

Ключевые слова

мандатная сущностно-ролевая ДП-модель, операционная система Linux, mandatory entity-role DP-model, OS Linux

Авторы

ФИООрганизацияДополнительноE-mail
Девянин Петр НиколаевичУчебно-методическое объединение по образованию в области информационной безопасности (г. Москва)доктор технических наук, доцент, председательpeter_devyanin@hotmail.com
Всего: 1

Ссылки

Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учебн. пособие для вузов. 2-е изд., испр. и доп. М.: Горячая линия-Телеком, 2013. 338 с.
Девянин П. Н. Корректность правил преобразования состояний системы в рамках мандатной сущностно-ролевой ДП-модели ОС семейства Linux // Прикладная дискретная математика. Приложение. 2013. №6. С. 58-59.
Девянин П. Н. Об опыте внедрения мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в защищенную ОС Astra Linux Special Edition // Методы и технические средства обеспечения безопасности информации. Материалы 22-й науч.-те
Операционные системы Astra Linux. http://www.astra-linux.ru/.
 Администрирование системы в рамках мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в ОС семейства Linux | ПДМ. 2013. № 4(22).

Администрирование системы в рамках мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в ОС семейства Linux | ПДМ. 2013. № 4(22).

Полнотекстовая версия