CC BY
64
2016 Математические основы компьютерной безопасности № 1(31)
МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ
УДК 004.94
ПРАВИЛА ПРЕОБРАЗОВАНИЯ СОСТОЯНИЙ СИСТЕМЫ В РАМКАХ ДП-МОДЕЛИ УПРАВЛЕНИЯ ДОСТУПОМ В КОМПЬЮТЕРНЫХ СЕТЯХ, ПОСТРОЕННЫХ НА ОСНОВЕ ОС СЕМЕЙСТВА LINUX
В. Ю. Тележников
Учебно-методическое объединение по образованию в области информационной
безопасности, г. Москва, Россия
Рассматривается мандатная сущностно-ролевая ДП-модель управления доступом в компьютерных сетях ОС семейства Linux, построенная на основе МРОСЛ ДП-модели. В рамках данной модели уточняются существующие и задаются новые де-юре правила преобразования состояний системы, позволяющие учитывать особенности функционирования рассматриваемых компьютерных сетей, обосновывается корректность их задания относительно требований, предъявляемых к мандатному и ролевому управлению доступом. Наличие новых правил преобразования состояний позволяет более детально описывать спецификации механизмов управления доступом, что нацелено на построение теоретически обоснованных локальных и сетевых подсистем безопасности компьютерных сетей.
Ключевые слова: компьютерные сети, модели безопасности, операционная система Linux, ДП-модели.
DOI 10.17223/20710410/31/7
SYSTEM STATE TRANSFORMATION RULES IN DP-MODEL OF ACCESS CONTROL IN COMPUTER NETWORKS BASED ON OPERATING SYSTEMS OF LINUX
V. Y. Telezhnikov EMA IS, Moscow, Russia E-mail: [email protected]
When modern computer systems (CS) are created, a big attention is paid to theoretical explanation of their access control security mechanisms. For this aim, some formal models are built and mandatory MROSL DP-model is the most developed of them. However, it is important to consider peculiarities of logical access control organization in computer networks and the existence of different security policies of network stations. MROSL DP-model and other models known to the author do not take this into account. Besides, it is necessary to provide flexible specification of access control to network resources in the context of theoretical models of logical access control in computer systems including hundreds and thousands users. The simple mechanism of access control administration is also needed. The author is building new mandatory
object-role access control DP-model for the computer systems based on OS of Linux family (MROCS DP-model) relying on MROSL DP-model in order to consider mentioned peculiarities. Existing de-jure rules of system state transformation are refined and new ones are specified in the context of this model for the purpose of taking into account peculiarities of functioning CS under consideration. These changes allow to describe in details specifications of access control mechanisms. Besides, the correctness of these rules with respect to mandatory and role-based access control requirements is shown, so it makes possible to construct theory-based network security subsystem of CS. De-jure rules of state transformation in MROCS DP-model connected with the organization of logical access control in the context of CS are directed to realization in special operating system Astra Linux Special Edition.
Keywords: computer networks, operating systems of Linux, DP-model.
Введение
При создании современных автоматизированных систем большое внимание уделяется теоретическому обоснованию безопасности их механизмов управления доступом. Для этого строятся формальные модели логического управления доступом, наиболее развитой из которых является мандатная сущностно-ролевая ДП-модель управления доступом и информационными потоками в защищённых ОС семейства Linux (МРОСЛ ДП-модель) [1, 2]. Одним из примеров её состоятельности является тот факт, что в настоящее время широкое распространение получила ОС специального назначения (ОССН) Astra Linux Special Edition [3], реализующая мандатное управление доступом, развитие которой ведётся в направлении адаптации её подсистемы безопасности к требованиям МРОСЛ ДП-модели с учётом поддержки мандатной политики целостности и ролевого управления доступом. Вместе с тем при объединении ОС в сеть целесообразно принимать во внимание особенности организации логического управления доступом к сетевым объектам, наличие различных политик безопасности рабочих станций сети, которые не учитываются как в МРОСЛ ДП-модели, так и в других известных автору формальных моделях. При этом в рамках теоретических моделей логического управления доступом в сетях, в которых одновременно могут работать сотни и тысячи пользователей, необходимо предусмотреть возможность гибкого задания прав доступа к ресурсам сети; они должны также обладать простым механизмом администрирования. С целью учёта этих особенностей на основе МРОСЛ ДП-модели автором ведётся построение новой мандатной сущностно-ролевой ДП-модели управления доступом в компьютерных сетях, построенных на основе ОС семейства Linux (МРОКС ДП-модели), которую можно будет использовать для создания теоретически обоснованного механизма защиты ОС, способных функционировать в рамках сети.
1. Основные элементы МРОКС ДП-модели
В силу того, что разработка новой модели ведётся на основе МРОСЛ ДП-модели, принятые в ней обозначения используются при изложении МРОКС ДП-модели.
В МРОКС ДП-модели рабочей станции сети соответствует любой отдельный персональный компьютер либо сервер сети, каждый из которых оборудован сетевым адаптером. При этом в описании модели предполагается, что заранее известны рабочие станции, которые могут функционировать в рамках сети:
— ш — количество рабочих станций, которые могут функционировать в сети, ш ^ 1;
— и — количество инициализированных (подключённых) рабочих станций сети в заданный момент времени, 1 ^ и ^ ш;
— WU Е U — множество специальных учётных записей (учётная запись-компьютер), каждая из которых соответствует отдельной рабочей станции сети.
В реальных компьютерных сетях есть возможность управления доступом на уровне рабочей станции сети, когда доступ предоставляется или запрещается, исходя не только из того, от имени какой учётной записи он осуществляется и к какому ресурсу, но и из того, какие рабочие станции при этом взаимодействуют. Для возможности отражения подобных ситуаций задаются новые множества и функции.
В МРОКС ДП-модели каждой рабочей станции, которая может функционировать в рамках сети, соответствуют отдельные подмножества субъект-сессий и сущностей сети:
— Si — множество субъект-сессий рабочей станции сети, где 1 ^ i ^ ш;
— Ei = Oi U Ci — множество сущностей рабочей станции сети, где Oi — множество объектов, Ci — множество контейнеров и Oi П Ci = 0, 1 ^ i ^ ш;
— OSi С Oi — множество объектов-сокетов рабочей станции сети, где 1 ^ i ^ ш. Замечание 1. В множество сущностей рабочих станций сети необходимо включить все сущности реальной ОС, к которым требуется назначать права доступа. Применительно к ОС семейства Linux такими объектами являются: регулярные (обычные) файлы, директории, символьные ссылки, файлы блочных устройств, специальные файлы устройств, сокеты, именованные каналы. В качестве сущностей следует рассматривать и отдельные файловые системы в совокупности. Среди всех сущностей только директории относятся к сущностям-контейнерам. Все остальные являются сущностями-объектами. Такие объекты файловых систем, как жёсткие ссылки, относятся также к сущностям-объектам и позволяют помещать их сразу в несколько сущностей-контейнеров.
В качестве субъект-сессий необходимо рассматривать все активные сущности ОС — «демоны», системные и прикладные (пользовательские) процессы, а также возможные их совокупности, например процессы, выполняющие одну задачу в рамках системы. В том случае, когда ОС функционирует в компьютерной сети, целесообразно рассматривать данную ОС в качестве самостоятельной субъект-сессии, которой будут подчинены все остальные субъект-сессии в иерархии, заданной на множестве субъект-сессий в МРОСЛ ДП-модели [1].
В множество объектов-сокетов необходимо включать все виды объектов реальной ОС, взаимодействие с которыми организуется через интерфейс сокетов и которые предназначены для предоставления доступа к ресурсам удалённых рабочих станций сети. Стоит отметить, что применительно к ОС семейства Linux интерфейс сокетов используется для работы как с сетевыми, так и с файловыми сокетами. Однако файловые сокеты используются как механизм межпроцессного взаимодействия в рамках одной рабочей станции, поэтому в МРОКС ДП-модели элементами множества OS являются только сетевые сокеты. При этом, с учётом специфики функционирования ОС семейства Linux (невозможность создания «жёстких» ссылок на сетевые сокеты, размещение их в корне псевдофайловой системы), все сетевые сокеты отдельной рабочей станции сети содержатся в единственной сущности-контейнере: существует единственная сущность-контейнер c Е C, такая, что для любого объекта-сокета os Е OS выполняется os Е He(c), то есть область значения функции H-1(OS) соответствует множеству, состоящему из одной сущности-контейнера.
Для любого 1 ^ i ^ ш из множества субъект-сессий выделяется множество сетевых субъект-сессий рабочей станции сети SNi С Si.
Для ОС, функционирующей на рабочей станции сети, задаётся отдельный элемент множества сетевых субъект-сессий: wsui Е SNi — сетевая субъект-сессия, соответствующая отдельной рабочей станции в рамках сети; CSN = {wsui,wsu2,... ,wsuM} — множество сетевых субъект-сессий, каждая из которых соответствует отдельной рабочей станции, которая может функционировать в сети.
Замечание 2. В множество сетевых субъект-сессий SN входят те процессы системы, которые являются участниками сетевого соединения с удалёнными рабочими станциями сети. При этом только в процессе функционирования сетевых субъект-сессий представляется возможным получить какой-либо удалённый доступ к ресурсам сети. В рамках разрабатываемой МРОКС ДП-модели отдельные рабочие станции сети являются сетевыми субъект-сессиями системы. Таким образом, сетевые субъект-сессии, входящие во множество CSN, представляют собой отдельные рабочие станции сети, участвующие в сетевом взаимодействии. В качестве такой сетевой субъект-сессий возможно рассматривать процесс init, запущенный на каждой отдельной рабочей станции сети.
Замечание 3. В МРОСЛ ДП-модели [1] для любой учётной записи пользователя задаётся соответствующая только ей индивидуальная роль. Исходя из этого, предлагается на практике обеспечить возможность функционирования каждой субъект-сессии wsui от имени учётной записи пользователя u Е WU, идентификатор которой будет уникальным в рамках всей рассматриваемой сети. Благодаря этому и в силу того, что их индивидуальные роли также уникальны, субъект-сессии wsui единственным образом ставится в соответствие конкретная рабочая станция сети. Используем следующие обозначения:
— csu_iuitialized : CSN ^ {true, false} — функция принадлежности рабочей станции к множеству инициализированных рабочих станций сети, такая, что для любого i, где 1 ^ i ^ ш, рабочая станция считается инициализированной, если для соответствующей ей сетевой субъект-сессии wsui Е SNi выполняется csu_iuitialized(wsui) = true, в противном случае wsui выполняется на изолированной рабочей станции сети;
— csu_accessory : (Ei U ... U Еш) U (Si U ... U Sw) ^ CSN — функция принадлежности субъект-сессий и сущностей к рабочей станции сети, такая, что для сущности или субъект-сессии e_s Е (Ei U ... U Еш) U (Si U ... U Su) существует единственное i, 1 ^ i ^ ш, такое, что csu_accessory(e_s) = wsui. По определению csru_accessory(wsrui) = wsui, 1 ^ i ^ ш.
Замечание 4. В тот момент, когда происходит подключение (инициализация) компьютера к сети, в множество субъект-сессий и сущностей сети добавляются множества субъект-сессий и сущностей, принадлежащих инициализируемой рабочей станции. При этом подразумевается, что заданные параметры функционирования инициализируемой рабочей станции удовлетворяют всем требованиям к реализации мандатного и ролевого управления доступом, предъявляемым к уже инициализированным рабочим станциям сети.
Таким образом, задаются непересекающиеся подмножества сущностей и субъект-сессий, принадлежащих отдельным рабочим станциям, которые могут функционировать в рамках сети:
— для любой субъект-сессии s Е Si выполняется csu_accessory(s) = wsui, 1 ^ i ^ ш;
— для любой сущности e Е Ei выполняется csu_accessory(e) = wsui, 1 ^ i ^ ш;
— для 1 ^ i < j ^ ш выполняется Si П Sj = 0, Ei П Ej = 0.
Множества субъект-сессий и сущностей различных инициализированных рабочих станций объединяются в множества субъект-сессий и сущностей сети соответственно:
— S = SilUSi2 U.. .US^ и для wsnij Е SNij выполняется csn_initialized(wsnij) = true, где 1 ^ j ^ и и 1 ^ ij ^ ш;
— E = Eil U Ei2 U ... U Eiv и для wvsni. Е SNi. выполняется csn _initialized(w sni.) = = true, где 1 ^ j ^ и и 1 ^ ij ^ ш.
Замечание 5. В МРОСЛ ДП-модели [1] учитывается, что ОС семейства Linux предоставляют возможность создания «жёстких» ссылок на объекты файловой системы. Это приводит к тому, что в рамках модели одна и та же сущность-объект (файл) может содержаться в нескольких сущностях-контейнерах (директориях). Однако это верно только для сущностей в рамках любой отдельной рабочей станции сети, так как «жёсткая» ссылка не может выходить за пределы файловой системы, в которой находится объект, на который она ссылается. Поэтому невозможно создать «жёсткую» ссылку на удалённой рабочей станции сети и, как следствие, определение функции csn_accessory корректно относительно создания «жёстких» ссылок.
Пусть IS С OS х OS — множество установленных соединений между объектами-со-кетами, используемых субъект-сессиями для передачи данных между собой. По определению если (osi,osj) Е IS, то (osj,osj) Е IS, где osj,, osj Е OS, 1 ^ i, j ^ ш и csn _initialized(w su) = csn _initialized(w snj) = true.
Замечание 6. Под установленным соединением будем понимать пару связанных между собой сокетов, используемых для передачи данных между субъект-сессиями посредством интерфейса сокетов с применением сетевых протоколов, ориентированных на установление соединения (например, TCP).
Теоретические модели компьютерных сетей, в которых одновременно могут работать сотни и тысячи пользователей, должны предоставлять возможность гибкого задания прав доступа к ресурсам сети и обладать простым механизмом администрирования ролевого управления доступа. Для этих целей в рамках разрабатываемой автором МРОКС ДП-модели наряду с множествами ролей и административных ролей задаётся новое множество запрещающих ролей, отличительная особенность которых в ограничении прав доступа пользователей, обладающих ими. Используем следующие обозначения:
— R — множество ролей;
— AR — множество административных ролей, при этом по определению AR П R = 0;
— UR — множество запрещающих ролей, ограничивающих права доступа к сущностям, при этом по определению R П UR = 0 и AR П UR = 0.
Отличительная особенность запрещающих ролей в том, что через них задается множество тех прав доступа к сущностям, которые не должна получить субъект-сессия, функционирующая от имени учётной записи пользователя, права доступа которой необходимо ограничить.
Замечание 7. Отсутствие множества запрещающих административных ролей объясняется тем, что число ролей и запрещающих ролей, используемых в реальных ОС, значительно меньше числа сущностей системы, что позволяет гибко задавать административные права доступа к ролям, запрещающим ролям при наличии только административных ролей.
На множестве запрещающих ролей задаётся иерархия аналогично тому, как задаётся иерархия на множестве ролей в МРОСЛ ДП-модели [1].
Определение 1. Иерархией запрещающих ролей называется заданное на множестве запрещающих ролей UR отношение частичного порядка ^. При этом по определению справедливо: для административной роли ar Е AR, если запрещающие роли ur',ur Е UR таковы, что (ur,readr) Е APA(ar) и ur' ^ ur, то выполняется условие (ur', readr) Е APA(ar). При этом по определению роли, запрещающие роли и административные роли несравнимы между собой, т. е. их иерархии считаются независимыми.
Множества Rr видов прав доступа, Ra видов доступа, Rf видов информационных потоков (по памяти и по времени) и P прав доступа к сущностям и субъект-сессиям задаются аналогично МРОСЛ ДП-модели [1]:
— Rr = {readr ,writer, executer, ownr} —множество видов прав доступа;
— Ra = {reada, writea} —множество видов доступа;
— Rf = {writem,writet} —множество видов информационных потоков (по памяти и по времени);
— P С (E х Rr) U (S х {ownr}) —множество прав доступа к сущностям и субъект-сессиям.
При этом следующие множества переопределяются с учётом введения запрещающих ролей:
— AP С (R U UR U AR) х Rr — множество административных прав доступа к ролям, запрещающим ролям или административным ролям;
— AA С S х (R U UR U AR) х Ra — множество доступов субъект-сессий к ролям, запрещающим ролям или административным ролям;
— F С (E US UR UURUAR)х(E U S UR UURUAR)хRf — множество информационных потоков;
— PA : R U UR U AR ^ 2P — функция прав доступа к сущностям ролей, запрещающих ролей и административных ролей (для запрещающих ролей право доступа владения к сущностям не задаётся);
— APA : AR ^ 2ap — функция административных прав доступа к ролям, запрещающим ролям и административным ролям административных ролей.
Вместе с тем такие множества, как P и AA представляют собой объединение соответствующих множеств, заданных для каждой инициализированной рабочей станции сети, при этом 1 ^ i ^ ш и csn_initialized(wsni) = true:
— Pi С (Ei х Rr) U (Si х {ownr}) —множество прав доступа к сущностям и субъект-сессиям, содержащимся на рабочей станции сети wsni (для y Е Ei U Si выполняется csn_accessory(y) = wsni);
— AAi С Si х (R U UR U AR) х Ra — множество административных доступов субъект-сессий рабочей станции wsni к ролям, запрещающим ролям или административным ролям (для s Е Sj, выполняется csn_accessory(s) = wsni).
С учётом этого, для 1 ^ i ^ ш задаются отдельные функции прав доступа:
— PAi : R U UR U AR ^ 2Pi — функция прав доступа к сущностям рабочей станции сети wsni ролей, запрещающих ролей и административных ролей.
Множества A и F, помимо этого, включают в себя соответственно множества доступов и информационных потоков, возникающих между субъект-сессиями и сущностями различных инициализированных рабочих станций сети, где 1 ^ i ^ ш, 1 ^ j ^ ш и csn_initialized(wsnj) = csn _initialized(w snj) = true:
— Aij С Si х Ej х Ra — множество доступов субъект-сессий рабочей станции сети wsUi к сущностям рабочей станции wsUj (для s € Si верно csu_accessory(s) = wsui} для e € Ej выполняется csn _accessory(e) = wsUj);
— Fij С (Ei U Si U R U UR U AR) х (Ej U Sj U R U UR U AR) х Rf — множество информационных потоков между рабочими станциями wsui и wsUj.
Множество функций Constraint apa, задающих ограничение на значения множеств административных прав доступа административных ролей, является одинаковым для всех рабочих станций сети. Множества функций ConstraintPA и ConstraintAA задаются отдельно для каждой рабочей станции сети.
Права доступа административных ролей AR к запрещающим ролям UR интерпретируются следующим образом:
— executer —право обращаться к ролям, подчинённым данной роли в иерархии запрещающих ролей;
— наличие права доступа readr к запрещающей роли указывает на необходимость включения роли во множество текущих ролей субъект-сессии: если x € S и существует ar € AR, такая, что (x, ar, reada) € AA, то для любой запрещающей роли ur € UR, для которой (ur,readr) € PA(ar), выполняется (x,ur,reada) € AA;
— writer — право изменять множество прав доступа запрещающей роли. Замечание 8. Для возможности назначения «принудительного» (при получении
доступа на чтение к административной роли) доступа reada к запрещающим ролям в рамках МРОКС ДП-модели предполагается, что не существует параметрически ассоциированных с ними сущностей: для запрещающей роли ur € UR верно равенство }ur[= 0.
Используем следующее обозначение:
— network_role : RU UR U AR ^ {true, false} — функция сетевых ролей, такая, что роль, запрещающая роль или административная роль r € R U UR U AR является сетевой, когда network_role(r) = true, в противном случае network_role(r) = = false (локальная роль).
Замечание 9. Функция network_role позволяет определить множество тех ролей, обладание которыми даёт возможность субъект-сессиям участвовать в процессе обмена данными между рабочими станциями по сети. Например, можно выделить роли, доступные учётным записям пользователей независимо от рабочей станции в масштабах всей сети; все остальные роли предназначены для локального использования на конкретной рабочей станции. Для реализации данной функции на практике необходимо либо по умолчанию при получении доступа к удалённым ресурсам учитывать наличие только сетевых ролей, либо предлагать пользователю получить в качестве текущих ролей те необходимые роли r € R U UR U AR, для которых network_role(r) = true. При реализации первого подхода в рамках отдельной рабочей станции сети пользователю доступны все соответствующие ему авторизованные роли, независимо от значения функции network_role, а в процессе управления доступом к данным, передаваемым по сети, учитываются права доступа только сетевых ролей, имеющихся в множествах текущих ролей соответствующих субъект-сессий.
Отметим, что рабочим станциям сети в рамках модели соответствуют субъект-сессии, к которым в МРОСЛ ДП-модели [1] может задаваться только право доступа ownr. Для обеспечения гибкого управления доступом (задания прав доступа readr, writer и т.д., что позволит при получении доступа к сущностям учитывать, на ка-
ких рабочих станциях сети они находятся) к удалённым рабочим станциям сети (т. е. соответствующей субъект-сессии) введём следующие обозначения:
— NR С R — множество ролей удалённого доступа, при этом по определению для любой роли rur Е NR выполняется uetwork_role(ur) = true (обладание данными ролями даёт возможность обращения к ресурсам удалённых рабочих станций, в том числе серверов сети);
— NUR С UR — множество запрещающих ролей удалённого доступа, при этом по определению для любой роли uur Е NUR выполняется uetwork_role(uur) = true (обладание данными ролями может запретить обращение к ресурсам удалённых рабочих станций, в том числе серверов сети).
Замечание 10. Для каждой рабочей станции сети существует единственная сущ-ность-«макроконтейнер», в которой содержатся все сущности данной рабочей станции. К ней могут быть заданы права доступа для ролей удалённого доступа: для любого 1 ^ i ^ ш существует единственная сущность-«макроконтейнер» em Е Ci, такая, что csu_accessory(em) = wsu и для любой сущности e Е Ei, e = em, выполняется e < em. Все сущности-«макроконтейнеры» объединяются в единое множество EM С C, где EM = {emi,..., emM} и csu_accessory(emj) = wsui для любого 1 ^ i ^ ш.
Замечание 11. Сущностью-«макроконтейнером» в реальных ОС семейства Liuux может являться корневой каталог, который обозначается «/». Именно к нему задаются права доступа для ролей удалённого доступа, на основе которых принимается решение о возможности обращения (установления сетевого соединения) к ресурсам удалённой рабочей станции сети. Права доступа всех остальных ролей к сущностям-«макрокон-тейнерам» интерпретируются традиционным образом. Таким образом, возможность получения запрашиваемого доступа к сущностям удалённой рабочей станции сети зависит не только от множества текущих ролей и мандатных атрибутов доступа субъект-сессии, но и от рабочей станции сети, на которой она функционирует.
Зададим административные роли:
— admiu_uet Е ADMIN_ROLES, получение доступа reada к которой необходимо для администрирования ролей сетевого доступа из NR (изменение множества прав доступа к сущностям-«макроконтейнерам»);
— admiu_csu Е ADMIN_ROLES, получение доступа reada к которой необходимо для администрирования удалённых рабочих станций сети.
При этом по определению для заданных административных ролей выполняется uetwork_role(admiu_csu) = true, uetwork_role(admiu_uet) = true, ir (admiu_uet) = ir (admiu_csu) = i_high.
2. Правила задания мандатного и ролевого управления доступом
С целью задания порядка предоставления прав доступа к сущностям для ролей и запрещающих ролей удалённого доступа и доступов субъект-сессий к ним сделаем предположение.
Предположение 1. В МРОКС ДП-модели выполняются следующие условия. Условие 1. Административное право доступа readr к ролям и запрещающим ролям удалённого доступа задаётся только для индивидуальных административных ролей учётных записей-компьютеров WU С U: для ролей удалённого доступа ur Е NR, если административная роль ar Е AR и (ur,readr) Е APA(ar), то ar Е {u_admiu_i_high : u Е WU}.
Условие 2. Для каждой учётной записи-компьютера и для каждого уровня конфиденциальности, не превышающего уровня конфиденциальности этой учётной записи, задана по крайней мере одна (количество может зависеть, например, от числа сетевых интерфейсов) индивидуальная роль удалённого доступа, на которую авторизована данная учётная запись: для каждой wu Е WU и каждого уровня конфиденциальности l ^ fu(wu) существует роль удалённого доступа wu_nr_l_li Е NR, такая, что (wu_nr_l_li,readr) Е APA(wu_admin_li), fr(wu_nr_l_li) = l и ir(wu_nr_l_li) = = iu(wu), li Е LI, где LI = {i_low, i_high} —множество уровней целостности данных, i_low < i_high.
Условие 3. Доступ на чтение к ролям и запрещающим ролям удалённого доступа могут получить только субъект-сессии, соответствующие рабочим станциям сети: для субъект-сессии s Е S \ CSN и роли r Е NR U NUR выполняется (s, r, reada)EAA.
Условие 4. Для создания, удаления, переименования, изменения иерархии ролей удалённого доступа, назначения к ним прав доступа административных ролей, а также для изменения их прав доступа к сущностям-«макроконтейнерам» субъект-сессия должна обладать доступом на чтение к административной роли admin_net.
Замечание 12. При попытке сетевой субъект-сессии Si получить доступ к сущности ej Е Ej, находящейся на удалённой рабочей станции сети wsnj, первоначально на рабочей станции сети wsni проверяется значение функции csn_initialized(wsnj) (доступность или недоступность удалённой рабочей станции сети). Если оно равно true (т. е. удалённая рабочая станция инициализирована в сети), то проверяется отсутствие в множестве текущих ролей субъект-сессии wsni, функционирующей от имени учётной записи-компьютера wu (user(wsnj) = wui), запрещающей роли, обладающей правом доступа executer к сущности-«макроконтейнеру» emj, и наличие по крайней мере одной сетевой роли удалённого доступа, обладающей этим же правом доступа к emj, где ej < emj. При выполнении этих условий проверяется возможность получения запрашиваемого доступа непосредственно к самой сущности ej.
С целью задания мандатного управления доступом к новым по сравнению с МРОСЛ ДП-моделью элементам системы сделаем следующее предположение.
Предположение 2. В рамках МРОКС ДП-модели для элементов системы выполняются следующие условия.
Условие 1 (мандатные уровни конфиденциальности и целостности сущностей-«макроконтейнеров», учётных записей-компьютеров). Вся траектория функционирования системы, соответствующей компьютерной сети, включая её начальное состояние, удовлетворяет следующим требованиям:
— каждая сущность-«макроконтейнер» emi Е Ei обладает высоким уровнем целостности, при этом выполняется условие CCRI(emi) = false, где 1 ^ i ^ ш;
— сущность-«макроконтейнер» обладает максимальным уровнем конфиденциальности среди всех сущностей конкретной рабочей станции сети: для сущности emi Е Е EM и любой сущности e Е Ei справедливо неравенство fe(e) ^ fe(emi) ^ ^ fem(emj) и CCR(emj) = false, где 1 ^ i ^ ш;
— каждая учётная запись-компьютер обладает высоким уровнем целостности: для учётной записи wu Е WU выполняется iu(wu) = i_high.
Условие 2 (мандатные уровни конфиденциальности и целостности рабочих станций сети). Вся траектория функционирования системы, соответствующей компьютерной сети, включая её начальное состояние, удовлетворяет следующим требованиям:
— уровень доступа субъект-сессии wsui не должен превышать уровня конфиденциальности сущности-«макроконтейнера» emi: для emi Е Ei и субъект-сессии wsui Е SNi выполняется fs(wsui) ^ fe(emi), где 1 ^ i ^ ш;
— каждая субъект-сессия, соответствующая отдельной рабочей станции сети, обладает высоким уровнем целостности: для субъект-сессии wsui выполняется is(ws,ui) = = i_high, где 1 ^ i ^ ш.
Условие 3. Все роли удалённого доступа обладают высоким уровнем целостности: для любой роли удалённого доступа ur Е NR справедливо равенство ir(ur) = i_high (это верно и для запрещающих ролей удалённого доступа, так как они все обладают высоким уровнем целостности по условию 3 предположения 1).
Условие 4. Субъект-сессия wsui получает доступ на чтение хотя бы к одной индивидуальной роли удалённого доступа ur Е NR, уровень конфиденциальности которой равен уровню доступа субъект-сессии: для любой субъект-сессии wsui Е CSN существует роль удалённого доступа user(wsui)_ur_fs(wsui)_i_high Е NR, такая, что (wsui,'ur,reada) Е AAi, 1 ^ i ^ ш.
Замечание 13. Субъект-сессии может быть предоставлен доступ на запись к сущности только в случае, когда её уровень целостности не выше текущего уровня целостности субъект-сессии. Доступ субъект-сессии wsui на запись к сущности-«макроконтейнеру», предоставляемый через владение ролями удалённого доступа, интерпретируется как возможность выполнения административных функций (например, настройка сетевых параметров рабочей станции сети). Выполнять подобные функции могут субъект-сессии, функционирующие от имени учётных записей доверенных пользователей, то есть субъект-сессии с высоким уровнем целостности, что соответствует мандатной политике целостности.
С целью задания порядка предоставления прав доступа к сущностям для запрещающих ролей и доступов субъект-сессий к ним, а также для описания правил мандатного управления доступа и целостности, связанных с использованием запрещающих ролей, сделаем предположение.
Предположение 3. В рамках МРОКС ДП-модели выполняются следующие условия, которые дополняют и уточняют (в части, касающейся множества запрещающих ролей) условия, заданные в МРОСЛ ДП-модели [1].
У с л о в и е 1. Права доступа запрещающих ролей к сущностям являются более приоритетными при проверке выполнения условий де-юре правил преобразования состояний сети и отдельной рабочей станции, в частности, по сравнению с правами доступа, которыми обладают роли к тем же сущностям.
Условие 2. При создании каждая субъект-сессия получает доступ на чтение к запрещающим ролям с уровнем конфиденциальности, не превосходящим её уровня доступа. При этом к запрещающим ролям обладает соответствующим правом доступа индивидуальная административная роль учётной записи пользователя, от имени которой функционирует данная субъект-сессия: для субъект-сессии s Е S выполняется условие: если ur Е UR, fr(ur) ^ fs(s) и (ur,readr) Е APA(user(s)_admiu_i_is(s)), то (s, ur, reada) Е AA.
Условие 3. Запрещающие роли обладают высоким уровнем целостности: для любой запрещающей роли ur Е UR справедливо равенство ir(ur) = i_high.
У с л о в и е 4. Для получения доступа на запись к запрещающей роли субъект-сессии (или кооперирующей с ней другой субъект-сессии) с уровнем доступа, равным c, необходимо получение доступа на запись к сущности c_i_eutity.
Условие 5. Административная роль может содержать административные права доступа на владение или запись к запрещающей роли только в том случае, когда административная роль обладает высоким уровнем целостности: для административной роли аг Е АЯ и запрещающей роли иг Е иЯ, если (иг,аг) Е АРА(аг), то %г(аг) = %_ЫдН, где аг Е {ошиг,1игйег}.
Условие 6. Субъект-сессия может создать, удалить, переименовать запрещающую роль, получить административный доступ на запись к запрещающей роли, изменить иерархию запрещающих ролей или изменить права доступа административных ролей к ней, только если эта запрещающая роль обладает высоким уровнем целостности: для субъект-сессии в Е 5, запрещающей роли иг Е и Я, если (в, иг, /шгИеа) Е АА, то %г(иг) = %3(в) = %_ЫдН.
Все остальные условия мандатного управления доступом и мандатного контроля целостности для запрещающих ролей задаются аналогично существующим условиям для ролей в МРОСЛ ДП-модели.
Замечание 14. Условия 5 и 6 предположения 3 не запрещают субъект-сессии, обладающей любым уровнем целостности, получить доступ на чтение к запрещающей роли. Однако, согласно условию 6, добавить или удалить соответствующее право доступа для административной роли может только субъект-сессия с высоким уровнем целостности (функционирующая от имени учётной записи пользователя с высоким уровнем целостности), что позволяет данной субъект-сессии изменять права доступа запрещающих ролей к сущностям с любым уровнем целостности.
3. Де-юре правила преобразования состояний
Зададим правила преобразования состояний, в исходном или результирующем состоянии которых используются или изменяются функции и множества, содержащие элементы, заданные для различных рабочих станций, функционирующих в рамках сети. Помимо этого приведём пример того, как изменяются правила преобразования состояний отдельных рабочих станций сети, заданные в МРОСЛ ДП-модели [1], с учётом новых элементов модели.
Де-юре правила преобразования состояний МРОКС ДП-модели
Правило: dest _access _read(xi, Xj, yj)
Исходное состояние: 1 ^ i ^ ш, 1 ^ j ^ ш, Xi,Xj Е SN, wsni,wsnj Е CSN : csn_accessory(xi) = = wsn-i, csn_accessory(xj) = wsnj, yi Е Ej, [существуют osi Е OSi и osj Е OSj: (osi,0Sj) Е Е csn_connected(wsni,wsnj), {(xi, os-i, aa) : aa Е {reada,writea}} С A, {(xj,osj, aa) : aa Е {reada, writea}} С A], [не существует ur Е UR, network_role(ur) = true, такой, что (xi,ur,reada) Е AA и (yi,readr) Е PAj(ur)] и [существует r Е R U AR, network_role(r) = true, такая, что (xi,r,reada) Е AA и (yj,readr) Е PAj(r)], [и либо (существует контейнер cj Е Cj, такой, что execute _container(xj ,cj ,yj) = true и fe (yj) ^ fs(xj)), либо (xj, downgrade _admin_role, reada) Е AA]
Результирующее состояние: A' = A U {(xj ,yj, reada), (xi, yj ,reada)} (Aj = Aj U {(xj ,yj ,reada)}, Aj U {(xi ,yj, reada)})_
Правило: dest_access_write(xi, xj, yj)
Исходное состояние: 1 ^ i ^ ш, 1 ^ j ^ ш, xi,xj Е SN, wsni,wsnj Е CSN: csn_accessory(xi) = = wsni, csn_accessory(xj) = wsnj, yi Е Ej, [существуют osi Е OSi и osj Е OSj: (osi,osj) Е Е csn_connected(wsni,wsnj), {(xi, osi, aa) : aa Е {reada,writea}} С A, {(xj ,osj, aa) : aa Е {reada, writea}} С A], [не существует ur Е UR, network_role(ur) = true, такой, что (xi,ur,reada) Е AA и (yi,writer) Е PAj (ur)] и [существует r Е R U AR, network_role(r) = true, такая, что (xi,r,reada) Е AA и (yj,writer) Е PAj(r)], [ie(yj) ^ is(xi) и либо (существует контейнер cj Е Cj, такой, что execute_container(xj,cj,yj) = true и, если yj Е E_HOLE, то fs(xi) ^ fe(Vj), иначе fe(yj) = fs(xi)), либо (xi, downgrade_admin_role,reada) Е AA], [если ie(yj) = i_high, то (xi, fs(xi)_i_entity,writea) Е A]
Продолжение таблицы
Результирующее состояние: A' = A U {(xj ,yj ,writea), (xi,yj, write a)} (Aj = Aj U {(xj ,yj,
writea)}, Aj U {(xi,yj, writea)})_
Правило: csn_connect(xi, osi, xj, yj, osj)
Исходное состояние: и < ш, 1 ^ i ^ ш, 1 ^ j ^ ш, yj Е OSj, [wsni,wsnj Е CSN: csn_accessory(xi) = wsni,csn_accessory(xj) = wsnj,csn_initialized(wsni) = true], [существует nr Е NR, такая, что (wsni,nr,reada) Е AAi и (emj,executer) Е PAj(nr), CCRI(emj) = = false, CCR(emj) = false], [не существует nur Е NUR, такой, что (csni,nur,reada) Е Е AAi и (emj ,executer) Е PAj (nur)], [существует nr' Е NR, такая, что (csnj ,nr' ,reada) Е Е AAj и (emi,executer) Е PAi(nr'), CCRI(emi) = false, CCR(emi) = false], [не существует nur' Е NUR, такой, что (wsnj,nur',reada) Е AAj и (emi,executer) Е PAi(nur')], [{(xi,osi,«a) : aa Е {reada, writea}} С Ai, (xj,yj,reada) С Ai], [либо fe(osi) = fe(yj) = fs(xj), либо fe(osi) < fe(yj) ^ js(xj) и (xj, downgrade_admin_role,reada) Е AAj], ConstraintpAj (PAj) = true Результирующее состояние: csn_connected'(wsni,wsnj) = csn_connected(wsni,wsnj) U (os^ oSj), OSj = OSj U oSj, fe(osj) = fe(osi),
pAj (user(xj ) _c_fs(xj )_is(xj )) = PAj (user(xj ) _c_fs(xj )_is(xj )) U{(osj , ownr )}, (HEj (yj )) =
= He3(He-1 (yj))Uosj,H'E.(osj) = 0, [если csn_initialized(wsni) = fаlse,то S' = SUSi, E' = EUEi, и = и +1, csn_initialized'(wsnj) = true, A' = A U Ai, AA' = AA U AAi] Правило: csn_disconnect(xi, osi, xj, osj)
Исходное состояние: 1 ^ i ^ ш, 1 ^ j ^ ш, xi Е Si, xj Е Sj, osi Е OSi, osj Е OSj, [wsni,wsnj Е CSN : csn_accessory(xi) = csni,csn_accessory(xj) = wsnj,csn_initialized(wsni) = = csn_initialized(wsnj) = true], (osi,osj) Е csn_connected(wsni,wsnj), ie(osi) ^ is(xi) и либо fe(osi) = fs(xi), либо (xi, downgrade_admin_role,reada) Е AA
Результирующее состояние: OSi = OSi \ {osi},A' = A \ {(s, osi,aa) : s Е S, aa Е Ra}, csn_connected'(wsni, wsnj) = csn_connected(wsni, wsnj) \ {(osi,osj)}, [если i = j и для любого 1 ^ k ^ n, k = j выполняется csn_connected(wsnk, wsnj) = 0, то S' = S \ Sj,E' = E \ Ej, AA' = AA \ AAj-, и = v - 1, A' = A \ (Aj- U Aij U Akj), для r Е R U UR U AR выполняется PA'(r) = PA(r) \ 2Pj, csn_initialized'(wsnj) = false], для s Е S' выполняются равенства user'(s) = user(s) и HS'(s) = HS(s) Правило: listen_socket(x, y)
Исходное состояние: x Е S, y Е OS, (x, listen_socket) Е AA, существует r Е R, такая, что network_role(r) = true, (x,r,reada) Е AA и (y,readr) Е PA(r) и [для любой ur Е UR : network_role(ur) = true, (x,ur,reada) Е AA верно (y,readr) Е PA(ur)], [либо fs(x) = fe(y), либо (x, downgrade_admin_role,reada) Е AA] Результирующее состояние: is_listening(y) = true Правило: access_read(x, x', y)
Исходное состояние: x,x' Е S, y Е E U R U UR U AR, существует r Е R U AR : (x, r, reada) Е AA и для любой ur Е UR : (x,ur,reada) Е AA, [если y Е E, то (y,readr) Е PA(r), (y,readr) Е PA(ur) и либо (существует контейнер cE C, такой, что execute _container(x, c,y) = true и fe(y) ^ ^ fs(x)), либо (x, downgrade_admin_role,reada) Е AA, и, если y Е OS, то network_role(r) = network_role(ur) = true], [если y Е R U UR U AR, то (y,readr) Е APA(r), Constraintaa(AA') = = true, (если y Е UR, то для e Е]y[ либо (x,e,reada) Е A, либо (x,e,writea) Е A), (либо fr(y) ^ ^ fs(x), либо (x, downgrade_admin_role,reada) Е AA) и если y Е R U AR, то ir(y) ^ is(x)], [если y Е RU AR и ir (y) = i_high, то (x', fs(x)_i_entity, writea) Е A], [если y Е NRUNUR, то x Е CSN] Результирующее состояние: если y Е E, то A' = A U {(x, y, reada)}, если y Е R U UR, то AA' = AA U {(x, y, reada)},
если y Е AR, то AA' = AA U {(x, y, reada)} U {(x,ur,reada): [x Е S, при этом если ur Е NUR, то
x Е CSN], (ur, readr) Е APA(y) и fr (ur) < fs(x)}_
Правило: access_write(x, x',y)
Исходное состояние: x,x' Е S, y Е E U R U UR U AR, существует r Е R U AR: (x, r, reada) Е AA и для любой ur Е UR: (x,ur,reada) Е AA, [если y Е E, то (y,writer) Е PA(r), (y,readr) Е PA(ur), ie(y) ^ is(x) и либо (существует контейнер cE C, такой, что execute _container(x,c,y) = true, и fe(y) = fs(x)), либо (x, downgrade_admin_role, reada) Е AA, и, если y Е OS, то network_role(r) = = network_role(ur) = true], [если y Е R U UR U AR, то (y,writer) Е APA(r), ir(y) ^ is(x), Constraintaa(AA') = true, (для e Е]y[ либо (x, e, reada) Е A, либо (x, e, writea) Е A), (либо fr (y) = = fs(x), либо (x, downgrade_admin_role,reada) Е AA)], [если (y Е E и ie(y) = i_high) или (y Е Е R U UR U AR и ir(y) = i_high), то (x', fs(x)_i_entity, writea) Е A] Результирующее состояние: если y Е E, то A' = A U {(x, y, writea)}, AA' = AA, если y Е R U UR U AR, то AA' = AA U {(x, y, writea)}, A' = A
Окончание таблицы
Правило: grant_rights(x,x',r, (r,ar.) : 1 ^ j ^ k)_
Исходное состояние: x,x' Е S, y Е E, r Е R U UR U AR, arj Е {writer,readr,executer}, (x,r,writea) Е AA, ie(y) ^ is(x), [существует r' Е R U AR: (x,r',reada) Е AA, (y,ownr) Е PA(r'), и, если y Е OS, то network_role(r) = true], [либо (существует контейнер c Е C, такой, что execute_container(x,c,y) = true, и fe(y) = fs(x)), либо (x, downgrade_admin_role,reada) Е AA], [если arj = writer, то ie(y) ^ ir(r)], Constraintpa(PA') = true, [если ie(y) = i_high, то (x', fs(x)_i_entity, writea) Е A], [если r Е NRUNUR, то (x, admin_net, reada) Е AA],где 1 ^ j ^ k Результирующее состояние: PA'(r) = PA(r) U {(y, arj) : 1 ^ j ^ k}, и для r' Е (R U AR) \ {r} выполняется равенство PA'(r') = PA(r')
Правило: grant _admin_rights(x,x' ,r, (ar,arj) : 1 ^ j ^ k)_
Исходное состояние: x,x' Е S, r Е RU UR U AR, ar Е AR, ar Е {writer,readr}, (x,ar,writea) Е Е AA, ir (r) ^ is(x), [если r Е R U AR или (r Е UR и существует j : arj = writer), то ir (r) ^ ir (ar)], [если r Е R U UR, то (x, roles_admin_role, reada) Е AA, если r Е AR, то (x, admin_roles_admin_role, reada) Е AA, если r Е NR U NUR, то (x, admin_net, reada) Е AA и (если существует j : arj = readr, то ar Е {u_admin_i_high : u Е WS})], [либо fr(r) = fs(x), либо (x, downgrade_admin_role,reada) Е AA], Constraintapa(APA') = true, Constraintaa(AA') = = true, [если ir(r) = i_high, то (x', fs(x)_i_entity, writea) Е A], где 1 ^ j ^ k Результирующее состояние: APA'(ar) = APA(ar) U {(r, arj) : arj = writer, 1 ^ j ^ k} U U {(r', arj): arj = readr, r' ^ r, 1 ^ j ^ k}, для ar' Е AR \ {ar} выполняется равенство APA'(ar') = = APA(ar'), если r Е RU AR, то AA' = AA, если r Е UR и arj = readr, то AA' = AAU{(s, r, reada): [s Е S, при этом (если r Е NUR, то s Е CSN)], (s, ar,reada) Е AA и fr(r) ^ fs(s)} Правило: create_first_session(x, x', u, y, z, zc, zi)
Исходное состояние: x,x' Е S, u Е U, y Е E, z Е S, [существует r Е R U AR, такая, что (x,r,reada) Е AA и (y,executer) Е PA(r), для любой ur Е UR : (x,ur,reada) Е AA и (y,executer) Е PA(ur)], существует контейнер c Е C, такой, что execute_container(x,c,y) = = true, fe(y) < min(fs(x),fu(u)), zc < fu(u), zi < min(iu(u),ie(y)), [либо fs(x) < zc, либо (x, downgrade_admin_role,reada) Е AA], [для e E]u[ либо (x,e,reada) Е A, либо (x, e,writea) Е A], [если zi = i_high, то (x', fs(x)_i_entity, writea) Е A], [если u Е WS и z Е S' ПCSN, то zi = i_high и zc ^ fe(em) для сущности-«макроконтейнера» em Е EM]
Результирующее состояние: S' = S Е z, f's (z) = zc, is (z) = zi, user'(z) = u, если u Е Ly, то LS = Ls U z, иначе N's = Ns U z, для s Е S выполняется user'(s) = user(s), f's(s) = fs(s), is(s) = is(s), если z Е CSN, то csn_initialized(z) = false, AA' = AA U {(z,u_admin_i_zi, reada), (z, u_c_zc_zi, writea), (z, common_zc_zi, writea)}U{(z, u_c_l_li, reada), (z, common_l_li, reada): l ^ zc и li ^ zi} U {(z, u_nr_zc_zi, reada): u Е WS и z Е CSN} U {(z,ur,reada): [ur Е UR, при этом (если ur Е NUR, то z Е CSN)], (ur,readr) Е APA(user(z)_admin_i_zi) и fr(ur) ^ fs(z)}, PA'(u_c_zc_zi) = PA(u_c_zc_zi) U {(z,ownr)}, и для r' Е R \ {u_c_zc_zi} выполняется PA'(r') = PA(r'), [z] = fa(u,y), ]z[= fp(u,y), HS'(z) = 0, для s Е S выполняется
HS(s) = HS(s)_
Правило: create_role(x, x', r, rc, ri, re, name, rz)
Исходное состояние: x,x' Е S, r Е RUURUAR, [если rz Е RUUR, то (x, roles_admin_role, aa) Е Е AA, если rz Е AR, то (x, admin_roles_admin_role, aa) Е AA, где aa Е {reada, writea}], (x,rz,writea) Е AA, re С RE, name Е NAME \ ({""} U {role_name(rz,r') : r' Е HR(rz)}), [либо r = fr(rz) = fs(x), либо r ^ fr(rz) и (x,downgrade_admin_role,reada) Е AA], [ri ^ ^ min(ir(rz),is(x)) и если rz Е UR, то ri = i_high], [для e Е re выполняется fe(e) = rc, ie(e) = ri], Constraintapa(APA') = true, ConstraintpA(PA') = true, [если ir(rz) = i_high, то (x', fs(x)_i_entity, writea) Е A], [если rz Е NR U NUR, то (x, admin_net,reada) Е AA] Результирующее состояние: если rz Е R, то R' = R Е {r}, APA'(roles_admin_role) = = APA(roles_admin_role) U {(r, ownr), (r, executer)} U {(r, readr) : (rz, readr) Е Е APA(roles_admin_role) и r / NR U NUR}, если rz Е AR, то AR' = AR U {r}, APA'(admin_roles_admin_role) = APA(admin_roles_admin_role) U {(r,ownr), (r, executer)} U U {(r,readr) : (rz,readr) Е APA(admin_roles_admin_role) и r Е NR U NUR}, для ar Е AR \ {admin_roles_admin_role, roles_admin_role} выполняется APA'(ar) = APA(ar) U U {(r, executer)}U{(r, readr) : (rz,readr) Е APA(ar) и (если r Е NRU NUR, то ar Е {u_admin_li : u Е U,li Е LI})}, fr(r) = rc, ir(r) = ri, CCR'(r) = false, CCRI'(r) = false, role_name'(rz,r) = = name, ]r[= re, shared_container'(r) = true, PA'(r) = 0, HR'(rz) = HE(z) U {r}, HR'(r) = 0, для r' Е (R U AR) \ {rz} выполняется равенство HR'(r') = HR(r')
Де-юре правила dest_access_read(xi, xj,yj), dest_access_write(xi,xj,yj) позволяют субъект-сессии xi, функционирующей на рабочей станции wsni, получить доступ на чтение или запись к удалённому ресурсу yj сети, расположенному на рабочей станции wsnj, через удалённое сетевое соединение с субъект-сессией xj. Для возможности обращения к ресурсам рабочей станции wsnj необходимо существование соке-тов osi и osj, через которые осуществляется сетевое соединение субъект-сессий xi и xj. При этом субъект-сессии xi и xj должны обладать доступом на чтение и запись к соке-там osi и osj соответственно. Вместе с тем субъект-сессия xj должна обладать сетевой ролью r, имеющей соответствующее право доступа (readr или writer) к сущности yj, и не должна содержать в качестве текущей какую-либо сетевую запрещающую роль ur, обладающую тем же рассматриваемым правом доступа к yj, что и роль r. Получение запрашиваемого доступа к yj возможно только с учётом прав доступа субъект-сессии xj к сущностям-контейнерам, содержащим yj. Для получения доступа на запись к сущности yj уровень целостности субъект-сессии xi должен быть не меньше уровня целостности yj, а её уровень конфиденциальности должен совпадать с уровнем доступа xj, за исключением случая, когда предоставляется доступ к объекту-«дырке», и уровень кофиденциальности yj должен быть не ниже уровня доступа субъект-сессии xj. При получении доступа на чтение уровень доступа субъект-сессии xj должен быть не ниже уровня конфиденциальности сущности yj. Для возможности нарушения требований мандатного управления доступом субъект-сессия xi должна обладать доступом на чтение к административной роли downgrade_admin_role.
Де-юре правило csn_connect(xi,osi,xj,yj,osj) позволяет субъект-сессии xi, соответствующей рабочей станции сети wsnj,, установить сетевое соединение с субъект-сессией xj, соответствующей рабочей станции сети wsnj, посредством сокетов osi и osj соответственно и «слушающего» сокета yj. При этом необходимо, чтобы в множестве текущих ролей субъект-сессии wsni содержалась роль удалённого доступа ur и отсутствовала запрещающая роль удалённого доступа nur, обладающие правом доступа executer к сущности-«макроконтейнеру» удалённой рабочей станции emj. Субъект-се-сиия xi должна обладать доступами на чтение и запись к объекту-сокету osj,, а субъект-сессия xj — только правом доступа на чтение к «слушающему» сокету yj. Для возможности установления сетевого соединения уровень доступа субъект-сессии xj должен быть не ниже уровня конфиденциальности «слушающего» сокета субъект-сесии yj. При этом либо уровень конфиденциальности xi должен быть равен уровню доступа субъект-сесии xj, а также уровню конфиденциальности «слушающего» сокета yj, либо для возможности нарушения этого требования субъект-сессия xj должна обладать доступом на чтение к административной роли downgrade_admin_role. Вместе с тем множество текущих ролей субъект-сессий wsnj должно содержать роль удалённого доступа ur и не включать запрещающую роль удалённого доступа nur, обладающие правом доступа executer к сущности-«макроконтейнеру» удалённой рабочей станции emi (разрешать ответный входящий трафик от удалённой рабочей станции wsnj). В силу того, что атрибуты CCR и CCRI для сущностей-«макроконтейнеров» имеют значение false, их уровни конфиденциальности и целостности в дальнейшем не учитываются при получении доступа внутрь этих контейнеров. При выполнении всех условий на рабочей станции wsnj создаётся сокет osj, участвующий в дальнейшем в сетевом соединении; его уровни кофиденциальности и целостности совпадают с уровнями конфиденциальности и целостности сокета osi. В случае, если субъект-сессия wsni не была инициализирована в сети (устанавливается первое сетевое соеди-
нение, csn_initialized(wsni) = false), то множества, описывающие состояние сети, дополняются множествами инициализируемой рабочей станции.
Де-юре правило csn_disconnect(xi,osi,xj,oSj) позволяет субъект-сессии Xi, функционирующей на рабочей станции wsni, удалить (закрыть) сокет osi и разорвать сетевое соединение, осуществляемое через сокет osj, с субъект-сессией Xj, функционирующей на рабочей станции сети wsnj. Для успешного выполнения запрашиваемого действия необходимо, чтобы уровень доступа субъект-сессий xi был равен уровню конфиденциальности сокета osi. Для возможности нарушения этого требования субъект-сессия x,¿ должна обладать ролью downgrade_admin_role. Вместе с тем уровень целостности сокета osi не должен превосходить уровня целостности субъект-сессии xi. В случае выполнения всех условий, а также если разорванное соединение было последним для рабочей станции сети wsnj, из множеств, описывающих состояние сети, удаляются множества рабочей станции wsnj.
Обоснуем утверждения о том, что способ задания запрещающих ролей с учетом предъявляемых требований в рамках МРОКС ДП-модели не повлияет на корректность задания правил преобразования состояний МРОСЛ ДП-модели [1] и что условия и результаты заданных правил преобразования соответствуют предположениям 1-3.
Утверждение 1. Пусть Go — начальное состояние системы T.(G*,OP,G0), удовлетворяющее условиям предположений 1 и 2. Тогда для любой траектории G0 \opi Gi \~0p2 ... \opN Gn , где N ^ 1, в состоянии GN выполняются условия предположений 1 и 2 и переход Gn -i \opN Gn удовлетворяет условиям этих предположений.
Доказательство.
Индукция по длине N траектории функционирования системы.
Пусть N = 0, тогда по условию утверждения состояние G0 удовлетворяет условиям предположений 1 и 2.
Пусть N > 0 и утверждение верно для всех траекторий длины 0 ^ L < N. Пусть G0 \~opi Gi \op2 ... \opN Gn — траектория функционирования системы. По предположению индукции состояние Gn-i удовлетворяет условиям предположений 1 и 2, а также каждый переход Gi-i \opi Gj, удовлетворяет условиям этих предположений, где 1 ^ i< N. '
Рассмотрим правило преобразования состояний opN. Если условия его применения не выполняются в состоянии Gn-i, то по определению правил преобразования состояний справедливо равенство Gn-i = Gn и по предположению индукции состояние Gn удовлетворяет условиям предположений 1 и 2 и переход GN-i \opN GN удовлетворяет условиям этих предположений. Пусть условия применения правила преобразования состояний opN выполняются в состоянии Gn-i.
Если opN является де-факто правилом (за исключением правила de_facto_op(s, op(x,x',...))), то в результате его применения могут измениться только значение функции de_facto_ownN-i и множество информационных потоков Fn-i. В предположениях 1 и 2 не содержится требований к множеству информационных потоков и фактическому владению субъект-сессий. Таким образом, если opN является де-факто правилом (за исключением правила de_facto_op(s, op(x, x',...))), то по предположению индукции состояние Gn удовлетворяет условиям предположений 1 и 2 и переход Gn-i \opN Gn удовлетворяет условиям этих предположений.
Если opN является де-факто правилом de_facto_op(si, sj ,op(xi}xj,...)), то результаты его применения совпадают с результатами применения де-юре правила op(xi} xj,...), за исключением множества информационных потоков Fn-i, в которое
добавляются информационные потоки по времени. Однако к таким информационным потокам также не предъявляются требования в предположениях 1 и 2, поэтому далее при обосновании шага индукции будем считать, что opN —де-юре правило.
Пусть opN —де-юре правило. Обоснуем выполнение условий предположений 1 и 2 в состоянии Gn и при переходе GN-1 bopN GN.
Административное право доступа readr к ролям или запрещающим ролям удалённого доступа задаётся при применении правил вида create_user(x,x',u,uc,ui,ue) (административное право доступа readr к индивидуальным ролям удалённого доступа задаётся аналогично индивидуальным ролям), set_user_labels(x,x',u,uc,ui,ue) (для индивидуальных ролей удалённого доступа задаётся аналогично индивидуальным ролям), graut_admiu_rights(x,x' ,ar, {(r,arj) : 1 ^ j ^ k}), create _r ole(x, x' ,r,rc,ri, re, uame, rz), create_hard_liuk_role(x, x', r, uame, rz) (аналогично правилу преобразования create_role). В состоянии GN-1 при применении правила graut_admiu_rights и в состоянии Gn в результате применения остальных правил проверяется условие назначения права доступа readr для ролей и запрещающих ролей удалённого доступа только для индивидуальных административных ролей учётных записей пользователей. Следовательно, с учётом предположения индукции в состоянии Gn и при переходе GN -1 bopN GN выполнено условие 1 предположения 1.
Заметим, что задание (и удаление) права доступа readr к индивидуальным ролям удалённого доступа организуется аналогично заданию (удалению) права доступа readr к индивидуальным ролям в МРОСЛ ДП-модели [1].
Таким образом, выполнение условия 2 предположения 1 МРОКС ДП-модели следует из утверждения 1 МРОСЛ ДП-модели [2].
Субъект-сессии могут получить административный доступ на чтение к запрещающим ролям удалённого доступа с использованием правил вида create _sessiou(x, x' ,y, z), create_first_sessiou(x,x',u,y,z,zc,zi), graut_admiu_rights(x, x',ar, {(r,arj) : 1 ^ ^ j ^ k}), access_read(x, x',y), а к ролям удалённого доступа — только посредством правила access_read(x, x',y). В результате применения этих правил получить доступ reada к запрещающим ролям удалённого доступа могут только субъект-сессии, входящие в множество CSN. Вместе с тем в условиях применения правила последнего вида проверяется, что доступ на чтение к роли (а также и к запрещающей роли) удалённого доступа может быть предоставлен только субъект-сессиям рабочих станций сети.
Таким образом, с учётом предположения индукции в состоянии Gn и при переходе GN-1 \~opN Gn выполнено условие 3 предположения 1.
Для создания, удаления, переименования, изменения иерархии ролей удалённого доступа, назначения к ним прав доступа административных ролей, а также для изменения их прав доступа к сущностям-«макроконтейнерам» субъект-сессия может использовать все правила МРОСЛ ДП-модели, которые используются для тех же действий с ролями, в условиях применения которых проверяется наличие административной роли admiu_uet в множестве текущих ролей данной субъект-сессии (для них задаются условия аналогично правилу graut_rights). Следовательно, с учётом предположения индукции в состоянии Gn и при переходе Gn-1 ^~oPN Gn выполнено условие 4 предположения 1.
Изменение уровней целостности и значений атрибутов CCRI и CCR контейнера выполняется с помощью правил преобразования вида set_eutity_labels(x,x',y,yc,yi) и set_coutaiuer_attr (x, x1, y, ccr, ccri, t), в условиях применения которых исключается возможность изменения уровней целостности и значений атрибутов CCR и CCRI для сущности-«макроконтейнера».
Субъект-сессия может изменить уровень целостности учётной записи пользователя при применении правила вида set_user_labels(x,x',u,uc,ui,ue), условия применения которого запрещают задавать для учётной записи-компьютера уровень целостности, отличный от i_high.
Таким образом, в силу условий, заданных в МРОСЛ ДП-модели, которые запрещают создавать сущность с уровнем конфиденциальности, превосходящим уровень конфиденциальности сущности-контейнера, её содержащего, и с учётом предположения индукции в состоянии Gn и при переходе Gn-i \opN Gn выполнено условие 1 предположения 2.
Создание субъект-сессии рабочей станции сети возможно с использованием правил вида create_session(x, xX, y, z), create_first_session(x, x', u, y, z, zc, zi), в условиях применения которых проверяется, что уровень целостности создаваемой субъект-сессии равен i_high, а уровень конфиденциальности (для правила create_session уровни конфиденциальности и целостности создаваемой субъект-сессии совпадают с соответствующими уровнями текущей субъект-сессии) не превосходит уровня конфиденциальности сущности-«макроконтейнера». В силу того, что мандатные атрибуты субъект-сессий не изменяются в процессе функционирования системы, и с учётом предположения индукции в состоянии Gn и при переходе Gn-i \opN Gn выполнено условие 2 предположения 2.
В соответствии с условиями правила create_role(x,x',r,rc,ri,re,name,rz), при создании ролей удалённого доступа им назначается уровень конфиденциальности i_high, и в модели отсутствуют правила, позволяющие изменять уровень целостности роли впоследствии. При создании индивидуальных ролей удалённого доступа учётных записей пользователей с использованием правил вида create _user(x,x',u,uc,ui,ue) и set_user _labels(x,x',u,uc,ui,ue), в соответствии с условием 2 предположения 1 им присваивается уровень целостности, совпадающий с уровнем целостности учётной записи-компьютера, который по условию 1 предположения 2 равен i_high на всей траектории функционирования системы. Следовательно, с учётом предположения индукции в состоянии Gn и при переходе GN-i \~opN GN выполнено условие 3 предположения 2.
Шаг индукции доказан. ■
Обоснуем также, что в МРОКС ДП-модели задание правил преобразования состояний системы корректо относительно требований, предъявляемых к мандатному и ролевому управлению доступом, связанных с новыми множествами запрещающих ролей UR и запрещающих ролей удалённого доступа NUR.
Утверждение 2. Пусть G0 — начальное состояние системы T.(G*,OP,G0), соответствующей любой отдельной рабочей станции сети, удовлетворяющее условиям предположения 3 МРОКС ДП-модели. Тогда для любой траектории Go \op1 Gi \op2 ■ ■ ■ \opn Gn , где N ^ 1, в состоянии Gn выполняются условия предположения 3 МРОКС ДП-модели, и переход GN-i \~opN GN удовлетворяет условиям этого предположения.
Доказательство.
Индукция по длине N траектории функционирования системы.
Пусть N = 0, тогда по условию утверждения состояние G0 удовлетворяет условиям предположения 3.
Пусть N > 0 и утверждение верно для всех траекторий длины 0 ^ L < N. Пусть G0 \~opi Gi \~ор2 ■■■ \~opN Gn — траектория функционирования системы. По предположению индукции состояние Gn-i удовлетворяет условиям предположения 3, а так-
же каждый переход Gi-i hop. Gi удовлетворяет условиям этого предположения, где 1 ^ i< N. '
Рассмотрим правило преобразования состояний opN. Если условия его применения не выполняются в состоянии Gn-i, то по определению правил преобразования состояний справедливо равенство Gn-i = Gn и по предположению индукции состояние Gn и переход GN-i \opN GN удовлетворяют условиям предположения 3. Пусть условия применения правила преобразования состояний opN выполняются в состоянии Gn-i.
Если opN —де-факто правило, то в результате его применения могут измениться только значение функции de_facto_ownN-i и множество информационных потоков Fn-i. Требований к множеству информационных потоков (как по памяти, так и по времени) и фактическому владению субъект-сессиями в предположениии 3 не содержится. Следовательно, если opN —де-факто правило, то по предположению индукции состояние Gn и переход GN-i \opN GN удовлетворяют условиям предположения 3.
Пусть opN — де-юре правило. Обоснуем выполнение условий предположения 3 в состоянии Gn и при переходе GN-i \opN GN.
В исходном состоянии всех де-юре правил МРОКС ДП-модели, в которых проверяется наличие прав доступа (кроме права доступа ownr) у текущих ролей или административных ролей субъект-сессии, проверяется отсутствие текущих запрещающих ролей, обладающих идентичными правами доступа. Следовательно, с учётом предположения индукции в состоянии Gn и при переходе Gn-i \oPN Gn выполнено условие 1 предположения 3.
Создание субъект-сессии может быть выполнено с использование одного из правил вида create_first_session(x,x',u,y,z,zc,zi) и create_session(x, x', y, z), в результате применения которых субъект-сессия получает доступ на чтение ко всем запрещающим ролям с уровнем конфиденциальности, не превосходящим уровня доступа создаваемой субъект-сессии, и таким, что индивидуальная административная роль учётной записи пользователя, от чьего имени запускается субъект-сессия, обладает административным правом доступа на чтение к ним. Следовательно, с учётом предположения индукции в состоянии Gn и при переходе GN-i \opN GN выполнено условие 2 предположения 3.
В соответствии с условиями правила create_role(x, x', r, rc, ri, re, name, rz) при создании запрещающих ролей им назначается уровень конфиденциальности i_high, и в модели отсутствуют правила, позволяющие изменять уровень целостности роли впоследствии. Следовательно, с учётом предположения индукции в состоянии Gn и при переходе GN -i \opN GN выполнено условие 3 предположения 3.
В отличие от МРОСЛ ДП-модели, административная роль может содержать административное право доступа на чтение к запрещающей роли независимо от уровня целостности последней. Правило opN, в результирующем состоянии которого административной роли назначается только право доступа на чтение (без права доступа на запись или владение) к запрещающей роли, может быть правилом вида grant_admin_rights(x,x',ar, {(r,arj) : 1 ^ j ^ k}), чьи условия и результаты применения не накладывают ограничений на уровень целостности запрещающей роли. Во всех остальных случаях административные права доступа к запрещающей роли задаются аналогично их заданию для ролей или административных ролей. Таким образом, с учётом предположения индукции в состоянии GN и при переходе GN-i \opN GN выполнено условие 5 предположения 3.
Административный доступ на чтение к запрещающей роли может быть предоставлен субъект-сессии только с использованием правил вида access_read(x, x', y),
create_first_session(x,x',u,y,z,zc,zi) и create_session(x, x', y, z), в условиях и результатах применения которых также не накладывается ограничений на уровень целостности запрещающей роли. Следовательно, с учётом предположения индукции в состоянии Gn и при переходе GN-1 l_opN GN выполнено условие 6 предположения 3.
Выполнение условия 4 предположения 3 доказывается аналогично условиям, заданным в МРОСЛ ДП-модели [1], в части, касающейся получения доступа к роли с уровнем целостности i_high. Шаг индукции доказан. ■
Заключение
Рассмотрена разрабатываемая (на основе МРОСЛ ДП-модели) автором мандатная сущностно-ролевая ДП-модель управления доступом в компьютерных сетях, построенных на основе ОС семейства Linux. В её рамках заданы новые функции и множества, а также правила преобразования состояний, которые позволяют описывать спецификации механизмов управления доступом в ОС с учётом особенностей организации логического управления доступом в компьютерных сетях. Сформулированы и доказаны утверждения о корректности правил преобразования состояний системы относительно требований, предъявляемых к мандатному и ролевому управлению доступом.
Задание новых правил преобразования МРОКС ДП-модели, связанных с организацией логического управления доступом в рамках компьютерных сетей, нацелено на их реализацию в ОССН Astra Linux Special Edition [3] при построении сетевой подсистемы безопасности.
ЛИТЕРАТУРА
1. Девянин П. Н. Администрирование системы в рамках мандатной сущностно-ролевой ДП-модели управления доступом и информационными потоками в ОС семейства Linux // Прикладная дискретная математика. 2013. №4(22). С. 22-40.
2. Девянин П. Н. Корректность правил преобразования состояний системы в рамках мандатной сущностно-ролевой ДП-модели ОС семейства Linux // Прикладная дискретная математика. Приложение. 2013. №6. С. 58-59.
3. http://www.astra-linux.ru — Операционные системы Astra Linux. 2009.
REFERENCES
1. Devyanin P. N. Administrirovanie sistemy v ramkakh mandatnoy sushchnostno-rolevoy DP-modeli upravleniya dostupom i informatsionnymi potokami v OS semeystva Linux [System administration in MROSL DP-model]. Prikladnaya Diskretnaya Matematika, 2013, no.4(22), pp. 22-40. (in Russian)
2. Devyanin P. N. Korrektnost' pravil preobrazovaniya sostoyaniy sistemy v ramkakh mandatnoy sushchnostno-rolevoy DP-modeli OS semeystva Linux [Correctness of state transformation rules in MROSL DP-model]. Prikladnaya Diskretnaya Matematika. Prilozhenie, 2013, no. 6, pp. 58-59. (in Russian)
3. http://www.astra-linux.ru
