Two kinds of accessgraph closure are defined here for the role DP-model, and algorithms for the constructionof them are suggested in the paper. The results are aimed to verify for all the users, entitiesand access rights simultaneously if the predicate can_share() is true meaning the possibilityof taking ownership access rights of a trusted subject by an untrusted subject in a computersystem with discretionary access and information stream management.
Closure of basic role DP-model.pdf При анализе базовой ролевой (сокращенно: БР) ДП-модели в работе [1] были рассмотреныусловия передачи прав доступа ролей в случае взаимодействия только двухсубъект-сессий двух пользователей. В рамках обозначений и определений, введенныхв указанной работе, рассмотрим случай взаимодействия субъект-сессий произвольногочисла пользователей и предложим алгоритм, используя который можно осуществлятьпроверку истинности предиката can_share() для всех пользователей, сущностейи прав доступа одновременно, а вместе с ней и возможности получения недовереннымсубъектом права доступа владения к доверенному субъекту в компьютерных системахс дискреционным управлением доступом и информационными потоками. Такой алгоритмреализует преобразование начального состояния компьютерной системы (КС)в его замыкание. Дадим определения замыканий базовой ролевой ДП-модели, предложими обоснуем алгоритмы их построения.В соответствии с [1], в рамках БР ДП-модели при анализе условий передачи правдоступа, реализации информационных потоков по памяти или по времени возможноиспользование только монотонных правил преобразования состояний.Введем подмножество правил преобразования БР ДП-модели OPacs = {take_role(),grant_right(), crea te _ /irs t_ s e ss ion (), control(), access_own(), take_access_own(),access_write(), access_append(), post()}. Этих правил преобразования, согласно [1],достаточно для анализа условий передачи прав доступа ролей.Множество информационных потоков F в состоянии БР ДП-модели будем характеризоватьлишь множеством информационных потоков по памяти Fm С F . Этогодостаточно для проверки истинности указанного предиката.При создании недоверенным пользователем u . Nu субъект-сессии множествофункционально ассоциированных с этой сессией сущностей определяется только в зависимостиот пользователя и сущности, из которой эта субъект-сессия создана. Созданныесубъект-сессии различаются лишь функционально ассоциированными сущностями,а также ролью, которая получает право доступа владения к субъект-сессии,поэтому для анализа передачи прав доступа ролей и проверки истинности предикатаcan_share() достаточно рассмотреть по одной субъект-сессии, созданной каждымнедоверенным пользователем в следующих предположениях.Предп ол ожени е 1. Будем считать сущностями, функционально ассоциированнымис субъект-сессией, созданной из сущности у . E недоверенным пользователемu . Nu, такие сущности, функционально ассоциированные с сущностями z, для которых(z,executer) . PA(UA(u)) в данном или некотором последующем состоянии КС. (G * ,O P ).Предп ол ожени е 2. После создания недоверенным пользователем u . Nu с помощьюправила crea te _ /irs t_ s e ss ion () субъект-сессии z из сущности у . E с использованиемроли r . can_manage_rights(AUA(u)) к множеству PA(t) для каждогоt . can_manage_rights(AUA(u)) добавляется в качестве элемента пара (z,ownr).Определение 1. Состояние G' = (PA', user', roles', A', F ^ , HE/) системы .(G*,OP, G0) назовем role-замыканием, если оно получено из G0 = (PA0, user0, roles0,A 0,Fm0,H e0) применением последовательности правил crea te _ /irs t_ s e ss ion () и take_-role() и выполнены следующие условия:1) Vu . Nu 3!s . S'(user'(s) = u);2) Vx . S' (roles'(x) = UA(user'(x)) U AUA(user'(x))).А л гор и тм 1. Построение role-замыкания системы .(G*,OP, G0) для G0 = (PA 0,user0, roles0, A0, Fm0, HEo)1 Д ля в с е х u . Nu2 Взять произвольно r . can manage rights(AUA(u)) и у . E , такие, что(у, executer) . PA 0(UA(u))3 Выполнить crea te_/irst_session (u , r, у, z)4 Для в сех у . E5 Если (у, executer) . PA0(UA(u)), то6 [z] = [z] U7 Для в сех t . can_manage_rights(AUA(u))8 PA 0(t) ^ (z,ownr)9 Д ля в с е х x . S10 Для в сех r . UA(user0(x)) U AUA(user0(x))11 Выполнить take_role(x, r)Данный алгоритм строит role-замыкание непосредственно по определению в рамкахпредположений 1, 2.Определение 2. Состояние Gacs = (PA acs, useracs, rolesacs, Aacs, FmaCs, HEacs) системы.(G*, OP, G0) назовем access-замыканием, если оно получено из role-замыканияприменением последовательности правил из OPacs \ {crea te _ /ir s t_ s e s s ion (), take_-role()} и дальнейшее применение указанных правил не приводит к изменению состояниясистемы.Алгоритм 2. Построение access-замыкания Gacs = (PAacs, useracs, ro/esacs, Aacs,Fmacs, HEacs) системы .(G*, OP, Go) для Go = (PA, user, ro/es, A, Fm, He )1: Выполнить алгоритм 1. Получить ro/е-замыкание G = (PA, user, ro/es, A, Fm, He)системы E(G*, OP, G0)2: Gacs = G, список Aown пуст3: Выбрать произвольно k,/ G S, k = /, для которых 3r G ro/es(k) [(/,ownr) G PA(r)].Если таких k и / нет, то перейти на п. 344: Aacs = Aacs U (k, /, owna), добавить (k, /, owna) в конец списка Aown5: Выбрать очередной непомеченный элемент (x,y,owna) из списка Aown6: Для всех r G ro/esacs(x)7: Для всех e G E8: Если ((e,ownr),r) G PAacs(r) x can_manage_rights(ro/esacs(x) П AR) V((e,ownr),r) G ( U PAacs(r)) x can_manage_rights(ro/esacs(y) П AR),т €rolesacs(y)то9: Для всех (e, ar) G Pacs10: PAacs(r) = PAacs(r) U (e, a )11: Если ar = executer, то12: [x] = [x] U fa(useracs(x),e)13: Для всех e G E14: Если 3r G ro/esacs(x) U ro/esacs(y) [(e, writer) G PAacs(r)], то15: Aacs Aacs U { (^ ^ writea) }, Fmacs Fmacs U { (^ ^ }16: Если 3r G ro/esacs(x) U ro/esacs(y) [(e,appendr) G PAacs(r)], то17: Aacs = Aacs U {(x, e, appenda)}, Fmacs = Fmacs U {(x, y, Wrifem)}18: Замкнуть множество Aacs по транзитивности отношения владения с помощью правилаtake_access_own()19: Замкнуть список Aown по транзитивности отношения владения с помощью правилаtake_access_own(), добавляя результаты замыкания в конец списка20: Для всех z G S, z = х,21: Для всех e G E22: Если 3r G ro/esacs(z) [(e,readr) G PAacs(r)] V 3(z, k,owna) G Aacs [3r; Gro/esacs(k) A (e,readr) G PAacs (r')], то23: Если 3r G ro/esacs(x) U ro/esacs(y) [(e,writer) G PAacs(r) V (e,appendr) GPAacs(r)] V (x, e, writem) G Fmacs, то24: Fmacs Fmacs U {(x, z, writem)}25: Для всех n G S, n = x,26: Для всех e G [n]27: Если x = e V (x,e,writem) G Fmacs, то28: Aacs = Aacs U {(x, П, OWWa)}, добавить (x, П, 0№П„) в конец Aown29: Замкнуть множество Aacs по транзитивности отношения владения с помощью правилаtake_access_own()30: Замкнуть список Aown по транзитивности отношения владения с помощью правилаtake_access_own(), добавляя результаты замыкания в конец списка31: Пометить (x,y,owna) в Aown как рассмотренный32: Если в списке Aown есть непомеченные элементы, то33: Перейти на п. 534: Вернуть Gacs = (PAacs, Useracs, ro/esacs, Aacs, Fmacs, HEacs)Поясним работу алгоритма 2. Пусть построено role-замыкание системы .(G*, OP, G0).В этом состоянии доступы владения субъект-сессий отсутствуют. Это следует из определенияrole-замыкания и того, что применение правил grant_right() и take_role()не приводит к появлению доступов владения субъект-сессий. Новые же права доступаролей без возникновения доступов владения субъект-сессий появиться не могут. Этоследует из определения правила grant_right() и функции de_/acto_actions. Поэтомуна шаге 3 выполняется проверка возможности осуществления доступа владенияс помощью правила access_own(). Если этого сделать нельзя, то текущее состояниесистемы не изменится.В процессе работы алгоритма формируется список доступов владения субъект-сессий, в котором рассмотренные элементы помечаются. Данные доступы рассматриваютсяпоследовательно друг за другом. Алгоритм завершает свою работу, когдав списке не останется непомеченных элементов. Данное условие обязано выполнитьсяв силу конечности множества S и его неизменности в процессе работы алгоритма.Шаги 6-12 алгоритма соответсвуют выполнению правила grant_right(), причем нашаге 8 выполняется вычисление функции de_/acto_actions() для рассматриваемыхx и у. Шаг 12 соответствует корректировке функционально ассоциированных сущностейв рамках предположения 1. Шаги 13-17 соответствуют применению правилaccess_write и access_append, шаги 20-24 - правила post(), шаги 25-28 - правилаcontrol (). Правила преобразований рассматриваются в порядке влияния примененияодного правила на возможные аргументы других, причем после шага 30 никакоеприменение правила из OPacs \ (create_/irst_session(), take_role()} с учетом толькодоступа владения (x^ ow n a ) не изменит текущего состояния системы.