— возможность изменения функциональности субъекта при реализации информационного потока по памяти на функционально ассоциированные с ним сущности;
— необходимость в ряде случаев определения различных правил управления доступом и информационными потоками для распределенных компонент КС.
В связи с этим при наличии возможности при преподавании дисциплины «Теоретические основы компьютерной безопасности» целесообразно рассмотреть подходы, примененные при разработке семейства моделей безопасности логического управления доступом и информационными потоками (ДП-моделей) КС с дискреционным, мандатным или ролевым управлением доступом [3]. При этом наиболее существенными моделями семейства являются дискреционная базовая ДП-модель, ДП-модель с функционально ассоциированными с субъектами сущностями (ФАС ДП-модель), мандатная ДП-модель и базовая ролевая ДП-модель.
Все рассмотренные модели войдут в разрабатываемое автором учебное пособие «Модели безопасности компьютерных систем», второе издание которого планируется в 2010 году.
ЛИТЕРАТУРА
1. Девянин П. Н. Модели безопасности компьютерных систем: Учеб. пособие для студ. высш. учеб. заведений. М.: Академия, 2005. 144 с.
2. Bishop M. Computer Security: art and science. ISBN 0-201-44099-7, 2002. 1084 p.
3. Девянин П. Н. Анализ безопасности управления доступом и информационными потоками в компьютерных системах. М.: Радио и связь, 2006. 176 с.
УДК 004.94
ЗАМЫКАНИЕ БАЗОВОЙ РОЛЕВОЙ ДП-МОДЕЛИ
М. А. Качанов
При анализе базовой ролевой (сокращенно: БР) ДП-модели в работе [1] были рассмотрены условия передачи прав доступа ролей в случае взаимодействия только двух субъект-сессий двух пользователей. В рамках обозначений и определений, введенных в указанной работе, рассмотрим случай взаимодействия субъект-сессий произвольного числа пользователей и предложим алгоритм, используя который можно осуществлять проверку истинности предиката can_share() для всех пользователей, сущностей и прав доступа одновременно, а вместе с ней и возможности получения недоверенным субъектом права доступа владения к доверенному субъекту в компьютерных системах с дискреционным управлением доступом и информационными потоками. Такой алгоритм реализует преобразование начального состояния компьютерной системы (КС) в его замыкание. Дадим определения замыканий базовой ролевой ДП-модели, предложим и обоснуем алгоритмы их построения.
В соответствии с [1], в рамках БР ДП-модели при анализе условий передачи прав доступа, реализации информационных потоков по памяти или по времени возможно использование только монотонных правил преобразования состояний.
Введем подмножество правил преобразования БР ДП-модели OPaCs = {take_role(), grant_right(), create_first_session(), control(), access_own(), take_access_own(), access _write(), access_append(), post()}. Этих правил преобразования, согласно [1], достаточно для анализа условий передачи прав доступа ролей.
Множество информационных потоков F в состоянии БР ДП-модели будем характеризовать лишь множеством информационных потоков по памяти Fm Ç F. Этого достаточно для проверки истинности указанного предиката.
При создании недоверенным пользователем u G Nu субъект-сессии множество функционально ассоциированных с этой сессией сущностей определяется только в зависимости от пользователя и сущности, из которой эта субъект-сессия создана. Созданные субъект-сессии различаются лишь функционально ассоциированными сущностями, а также ролью, которая получает право доступа владения к субъект-сессии, поэтому для анализа передачи прав доступа ролей и проверки истинности предиката can_share() достаточно рассмотреть по одной субъект-сессии, созданной каждым недоверенным пользователем в следующих предположениях.
Предположение 1. Будем считать сущностями, функционально ассоциированными с субъект-сессией, созданной из сущности y G E недоверенным пользователем u G Nu, такие сущности, функционально ассоциированные с сущностями z, для которых (z,executer) G PA(UA(u)) в данном или некотором последующем состоянии КС
E(G*,OP ).
Предположение 2. После создания недоверенным пользователем u G Nu с помощью правила create_first_session() субъект-сессии z из сущности y G E с использованием роли r G can_manage_rights(AUA(u)) к множеству PA(t) для каждого t G can_manage_rights(AUA(u)) добавляется в качестве элемента пара (z,ownr).
Определение 1. Состояние G' = (PA',user',roles',A',F'm,HE/) системы T.(G*, OP, G0) назовем role-замыканием, если оно получено из G0 = (P A0,user0,roles0,A0, Fm0 ,He0) применением последовательности правил create_first_session() и take_-role() и выполнены следующие условия:
1) Vu G Nu 3!s G S'(user'(s) = u);
2) Vx G S' (roles'(x) = UA(user'(x)) U AUA(user'(x))).
Алгоритм 1. Построение role-замыкания системы T.(G*,OP,G0) для ,o Ao o Go
usero, roleso, Ao, Fm0, He0)
1 Для всех u G Nu
2 Взять произвольно r G can manage rights(AUA(u)) и y G E, такие, что
(y,executer) G PA0(UA(u))
3 Выполнить create_first_session(u, r, y, z)
4 Для всех y G E
5 Если (y,executer) G PA0(UA(u)), то
6 [z] = [z] U fa(u,y)
7 Для всех t G can_manage_rights(AUA(u))
8 PA0(t) ^ (z,ownr)
9 Для всех x G S
10 Для всех r G UA(user0(x)) U AUA(user0(x))
11 Выполнить take_role(x, r)
Данный алгоритм строит role-замъlкание непосредственно по определению в рамках предположений 1,2.
Определение 2. Состояние Gacs = (PAacs,useracs,rolesacs, Aacs, Fmacs, HEac3) системы T,(G*, OP, G0) назовем access-замыканием, если оно получено из role-замыкания применением последовательности правил из OPacs \ {create_first_session(), take_-role()} и дальнейшее применение указанных правил не приводит к изменению состояния системы.
Алгоритм 2. Построение access-замыкания Gacs = (PAacs, useracs, rolesacs, Aacs, Fmacs, HKcs) системы E(G*,OP,Go) для Go = (PA, user, roles, A, Fm, He)
1: Выполнить алгоритм 1. Получить role-замыкание G = (PA, user, roles, A, Fm, He) системы T.(G*,OP,G0)
2: Gacs = G, список Aown пуст
3: Выбрать произвольно k,l Є S,k = l, для которых 3r Є roles(k) [(l,ownr) Є PA(r)].
Если таких k и l нет, то перейти на п. 34 4: Aacs = Aacs U (k,l, owna), добавить (k,l, owna) в конец списка Aown 5: Выбрать очередной непомеченный элемент (x,y,owna) из списка Aown 6: Для всех r Є rolesacs(x)
7: Для всех e Є E
8: Если ((e,ownr),r) Є PAacs(r) x can_manage_rights(rolesacs(x) П AR) V
((e,ownr),r) Є ( U PAacs(r)) x can_manage_rights(rolesacs(y) П AR),
T erolesacs(y)
то
9: Для всех (e, ar) Є Pacs
10: PAacs (r) = PAacs(r) U (e, a)
11: Если ar = executer, то
12: [x] = [x] U fa(useracs(x),e)
13: Для всех e Є E
14: Если 3r Є rolesacs(x) U rolesacs (y) [(e,writer) Є PAacs(r)], то
15: Aacs Aacs U {(x, e, writea')}, Fmacs Fmacs U {(xi yi writem)}
16: Если 3r Є rolesacs(x) U rolesacs(y) [(e,appendr) Є PAacs(r)], то
17: Aacs = Aacs U {(x, e, appcnda)}, Fmacs = Fmacs U {(x, y, writem)}
18: Замкнуть множество Aacs по транзитивности отношения владения с помощью правила take_access_own()
19: Замкнуть список Aown по транзитивности отношения владения с помощью правила take_access_own(), добавляя результаты замыкания в конец списка 20: Для всех z Є S, z = x,
21: Для всех e Є E
22: Если 3r Є rolesacs(z) [(e,readr) Є PAacs(r)] V 3(z,k,owna) Є Aacs [3r; Є
rolesacs(k) A (e, readr) Є PAacs (r')], то 23: Если 3r Є rolesacs(x) U rolesacs(y) [(e,writer) Є PAacs(r) V (e,appendr) Є
PAacs(r)] V (x,e, writem) Є Fmacs, то
24: Fmacs Fmacs U {(xi z,writem')}
25: Для всех n Є S,n = x,
26: Для всех e Є [n\
27: Если x = e V (x,e,writem) Є Fmacs, то
28: Aacs = Aacs U {(x, П, owna)}, добавить (x,n, owna) в конец Aown
29: Замкнуть множество Aacs по транзитивности отношения владения с помощью правила take _access _own()
30: Замкнуть список Aown по транзитивности отношения владения с помощью правила take_access_own(), добавляя результаты замыкания в конец списка 31: Пометить (x,y,owna) в Aown как рассмотренный 32: Если в списке Aown есть непомеченные элементы, то 33: Перейти на п. 5
34: Вернуть Gacs = (PAacs, useracs, rolesacs, Aacs, Fmacs, HEacs)
Поясним работу алгоритма 2. Пусть построено role-замыкание системы T.(G*, OP, G0). В этом состоянии доступы владения субъект-сессий отсутствуют. Это следует из определения role-замыкания и того, что применение правил grant_right() и take_role() не приводит к появлению доступов владения субъект-сессий. Новые же права доступа ролей без возникновения доступов владения субъект-сессий появиться не могут. Это следует из определения правила grant_right() и функции de_facto_actions. Поэтому на шаге 3 выполняется проверка возможности осуществления доступа владения с помощью правила access_own(). Если этого сделать нельзя, то текущее состояние системы не изменится.
В процессе работы алгоритма формируется список доступов владения субъект-сессий, в котором рассмотренные элементы помечаются. Данные доступы рассматриваются последовательно друг за другом. Алгоритм завершает свою работу, когда в списке не останется непомеченных элементов. Данное условие обязано выполниться в силу конечности множества S и его неизменности в процессе работы алгоритма.
Шаги 6-12 алгоритма соответсвуют выполнению правила grant_right(), причем на шаге 8 выполняется вычисление функции de_facto_actions() для рассматриваемых x и у. Шаг 12 соответствует корректировке функционально ассоциированных сущностей в рамках предположения 1. Шаги 13-17 соответствуют применению правил access_write и access_append, шаги 20-24 — правила post(), шаги 25-28 — правила control (). Правила преобразований рассматриваются в порядке влияния применения одного правила на возможные аргументы других, причем после шага 30 никакое применение правила из OPacs \ {create_first_session(), take_role()} с учетом только доступа владения (x,y,owna) не изменит текущего состояния системы.
ЛИТЕРАТУРА
1. Девянин П. Н. Базовая ролевая ДП-модель // Прикладная дискретная математика. 2008.
№1(1). С. 64-70.
УДК 004.94
ПОДХОДЫ К ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ КОМПЬЮТЕРНЫХ СИСТЕМ С ФУНКЦИОНАЛЬНО ИЛИ ПАРАМЕТРИЧЕСКИ АССОЦИИРОВАННЫМИ СУЩНОСТЯМИ
Д. Н. Колегов
В настоящее время одной из актуальных задач теории компьютерной безопасности является разработка математических моделей безопасности современных компьютерных систем (КС), реализующих управление доступом и информационными потоками. Данная задача возникает как при теоретическом анализе безопасности КС с применением их формальных моделей, так и при тестировании механизмов защиты КС с использованием процедур, методов и средств автоматизации и компьютерного моделирования. На необходимость формализации процедур оценки безопасности, разработки общих методологий и моделей угроз безопасности КС указывается в «Концепции оценки соответствия автоматизированных систем требованиям безопасности информации» [1]. Более того, в соответствии с «Критериями оценки безопасности информационных технологий» [2] для КС с высоким уровнем доверия обязательным является разработка формальной модели их политики безопасности управления доступом и информационными потоками.