МОДЕЛЬ МАНДАТНОГО КОНТРОЛЯ ЦЕЛОСТНОСТИ В ОПЕРАЦИОННОЙ СИСТЕМЕ KASPERSKYOS Текст научной статьи по специальности «Компьютерные и информационные науки»

Б01: 10.15514/18РКЛ8-2020-32(1)-2

Модель мандатного контроля целостности в операционной системе KasperskyOS

В. С. Буренков, ОЯСЮ: 0000-0002-0232-774Х<Vladimir.Burenkov@kaspersky.com> Д. А. Кулагин, ОЯСЮ: 0000-0001-5055-0826 <Dmitry.Kulagin@kaspersky.com>

АО «Лаборатория Касперского», 125212, Россия, Москва, Ленинградское шоссе, д. 39А, стр. 3

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

Ключевые слова: мандатный контроль целостности; операционная система; KasperskyOS.

Для цитирования: Буренков В.С., Кулагин Д.А. Модель мандатного контроля целостности в операционной системе KasperskyOS. Труды ИСП РАН, том 32, вып. 1, 2020 г., стр. 27-56. DOI: 10.15514ЛSPRAS-2020-32(1)-2

A Mandatory Integrity Control Model for the KasperskyOS

Operating System

V. S. Burenkov, ORCID: 0000-0002-0232-774X<Vladimir.Burenkov@kaspersky.com> D. A. Kulagin, ORCID: 0000-0001-5055-0826 <Dmitry.Kulagin@kaspersky.com>

AO Kaspersky Lab., 39A, building 3, Leningradskoe shosse, Moscow, 125212, Russia

Abstract. Existing models of mandatory integrity control in operating systems restrict accesses of active components of a system to passive ones and represent the accesses directly: subjects get read or write access to objects. Such a representation can be used in modeling of monolithic operating systems whose components that provide access to resources are part of the trusted computing base. However, the implementation of these components is extremely complex. Therefore, it is arduous to prove the absence of bugs (vulnerabilities) in them. In other words, proving such a model to be adequate to the real system is nontrivial and often left unsolved. This article presents a mandatory integrity control model for a microkernel operating system called KasperskyOS. Microkernel organization of the system allows us to minimize the trusted computing base to include only the microkernel and a limited number of other components. Parts of the system that provide resource access are generally considered untrusted. Even if some of them are erroneous, the operating system can still provide particular security guarantees. To prove that by means of a model, we introduce the notion of object drivers as intermediaries in operations on objects. We define the requirements that object drivers must satisfy. We also add the means for analysis of the consequences of violations of the requirements. We state and prove that the model either preserves integrity if all active components satisfy the requirements, or restricts the negative impact if some of the components are compromised. Correct implementation of the model guarantees that compromised components will not affect components with higher or incomparable integrity levels. We describe a policy specification language developed in accordance with the model. We provide an example of using it to describe a security policy that ensures a correct update of a system operated by KasperskyOS.

Keywords: mandatory integrity control; operating system; KasperskyOS.

For citation: Burenkov V.S., Kulagin D.A. A Mandatory Integrity Control Model for the KasperskyOS Operating System. Trudy ISP RAN/Proc. ISP RAS, vol. 32, issue 1, 2020. pp. 27-56 (in Russian). DOI: 10.15514/ISPRAS-2020-32(1 )-2

1. Введение

Контроль целостности компьютерных систем является одним из фундаментальных вопросов, рассматриваемых при разработке безопасных систем. Для обеспечения целостности в операционных системах реализуются механизмы мандатного контроля целостности [1]. Их реализация должна быть частью доверенной вычислительной базы. Классический путь разработки механизмов безопасности начинается с создания модели системы [2]. Модель должна отражать существенные особенности разрабатываемой операционной системы. Достоинством наличия модели является возможность строгого доказательства того, что модель обладает определенными свойствами, которыми должна также обладать и сама система. Реализация модели приведет к получению требуемых механизмов безопасности. Если модель реализована корректно, то и система будет обладать доказанными ранее свойствами.

Существуют и официальные требования наличия формальной модели политики безопасности. Их предъявляет, например, ФСТЭК России [3].

В данной работе рассматривается разработка модели мандатного контроля целостности для ее реализации в новой микроядерной операционной системе KasperskyOS. Концепция микроядерных операционных систем зародилась достаточно давно [4]. Также хорошо известны ее преимущества с точки зрения безопасности [5, 6, 7], главное из которых - уменьшение доверенной базы за счет вынесения большинства драйверов из

адресного пространства ядра в непривилегированный код. Несмотря на известность микроядерной архитектуры, существующие подходы к моделированию свойств безопасности операционных систем не учитывают ее специфические свойства. Так, в субъект-объектных [8] моделях управления доступом и информационными потоками получение доступов активных компонент системы к ресурсам представлено непосредственно (рис. 1). Это связано с тем, что данные модели разрабатываются для операционных систем с монолитной архитектурой, где части системы, обеспечивающие доступ к ресурсам (например, драйверы устройств и файловые системы), выполняются в адресном пространстве ядра. Это вынуждает считать их доверенными, и, как следствие, пренебрегать ими при моделировании. Однако эти части являются достаточно сложными программными компонентами, в которых высока вероятность наличия уязвимостей. По этой причине их включение в доверенную вычислительную базу означает использование предположений, которые в действительности могут быть не выполнены.

"приложение^

ДВБ

Файловая Другие

система подсистемы

Ядро

В модели «x получает доступ к y»

_________________I

Рис. 1. Схема получения доступа к ресурсу (файлу) в монолитной операционной системе и ее трактовка в существующих формальных моделях Fig. 1. Resource access scheme in a monolithic operating system and its interpretation in existing formal

models

В отличие от монолитных операционных систем, доступ к ресурсам в рамках микроядерной операционной системы KasperskyOS происходит посредством отдельных процессов - драйверов ресурсов. Поскольку это обычные пользовательские процессы, отпадает необходимость считать их доверенными.

Рассмотрение драйверов ресурсов как обычных процессов позволяет также минимизировать начальное состояние модели системы, не включая в него большинство драйверов. Это дает возможность моделирования безопасности системы, начиная с самых ранних этапов ее загрузки: с того момента, когда загружены только ядро, модуль безопасности и очень ограниченный набор доверенных драйверов. В моделях безопасности для монолитных операционных систем достаточно сложный этап начальной загрузки системы не рассматривается, а созданные в процессе загрузки компоненты считаются частью начального состояния модели.

Рис. 2. Схема получения доступа к ресурсу (файлу) в микроядерной системе и необходимый вид ее

трактовки в соответствующих формальных моделях Fig. 2. Resource access scheme in a microkernel operating system and the way it should be interpreted in

formal models

В то же время наличие недоверенных драйверов ресурсов означает, что при моделировании доступов к ресурсам необходимо всегда принимать во внимание, кроме

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

1. Разработана модель политики безопасности управления доступом и информационными потоками в KasperskyOS, описывающая мандатный контроль целостности. В отличие от существующих моделей, детально проработаны правила доступа к ресурсам посредством драйверов ресурсов, которые не обязательно являются доверенными.

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

3. Сформулирована и доказана теорема, утверждающая, что

• если все сущности удовлетворяют сформулированным требованиям, то отсутствуют запрещенные информационные потоки от менее целостных компонент к более целостным или несравнимым,

• либо, в случае присутствия сущностей, не удовлетворяющих сформулированным требованиям, характер нарушения целостности системы ограничен максимальными уровнями целостности компонентов, нарушающих требования.

Таким образом, корректная реализация модели гарантирует, что если компрометирована часть системы вплоть до некоторого уровня целостности, то это не приведет к компрометации части системы с большими или несравнимыми уровнями целостности.

4. Помимо этого, описан язык спецификации политик мандатного контроля целостности, разработанный в соответствии с правилами модели, и приведен пример использования языка для задания политики безопасности системы с безопасным процессом обновления.

2. Существующие модели мандатного контроля целостности

Мандатный контроль целостности впервые был теоретически описан в работе Биба (K. Biba) [9]. Липнер (S. Lipner) [10]. Кларк и Уилсон (D. Clark, D. Wilson) [11], Ли (T. Lee) [12] представили ранние рассуждения о контроле целостности в коммерческих системах обработки данных. Брювер и Нэш (D. Brewer, M. Nash) [13] разработали другую классическую модель безопасности коммерческих систем, затрагивающую вопросы целостности и конфиденциальности.

Современные модели зачастую основаны на классических моделях целостности и информационных потоков. Так, Лиу (Z. Liu) и др. [14] описывают простую модель контроля целостности в стиле Белла-ЛаПадулы (D. Bell, L. LaPadula) [15]. Модели целостности Usable Mandatory Integrity Protection (UMIP) [16] и SecGuard [17] разработаны с целью простоты использования и реализованы в прототипах, основанных на ядре Linux. Описание моделей не формализовано в достаточной степени. Помимо этого, в них применяются потенциально опасные решения. Модели позволяют понижать уровень целостности субъекта, однако не рассматривают случаи, когда у такого субъекта есть открытые на запись высокоцелостные объекты. Авторы этих моделей также предлагают использовать дискреционные права доступа для задания уровней целостности. Однако при таком подходе ошибка в конфигурации дискреционных прав доступа приведет к бесполезности мандатного контроля целостности. Модель, разработанная П.Н. Девяниным и реализованная в операционной системе Astra Linux [18], достаточно проработана теоретически. Имеются математические доказательства свойств модели. Более того, модель формализована и верифицирована в системе Event-B [19, 20]. Модель была разработана применительно к ядру Linux и подразумевает, что ядро, которое включает в себя большое количество компонент, включая драйверы и файловые системы, является доверенным. Это привело к достаточно большому количеству предположений о начальном состоянии модели, что не отвечает целям настоящей работы.

Операционная система Microsoft Windows реализует мандатный контроль целостности [21], основанный на модели Биба, начиная с версии Windows Vista (2007). Имеются положительные оценки соответствующих механизмов.

Таким образом, в литературе отсутствуют модели мандатного контроля целостности, позволяющие минимизировать доверенную вычислительную базу, в частности, вынести драйверы из пространства ядра. Данная работа восполняет этот пробел.

3. Архитектура операционной системы KasperskyOS

Модель, представленная в данной работе, была разработана для реализации в микроядерной операционной системе KasperskyOS. Основными компонентами операционной системы являются микроядро, монитор безопасности и множество драйверов, реализованных в виде непривилегированных приложений. Главными функциями микроядра являются разделение ресурсов между процессами (которые в рамках операционной системы именуются сущностями), предоставление механизма межпроцессного взаимодействия IPC (interprocess communication) и запуск монитора безопасности для проверки этих взаимодействий. Операционная система разрабатывалась с учетом принципа разделения ресурсов и приложений посредством минимальной доверенной вычислительной базы, направленного на поддержку политик безопасности. Этот подход известен с 1980-х годов [22]. Его современным воплощением является архитектура MILS [23].

Важным компонентом архитектуры MILS является ядро разделения. Если операционная система корректно реализует ядро разделения, то она гарантирует изоляцию приложений (возможно, с различными уровнями доверия) друг от друга. Изоляция приложений очень важна с точки зрения безопасности, так как она позволяет ограничить нежелательное воздействие на систему в целом, которое может оказать отдельное приложение. Однако, во многих случаях одного только ядра разделения недостаточно, особенно, когда взаимодействуют сложные компоненты с разными уровнями доверия. В такой ситуации требуется убедиться, что взаимодействия в системе удовлетворяют требованиям безопасности (часто сложным и разнообразным). В KasperskyOS для решения этой проблемы существует Kaspersky Security System - набор инструментов для

спецификации самых разных свойств безопасности и синтезирования монитора обращений, проверяющего любые взаимодействия внутри системы на предмет соответствия политике. Для спецификации свойств (политики) используется декларативный язык Policy Specification Language (PSL). Описанная на нем политика транслируется в запускаемый образ монитора безопасности, которому ядро и другие сервисы могут направлять свои запросы.

Подход имеет много общего с архитектурой FLASK [24]. Прежде всего это:

• абстрагирование ресурсов и процессов как доменов безопасности; это позволяет монитору применять общие правила по контролю, не обращая внимание на их различную природу (когда это допустимо);

• разделение вычисления политики и механизма, инициирующего проверку события, передающего связанный с событием контекст и интерпретирующего результат проверки. Это одна из ключевых идей FLASK, позволяющая контролировать не только системные события, но и события прикладного уровня.

В KasperskyOS, кроме этого, каждый сервис должен статически декларировать свои интерфейсы. Это делает структуру передаваемых сообщений прозрачной для монитора безопасности, существенно расширяя выразительные возможности языка спецификации политик: монитор безопасности может проверить, что структура сообщения соответствует объявленному интерфейсу, проанализировать части сообщения и связать определенные правила с данным взаимодействием. Для спецификации свойств безопасности можно одновременно использовать разные модели/формализмы. Например, ролевой доступ или политики на основе конечных автоматов. Разные правила комбинируются всегда с помощью конъюнкции - чтобы какое-либо событие было разрешено, необходимо, чтобы оно было разрешено всеми правилами, ассоциированными с этим событием. В данной работе рассматривается мандатный контроль целостности, который реализован как формализм, который можно использовать совместно с другими для спецификации политики безопасности решения. Как было отмечено, каждая сущность или ресурс является доменом безопасности, с которым ассоциирован контекст безопасности, определяемый идентификатором. Таким образом, с точки зрения политики безопасности, программно-аппаратная система, управляемая KasperskyOS, представляет собой множество доменов безопасности и информационных потоков между ними.

3.1 Взаимодействие между процессами

В KasperskyOS сущности обмениваются друг с другом сообщениями посредством механизма синхронного межпроцессного взаимодействия. Выделяются две роли: клиент (сущность, инициирующая взаимодействие) и сервер (сущность, обрабатывающая обращение). Клиент направляет серверу сообщение-запрос, при этом поток исполнения, из которого производится обращение, блокируется до получения ответа от сервера или ядра (в случае, например, ошибки). Серверный поток исполнения находится в ожидании сообщений. При получении запроса, этот поток получает управление, обрабатывает запрос и отсылает сообщение-ответ. При получении сообщения-ответа клиентский поток разблокируется и может продолжать исполнение.

Предположим, что поток Т1 сущности Р± вызывает метод, объявленный в интерфейсе другой сущности Р2 (рис. 3). В этом случае Р± отправляет запрос сущности Р2. В этот момент 7\ приостанавливает свое исполнение, ожидая ответа от Р2. Запрос проходит через механизм IPC, реализованный в микроядре. Механизм IPC отправляет сообщение монитору безопасности, который обрабатывает его согласно политике безопасности. Если политика безопасности разрешает выполнение запроса, то запрос направляется сущности Р2. Р2 затем обрабатывает запрос (в соответствии с реализацией метода) и 32

отправляет ответ сущности Рг. Ответ может содержать данные, вычисленные сущностью Р2 или просто сигнал о завершении обработки запроса. Ответ затем проходит путь через механизм IPC и монитор безопасности. Монитор проверяет, может ли ответ быть доставлен согласно политике безопасности. Если да, то получает ответ и 7\ продолжает свое исполнение. Если отправка запроса или ответа запрещена монитором безопасности, то попытка взаимодействия между Рх и Р2 прерывается и 7\ продолжает свое исполнение.

Рис. 3. Схема межпроцессного взаимодействия Fig. 3. Interprocess communication scheme Монитор безопасности имеет возможность контролировать любые IPC сообщения. С этой целью ядро передает монитору на проверку как сообщение-запрос, так и ответ. Передача сообщения происходит только в случае, если монитор дал разрешение. Кроме операций по контролю запросов и ответов, монитор также поддерживает две специальных операции - execute и security.

Операция execute используется ядром для сообщения монитору о создании новой сущности. Операция security позволяет сущностям отправлять сообщения монитору безопасности напрямую. Данная операция является основой для реализации сервисов (драйверов), которые предоставляют контролируемый доступ к ресурсам.

3.2 Управление доступом к ресурсам

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

Во время каждого доступа к ресурсам драйвер ресурсов должен предоставлять монитору безопасности необходимый контекст. Монитор безопасности затем разрешает или запрещает доступ. При доступе к ресурсу, драйвер использует операцию security для обращения к подсистеме безопасности. В этом обращении драйвер передает дескриптор

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

Ядро операционной системы гарантирует разделение адресных пространств сущностей, поэтому драйвер может управлять только теми ресурсами, системные дескрипторы на которые были выданы именно этому драйверу.

Безусловно, уровень доверия (в самом общем смысле) некоторого ресурса не может быть выше, чем уровень доверия драйвера этого ресурса. Любая политика безопасности должна учитывать это обстоятельство. Это становится важным в случае, когда драйвер является отдельным приложением, не входящим в доверенную вычислительную базу. Рис. 4 иллюстрирует типовой случай выполнения доступа к ресурсу (цифрами обозначен порядок выполнения операций). Здесь сущность Р, Драйвер и его Ресурс являются отдельными доменами безопасности. Сущность Р, которая хочет получить доступ к ресурсу отправляет соответствующее сообщение драйверу этого ресурса. В этом сообщении ресурс может быть идентифицирован различными способами, например, по имени. Драйвер ресурса вычисляет идентификатор ресурса. Затем драйвер ресурса отправляет сообщение монитору безопасности, предоставляя контекст: дескриптор инициатора запроса Р, дескриптор ресурса и другую информацию. Монитор безопасности определяет, может ли Р получить доступ к ресурсу согласно политике безопасности. Если доступ разрешен, то драйвер получает доступ к ресурсу и отправляет ответ сущности Р. Ответ содержит данные, полученные по результатам доступа к ресурсу, и идентификатор ресурса, который может быть использован сущностью в дальнейшем.

4. Модель мандатного контроля целостности 4.1 Информационные потоки

Нахождение системы в целостном состоянии означает, что сущности системы работают корректно. Для обеспечения их корректной работы механизмы мандатного контроля

2. Обращение к монитору ▼ безопасности

Рис. 4. Схема обращения к ресурсу посредством его драйвера Fig. 4. Resource access via its driver

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

Информационным потоком от источника к приемнику называется преобразование данных в приемнике, зависящее от данных, находящихся в источнике [8]. В качестве как источника, так и приемника может выступать сущность или объект. Информационный поток от источника х к приемнику у может возникнуть в результате выполнения различных операций, например, когда сущность х получает доступ на запись в объект у или когда сущность у получает доступ на чтение к объекту х. Во всех случаях поток будем обозначать (х, у, writem) - информация передается от х к у (х «записывает» в у, отсюда название потока write). Индекс «да» подчеркивает, что рассматриваются информационные потоки по памяти.

4.2 Основные компоненты модели

4.2.1 Сущности и объекты

S - множество сущностей (субъектов) системы, представляющее активные компоненты операционной системы. О - множество объектов системы, представляющее пассивные компоненты операционной системы.

Для целей моделирования иерархии объектов введена функция иерархии объектов НО: 0^2°, которая ставит в соответствие каждому объекту с Е О множество объектов НО (с). Будем говорить, что объекты из НО (с) непосредственно находятся в контейнере с.

Выделяется множество корневых объектов CR £ о, не находящихся ни в каком контейнере.

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

Функция OD:O^S ставит в соответствие любому объекту системы его драйвер. Обратное отношение OD-1 £ S х О позволяет определить объекты, управляемые данным драйвером.

4.2.2 Доступы и информационные потоки

Ra = {reada,writea} - множество видов доступа, где reada обозначает доступ на чтение, writea обозначает доступ на запись.

Rf = {writem} - множество видов информационных потоков, где writem обозначает информационный поток по памяти на запись в сущность или объект. А £ S х О х Ra - множество доступов сущностей к объектам. F £ (S U О) х (S U О) х Rf - множество информационных потоков.

4.2.3 Уровни целостности

(LI, <) - решетка уровней целостности. Уровень целостности сущностей и объектов определен с помощью функции il:S U О ^ LI.

При работе операционной системы возникают ситуации, в которых возможно участие сущности в «опасных» взаимодействиях, то есть обращениях на чтение к объектам с

более низким либо несравнимым уровнем целостности. Для разрешения таких взаимодействий в модели введена функция ilr: S ^ LI, определяющая для каждой сущности минимальный уровень целостности объектов, к которым эта сущность может обращаться на чтение. Модель построена таким образом, что для любой сущности s Е S выполняется ilr(s) < il(s).

Для элементов х,у Е LI под х < у будем иметь в виду х < у Ах Ф у. UP\S ^ {false, true] - функция привилегий, служащая для обозначения сущностей, которым разрешено повышать уровень целостности объектов. Предполагается, что в качестве таких сущностей могут выступать доверенные сущности, для которых значение данной функции устанавливается равным true.

4.2.4 Система переходов

В соответствии с распространенным подходом [25], в качестве модели компьютерных систем, управляемых операционной системой, используется система переходов. Системой переходов называется кортеж

TS = (States, OP, G0),

где

• States - множество состояний,

• OP - множество правил преобразования состояний,

• ^ £ States х OP х States - отношение переходов,

• G0 Е States - начальное состояние.

ор

Для краткости под обозначением G — G' будем понимать (G, op, G') Е Если правило преобразования состояний в данном контексте неважно, будем писать G ^ G'. Состояние системы переходов TS = (States, OP, ^, G0) определено как кортеж

G = (S,0,0D,A,F,H0,(il,ilr),UP). Примечание. В рамках модели мы не рассматриваем процесс определения функции UP. Предполагается, что ее значение в каждом состоянии системы переходов определено корректно. Если UP(s) = true для некоторой сущности s, то эта сущность действительно обладает привилегией повышения уровня целостности объектов. Если же сущность s не обладает такой привилегией, то UP(s) = false.

4.2.5 Захват контроля над сущностями и объектами

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

множество CS £ S сущностей, над которыми захвачен контроль, и множество СО £ О объектов, над которыми захвачен контроль.

Как будет доказано в разделе 4.5, модель исключает неограниченный захват контроля частей системы: если захвачен контроль над частью системы, максимальный уровень целостности компонент которой ниже максимально возможного уровня целостности, то это не приводит к захвату контроля над более целостными компонентами системы и, как следствие, всей системы в целом.

4.3 Требования к начальному состоянию

Представленная модель разрабатывалась таким образом, чтобы к начальному состоянию

G0 = (S0,O0,OD0,A0,F0,HO0,(il0,ilr0),UP0) системы переходов TS предъявлялось как можно меньше требований. Предполагается, что в начальном состоянии существует сущность core Е S0, которая представляет ядро операционной системы, и определены значения уровней целостности il0(core) и ilr0(core). Значение il0(core) является максимально возможным значением уровня целостности: ядро операционной системы является наиболее доверенной сущностью. Остальные множества, определенные в модели, являются пустыми.

В случае необходимости в качестве начального можно использовать и состояние с большим количеством непустых компонент. В таком случае к начальному состоянию модели предъявляются следующие требования.

• Для каждого объекта определен его драйвер:

Vo Е О0. 3d Е S0. OD0(o) = d.

• Для всех объектов о Е О0 определено значение И0(о).

• Для всех сущностей s Е S0 определены значения il0(s) и ilr0(s).

• Уровень целостности каждого объекта не выше уровня целостности его драйвера:

Vo Е О0.И0(о) < il0(OD0(o)y

• Для каждого объекта, не являющегося корневым, существует не менее целостный контейнер, в котором находится этот объект:

Vo ЕО0\ CR0. 3с. о Е НО0(с) A il0(o) < И0(с).

• Для всех сущностей s Е S0 определено значение UP0(s).

• Множество доступов является пустым: А0 = 0.

• Множество информационных потоков является пустым: F0 = 0.

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

В результате анализа операций межпроцессного взаимодействия, возникающих в ряде приложений KasperskyOS, был определен набор правил преобразования состояний, которые могут быть использованы для контроля таких взаимодействий с целью обеспечения целостности системы.

Каждое правило преобразования состояний описывает переход из состояния G = (S,0,0D,A,F,H0,(il,ilr),UP) в состояние G' = (S',0',OD',А,F',НО',(il',ilr'),UP') и представлено с помощью пред- и постусловий. Если все части предусловия правила истинны в состоянии G, то постусловие этого правила определяет отношение между компонентами состояния G' и соответствующими компонентами состояния G. В определении правил указаны только те компоненты G', которые изменяются при осуществлении перехода.

Предусловия правил, моделирующих действия сущностей, должны быть реализованы в операционной системе. В связи с этим предусловия разрабатывались так, чтобы они были по возможности простыми. Постусловия в основном служат для анализа модели. Правила преобразования состояний принимают параметры, список которых указывается в скобках после имени правила.

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

В постусловиях некоторых правил используются конструкции йЧЬеп-е^е (как правило, для описания эффектов от факта компрометации параметров правила), смысл которых такой же, как и во многих популярных языках программирования.

4.4.1 Получение доступа на чтение к объектам

Операции получения доступа к ресурсам операционной системы выполняются посредством драйверов ресурсов. В корректно работающей системе должно выполняться следующее свойство. Свойство драйверов ресурсов 0

При доступе сущности к ресурсу драйвер этого ресурса должен инициировать сравнение уровней целостности сущности и ресурса, реализованное в механизме мандатного контроля целостности. Таким образом, в модели предполагается, что при доступе сущности 5 к объекту о, если над драйвером объекта о не захвачен контроль, то будет выполнено сравнение уровней целостности сущности 5 и объекта о. Если над драйвером захвачен контроль, то будем считать, что сравнение уровней выполнено не будет. В связи с этим модель разработана таким образом, чтобы уровень целостности драйвера был не меньше уровня целостности объектов, которыми он управляет, а также выполнялись определенные гарантии по поводу соотношения уровней целостности драйвера объектов и сущности, получающей доступ к этим объектам.

Рассмотрим операцию получения сущностью х доступа на чтение к объекту у. Эта операция выполняется посредством драйвера й объекта у\ драйвер получает доступ к объекту и передает данные из объекта в сущность х. Возникающие информационные потоки показаны на рис. 5.

х (Ь,х,шгйет) б (у,Ь,шгйет) у

^--------^--------Р

ч /

(У,х,^г'Лет)

Рис. 5. Возможные информационные потоки при получении сущностью х доступа на чтение к

объекту у посредством драйвера d Fig. 5. Information flows that may arise if entity x has acquired read access to object y via driver d В корректно работающей системе драйверы ресурсов должны обладать следующим свойством.

Свойство драйверов ресурсов 1

1. Драйвер ресурсов должен быть реализован таким образом, чтобы информационные потоки от ресурсов, которыми он управляет, не влияли на его корректную работу.

2. При доступе на чтение сущностей к ресурсу, управляемому драйвером, драйвер должен передавать данные из ресурса в неизменном виде.

Свойство 1.1 позволяет не учитывать поток (y,d,writem). Свойство 1.2 позволяет не учитывать поток (d,x,writem). Из этого свойства следует, что достаточно учитывать только информационный поток (у, х, writem) от объекта у к сущности х, получающей к нему доступ на чтение.

В случае, если над драйвером d захвачен контроль, d более не обладает свойством 1. Важным становится информационный поток (d,x,writem), поскольку d может передавать в х произвольные данные. Информационный поток (у, d, writem) можно не учитывать и в этом случае, поскольку над d и так уже захвачен контроль. Получение доступа на чтение к данным с большим или равным уровнем целостности является стандартной операцией.

Случай, когда — (il(x) < И(у)) A (ilr(x) < И(у)), и над сущностью х не захвачен контроль, является особенным: предполагается, что сущность х может безопасно считывать менее целостные данные (либо данные, чей уровень целостности не сравним с il(x), но сравним с ilr(x); в дальнейшем будем называть такие данные просто менее целостными), то есть продолжать функционировать согласно своей спецификации. В этом случае информационных потоков к сущности х не возникает (в предположении, что над сущностью х не захвачен контроль).

В случае, если над драйвером d захвачен контроль, сравнение уровней целостности х и у может не выполняться. Однако ядром операционной системы обеспечивается аналогичное сравнение уровней целостности х и d. Ядро операционной системы также гарантирует выполнение условий OD(y) = d и, следовательно, il(y) < il(d). Таким образом, правило имеет вид:

read(x,d,y): сущность х получает доступ на чтение к объекту у посредством драйвера объектов d.

Предусловие: x,d Е S; у Е О; OD(y) = d;

(il(x) < il(d)) V {—(il(x) < il(d)) A (ilr(x) < il(d)));

d£CS^ (il(x) < il(y)) V (—(il(x) < il(y)) A (ilr(x) < il(y))); il(y) < il(d).

Постусловие: A' = AU {(x,y,reada)}; if d £ CS then {

if il(x) < il(y) A il(x) < il(d)Vx Е CS then F' = F U {(y,x,writem)}

}

else {

if il(x) < il(d) V x Е CS then F' = F U {(y,x,writem), (d,x,writem)}

}.

4.4.2 Получение доступа на запись к объектам

Рассмотрим операцию получения сущностью х доступа на запись к объекту у. Эта операция выполняется посредством драйвера d объекта у: драйвер получает данные для записи от сущности х, доступ к объекту у и записывает полученные данные в объект. Возникающие информационные потоки показаны на рис. 6.

x (x,d,writem) d (d,y,writem) y

к---------------У

(x,y,write m)

Рис. 6. Возможные информационные потоки при получении сущностью х доступа на запись к

объекту у посредством драйвера d Fig. 6. Information flows that may arise if entity x has acquired write access to object y via driver d В корректно работающей системе драйвера ресурсов должны обладать следующим свойством.

Свойство драйверов ресурсов 2

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

2. При доступе на запись сущностей к ресурсу, управляемому драйвером, драйвер должен записывать в ресурс те же данные, которые ему были переданы сущностью.

Свойство 2.1 позволяет не учитывать поток (x,d,writem). Свойство 2.2 позволяет не учитывать поток (d,y,writem).

В случае, если над драйвером d захвачен контроль, d более не обладает свойством 2. Важным становится информационный поток (x, d, writem), поскольку данные от х могут привести к неспецифицированному поведению драйвера d. Информационный поток (d,y,writem) можно не учитывать и в этом случае, поскольку уровень целостности объекта у не больше уровня целостности сущности d, и в рамках модели можно описать захват контроля над у: с помощью последовательности правил write(d, d,y) и control(y), которые будут описаны далее. Таким образом, правило имеет вид:

write(x,d,y): сущность х получает доступ на запись к объекту у посредством драйвера объектов d.

Предусловие: x,d Е S; у Е О; OD(y) = d; d&CS^ il (у) < il(x); il (y) < il(d).

Постусловие: A' = Au {(x,y,writea)}; if d & CS then F' = F u {(x,y,writem)} else F' = F u {(x,y, writem), (x, d, writem)}.

4.4.3 Создание сущностей и объектов, удаление, перемещение, повышение уровня целостности объектов

execute (x, у, s, ils, ilsr): сущность х создает (запускает) сущность s из объекта у с установлением уровней целостности сущности s.

Предусловие: х Е S; у Е О; s & S u О; ils < il(y); ilsr < ils. Постусловие: S' = S u {s}; il'(s) = ils; ilr'(s) = ilsr; if y ECO then F' = F u {(y, s, writem)}.

Если над объектом y захвачен контроль, то возникает информационный поток от у к сущности s с тем, чтобы в дальнейшем можно было моделировать распространение захвата контроля с помощью правила control(s).

В правилах create, create_root, move и delete возникновение информационных потоков объясняется аналогично правилу write.

create(x,y,z,d,ily): сущность х создает объект у посредством драйвера d, включает у в состав контейнера z и устанавливает уровень целостности у в Ну.

Предусловие: x,d Е S; у £ S U О; z Е О; (x,z,writea) Е A; (d,z,writea) Е А; Ну < il(x); Ну < il(z); Ну < il(d).

Постусловие: О' = О U {у}; НО'(z) = HO(z) U {у}; НО'(у) = 0; OD'(y) = d; il'(y) =

Ну;

if dЕCS then { F' = F U {(x,y, writem), (x, d, writem)}; CO' = CO U{y} }. create_root(x,y,d,ily): сущность x создает корневой объект у посредством драйвера d и устанавливает уровень целостности у в Ну.

Предусловие: x,d Е S; у £ S U О; Ну < il(x); Ну < il(d).

Постусловие: О' = О U {у}; CR' = CRU {у}; НО'(у) = 0; OD'(y) = d; il'(y) = ily; if dЕCS then { F' = F U {(x,y, writem), (x, d, writem)}; CO' = CO U{y} }. move(x,y,d,from,to): сущность x перемещает объект у из контейнера from в контейнер to посредством драйвера d.

Предусловие: x,d Е S; у Е О; OD(y) = d; from, to Е О; from Ф to; уф from; у Ф to; у Е НО (from);

(x,from,writea) Е A; (x,to,writea) Е A; (d, from,writea) Е A; (d,to,writea) Е А;

d£CS^ Н(у) < Н(х);

il(y) < il(d); il(y) < il(to).

Постусловие: НО'(from) = HO(from) \ {у};

НО'(to) = HO(to)U{y}.

if d Е CS then F' = F U {(x,y,writem), (x,d,writem)}.

delete(x,y,d,z): сущность x удаляет объект у из контейнера z посредством драйвера d.

Предусловие: x,d Е S; у Е О; z Е О; у Е HO(z); OD(y) = d; (x,z,writea) Е A; (d,z,writea) Е A; HO(y) = 0; il(y) < il(x); il(y) < il(d). Постусловие: О' = О \ {у}; if у Е СО then СО' = СО\ {у}; А'=А\ {(s,y, аа): БЕ5,ааЕ RJ;

F' =F \ ({(x,y,writem):x Е S U 0} U {(y,x,writem):x ЕSU 0});

HO'(z) = HO(z)\{y};

if dЕ CS then F' = F' U {(x,d,writem)}.

upgrade(x,y,z,d,ily): сущность x изменяет уровень целостности объекта у посредством драйвера d, объект у находится в контейнере г, новое значение уровня целостности объекта у равно Ну.

Предусловие: х Е S; у Е О; OD(y) = d; z Е О; UP(x) = true;

il(y) < il(x); ily < il(x); у Е HO(z); ily < il(z); ily < il(d); il(y) < ily.

Постусловие: il' (y) = ily.

4.4.4 Взаимодействие сущностей

Наиболее распространенным случаем межпроцессного взаимодействия является вызов одной сущностью метода другой сущности с тем, чтобы вторая сущность выполнила определенное действие и вернула результат. Если сущность х вызывает метод сущности у, то в рамках такого взаимодействия возможны два информационных потока:

• (x, y, writem) - данные, передаваемые сущностью x при обращении к сущности у за сервисом сущности у (параметры вызываемого метода сущности у).

• (у, х, writem) - данные, возвращаемые сущности х после того, как вызванный метод сущности у завершил свою работу.

В корректной системе должно выполняться следующее предположение. Предположение 1. Поведение сущности не должно приводить к некорректному состоянию системы независимо от того, какие данные ей переданы в результате вызова ее метода.

Таким образом, в случае, если над сущностью у не захвачен контроль, то поток (х,у, writem) учитывать не нужно.

Соотношения уровней целостности сущностей х и у аналогичны случаю получения сущностью доступа на чтение к объекту.

Описанный случай взаимодействия сущностей представлен в модели с помощью правила call:

call(x,y): сущность х вызывает метод сущности у с целью получения данных от сущности у.

Предусловие: х,у 6 S; (il(x) < il(y)) V (-(il(x) < il(y)) A (ilr(x) < il(y))).

Постусловие: if il(x) < il(y) V x 6 CS then { if у & CS then F' = F U {(у, x, writem)} else F' = F U {(y, x, writem), (x, y, writem)} }. В рамках особого случая межпроцессного взаимодействия сущность передает данные менее целостной сущности. Например, сущность может быть подписана на получение данных от более доверенной сущности. В модели такое взаимодействие задано с помощью правила invoke.

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

Таким образом, если над сущностью х не захвачен контроль, то поток (y,x,writem) учитывать не нужно.

invoke(x,y): сущность х вызывает метод сущности у с целью передачи данных сущности у.

Предусловие: х,у 6 S; il(y) < il(x). Постусловие: if х & CS then F' = F U {(x,y,writem)} else F' = F U {(x,y, writem), (y, x, writem)}.

4.4.5 Возникновение неявных информационных потоков

Ранее представленные (де-юре) правила моделируют действия сущностей в системе и определяют информационные потоки, возникающие в результате таких действий. Однако информационные потоки также могут возникать неявно, в результате ранее совершенных действий. Для моделирования возникновения таких потоков в модель добавлены правила, основанные на идее де-факто передач [26]. Следуя [8, 27], будем называть такие правила де-факто правилами.

В отличие от де-юре правил, де-факто правила не предназначены для реализации в операционной системе и используются для целей, связанных с синтезом и анализом модели.

pass(x, z, у): «г передает (passes) данные из х в у».

Предусловие: z Е S; х Е О; у Е S U О; х Ф у; (z,x,reada) Е A; (z,y,writem) Е F; — (—(il(z) < il(x)) Ailr(z) < il(x) V - (il(z) < il(OD(x))) Ailr(z) < il(OD(x)))v z Е CS.

Постусловие: F' = F U {(x,y,writem)}.

Если сущность z может безопасно считывать менее целостные данные с меньшим либо равным уровнем целостности (из объекта х) и над ней не захвачен контроль, то сущность z безусловно не передает эти данные в сущность или объект у, следовательно, информационный поток от х к у не возникает. В остальных случаях передача данных происходит.

сх-

x

reada writem

litem I < У

writem reada writem

Рис. 7. Реализация информационного потока с помощью правила pass Fig. 7. Realization of information flow via the pass de facto rule post(x,z,y): «х отправляет (posts) данные у через z». Предусловие: x,y Е S; z Е О; x Ф у; (y,z,reada) Е A; (x,z,writem) Е F;

-(-(il(y) < il(z))Ailr(y) < il(z)V -i(il(y) < il(OD(z)))Ailr(y) < il(OD(z)f).

Постусловие: F' = F U {(x,y,writem)}.

Элемент предусловия — (—(il(y) < il(z)) A ilr(y) < il(z) V — (il(y) < il(OD(z))) A

ilr(y) < il(OD(z))) говорит о том, что сущность у получила доступ на чтение к объекту

z не как сущность, которая может безопасно считывать менее целостные данные. В ином случае, аналогично правилам read и call, поток от х к у не возникает.

Рис. 8. Реализация информационного потока с помощью правила post Fig. 8. Realization of information flow via the post de facto rule find(x, z, у): «у находит (finds) данные из x через z». Предусловие: x,z Е S; у Е S U О; х Ф у; {(x,z,writem), (z,y,writem)} £ F. Постусловие: F' = F U {(x,y,writem)}.

Рис. 9. Реализация информационного потока с помощью правила find Fig. 9. Realization of information flow via the find de facto rule

z

У

z

4.4.6 Распространение зоны захвата контроля

Для моделирования распространения зоны захвата контроля в модели введено де-факто правило, описывающее изменения множества CS U СО: если к сущности или объекту имеется поток от сущности или объекта из CS U СО, то эта сущность или объект попадает в множество сущностей и объектов, над которыми захвачен контроль. Предусловие этого правила проверяет наличие потока от элемента множества CS U СО, а постусловие добавляет того, к кому этот поток, в множество CS U СО. Таким образом, наличие потока в текущем состоянии приведет к попаданию во множество захваченных в следующем состоянии. В случае, если захват контроля осуществляется над драйвером объектов, контроль также захватывается и над всеми объектами, которыми управляет этот драйвер.

control(x): захват контроля над сущностью или объектом х.

Предусловие: х 6 (S U О) \ (CS U СО); Эу 6 CS U СО. (у, х, writem) 6 F. Постусловие: CS' U СО' = CSUCOU {х}; if х 6S then СО' = СО' U OD-1(x).

4.5 Свойства безопасности, обеспечиваемые моделью

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

Назовем вычислениями без кооперации доверенных и недоверенных сущностей для реализации информационных потоков такие вычисления системы переходов TS, на которых доверенные сущности не инициируют применение правила upgrade. Теорема 1 показывает, что либо возникающие информационные потоки направлены от не менее целостных сущностей или объектов, либо расширение зоны захвата контроля носит строго ограниченный характер. Ограничение заключается в том, что в этом случае в множестве захваченных компонентов всегда уже имеется сущность с уровнем целостности большим либо равным уровню целостности компонента, к которому реализован информационный поток (рис. 10).

Il(u)<il(u" )

Захвачены n. Не захвачены

• \ u" \ write* J / u' u

Рис. 10. Ограничение расширения зоны захвата контроля Fig. 10. Restriction of the area of compromised components

Теорема 1. Для всех состояний G = (S,0,0D,A,F,H0,(il,ilr),UP) EStates системы переходов TS = (States, OP, ^, G0), достижимых из начального состояния G0 и принадлежащих вычислениям системы переходов TS без кооперации доверенных и недоверенных сущностей для реализации информационных потоков, выполняется: Для всех сущностей и объектов и, и' E S U О, если существует информационный поток от и' к и, то либо уровень целостности и меньше либо равен уровню целостности и', либо в множестве сущностей и объектов, находящихся под контролем, существует сущность и'', такая, что уровень целостности и меньше либо равен ее уровню целостности:

VG E Reach(TS).Vu,u' ESUO. (и',u,writem) EF ^ il(u) < il(u')V3u'' E CS.il(u) <

il(u'').

Доказательство. Доказательство утверждения теоремы проведем методом математической индукции по длине пути системы переходов TS. Выберем произвольный путь G0G1G2 ... системы TS. Базис индукции. Длина пути п = 0.

В соответствии с требованиями к начальному состоянию, F0 = 0. Следовательно, доказываемое утверждение верно.

Индуктивная гипотеза. Пусть для некоторого п> 0 верно: Vk < n.Vu,u' E SkU Ok. (и',u,writem) EFk^ ilk(u) < Hk(u') V ^u'' E CSk. ilk(u) <

ilk(u").

Шаг индукции. Рассмотрим переход Gn

^n+i системы переходов TS. Докажем, что Vu,u' E Sn+i U On+i. (u',u,writem) E Fn+i ^ iln+i(u) < iln+i(u') V 3u'' E CSn+i.iln+i(u) < iln+i(u ). Рассмотрим произвольные и,и' E Sn+i U On+i. Предположим, что (и' ,u,writem) E Fn+i (гипотеза). Докажем, что

iln+i(u) < Un+i(u0 V3u'' E CSn+i.iln+i(u) < iln+i(u''). Рассмотрим все правила, порождающие переход Gn ^ Gn+i, и для каждого правила -информационные потоки, которые могут возникнуть в результате применения этого правила.

Правило read (х, d, у).

Случай 1. d CSn. Информационный поток (и' ,u,writem) E Fn+i из гипотезы - это поток (y,x,writem). Если х £ CSn, то, согласно предусловию правила, iln(x) < Ип(у). Следовательно, iln+i(x) < Hn+i(y). Если х E CSn, то в качестве и'' можно выбрать х, поскольку правило read не изменяет множество CS и х E CSn+i.

Случай 2. d E CSn. Информационный поток (и' ,u,writem) E Fn+i из гипотезы - это один из следующих потоков.

(y,x,writem). Если х £ CSn, то < Следовательно, Hn+i

(х) < ип+ i(d), и в

качестве и'' можно выбрать d. Если х E CSn, то в качестве и'' можно выбрать х, поскольку правило read не изменяет множество CS и х E CSn+i.

(d,x,writem). Если х £ CSn, то iln(x) < iln(d). Следовательно, iln+i(x) < iln+i(d), и в качестве и'' можно выбрать d. Если х E CSn, то в качестве и'' можно выбрать х. Правило write(х, d, у).

Случай 1. d £ CSn. Информационный поток (и',u,writem) E Fn+i из гипотезы - это поток (x,y,writem). Согласно предусловию правила, Ип(у) < Ип(х). Следовательно,

H-n+i (у) < H-n+i (X).

Случай 2. d E CSn. Информационный поток (и',u,writem) E Fn+i из гипотезы - это один из следующих потоков.

(x,y,writem). Согласно предусловию, Un(y) < Un(d). Следовательно, Hn+i(y) <

iln+ i(d), и в качестве и'' можно выбрать d.

(x,d,writem). В качестве и'' можно выбрать саму сущность d.

Правило execute(x,y,s,ils,ilsr). Информационный поток (и',u,writem) Е Fn+1 из гипотезы - это поток (у,s,writem). Согласно предусловию правила, ils < iln(y). Следовательно, Ип+1 (s) < Hn+i(y).

Правила create(x,y,z,d,ily), create_root(x,y,d,ily). Информационный поток (и', и, writem) Е Fn+1 из гипотезы - это один из следующих потоков. (x,y,writem). Согласно предусловию, ily < Ип(х). Следовательно, Ип+1(у) < Ип+1(х). (х, d, writem). В качестве и'' можно выбрать саму сущность d.

Правило move(x,y,d,from,to). Информационный поток (и' ,u,writem) Е Fn+1 из гипотезы - это один из следующих потоков.

(x,y,writem). Так как при этом d Е CSn, то, в качестве сущности и'' можно выбрать сущность d, поскольку в соответствии с предусловием iln(y) < iln(d). (х, d, writem). В качестве и'' можно выбрать саму сущность d. Правило delete (х, у, d, z).

Информационный поток из гипотезы - это поток (х, d, writem), возникающий, если d Е CSn. В этом случае d Е CSn+1, и эту сущность можно выбрать в качестве и'' . Правило control не добавляет информационные потоки рассматриваемого вида, не изменяет уровни целостности и не удаляет сущности. Поэтому в соответствии с индуктивной гипотезой в этом случае утверждение шага индукции оказывается истинным. Правило call (х, у).

Случай 1. у £ CSn. Информационный поток из гипотезы - это поток (у, х, writem). Если х £ CSn, то Ип(х) < Нп(у). Следовательно, iln+1(x) < iln+1(y). Если х Е CSn, то в качестве и'' можно выбрать х.

Случай 2. у Е CSn. Информационный поток (и',u,writem) Е Fn+1 из гипотезы - это один из следующих потоков.

(y,x,writem). Если х £ CSn, то iln(x) < iln(y). Следовательно, iln+1(x) < Ип+1(у).

Если х Е CSn, то в качестве и' ' можно выбрать х.

(х,у, writem). В качестве и'' можно выбрать саму сущность у.

Правило invoke(х,у).

Случай 1. х £ CSn. Информационный поток из гипотезы - это поток (x,y,writem). Согласно предусловию, Ип(у) < Нп(х). Следовательно, Нп+1(у) < Нп+1(х). Случай 2. х Е CSn. Информационный поток (и',u,writem) Е Fn+1 из гипотезы - это один из следующих потоков.

(x,y,writem). Поскольку iln(y) < iln(x), то iln+i(y) < Hn+i(x). (y,x,writem). В качестве и'' можно выбрать саму сущность х.

Правило pass(x,z,y). Информационный поток (и',u,writem) Е Fn+1 из гипотезы - это поток (x,y,writem).

Согласно предусловию правила pass, (z,x,reada) Е Ап. Анализ постусловий всех правил показывает, что доступ (z, х, reada) Е Ап мог быть получен только с помощью правила read(z,OD(x),x), где OD(x) - драйвер объекта х. Другими словами, одним из op¡,i = 1, ...,п на вычислении G0op1G1 ...opnGn является op¿ = read(z,OD(x),x),1 < I < п. Поскольку случай, когда сущность z может безопасно получать доступ на чтение менее целостных данных в данном правиле не приводит к возникновению информационных потоков, то, согласно предусловию правила read для случая z £ CS¿

(поскольку драйвер объекта остается неизменным на вычислениях системы переходов TS, для его обозначения будем просто писать OD, без индекса состояния):

1. если OD(x) £ CSt, то ili(z) < ilt(x);

2. если OD(x) E CSL, то ilL(z) < ill(OD(x)).

Поскольку уровни целостности и факты захвата контроля не меняются на вычислениях системы переходов TS, итого имеем

(OD(x) £ CSn Л iln(z) < iln(x)) V (oD(x) E CSn Л iln(z) < iln(OD(x)j) VzE CSn.

Согласно предусловию правила pass также имеем (z,y,writem) E Fn. Согласно индуктивной гипотезе,

Un(y) < Hn(z)V3u'' E CSn.iln(y) < iln(u''). Если Би'' E CSn.iln(u) < iln(u''), то сразу заключаем Би'' E CSn+i.iln+i(y) < Un+i(u' ').

Если iln(y) < iln(z), то имеем три случая:

1. Un(y) < Hn(z) лИп(г) < iln(x), следовательно, iln(y) < Ип(х), а значит

H-n+i (у) < H-n+i СО;

2. Un(y) < Hn(z) лИп(г) < iln(OD(x)j, следовательно, iln(y) < iln(OD(x)j, а значит iln+i(y) < iln+i{OD(x)). Поскольку в этом случае OD(x) E CSn+i, то в качестве искомого и'' E CSn+i можно взять OD(x) ;

3. iln(y) < iln(z) Лг E CSn, следовательно, z E CSn+i ЛИ^^) < iln+i(z), и в качестве искомого и'' E CSn+i можно взять z.

Таким образом, проанализированы все возможные случаи, и можно заключить, что

iln+iW < ^n+i(x) V Би'' E CSn+i.iln+i(y) < iln+i(u''). Правило post(x,z,y). Информационный поток (и',u,writem) E Fn+i из гипотезы - это поток (x,y,writem).

Согласно предусловию правила post, (y,z,reada) E Ап. Следовательно,

(OD(z) £ CSn Л Un(y) < iln(z)) V (0D(z) E CSn Л Un(y) < iln(OD(z)j)V у E CSn.

Согласно предусловию правила post также имеем (x,z,writem) E Fn. В соответствии с индуктивной гипотезой,

iln(z) < iln(x) VБu'' E CSn.iln(z) < iln(u''). Если Би'' E CSn.iln(z) < iln(u''), то Би'' E CSn+i.iln+i(z) < iln+i(u''). Имеем три случая:

1. Би'' E CSn.iln(z) < iln(u'') ЛИп(у) < iln(z), следовательно, Би''E CSn. iln(y) < iln(u''), а значит Би'' E CSn+i. iln+i(y) < Hn+i(u'').

2. Би'' E CSn.iln(z) < iln(u'') ЛИп(у) < iln(OD(z)j, следовательно, iln+i(y) < Un+i(OD(z)j. Поскольку в этом случае OD(z) E CSn+i, то в качестве искомого и' ' E CSn+i можно взять OD(z);

3. Би'' E CSn. iln(z) < iln(u'') Л у E CSn, следовательно, у E CSn+i, и в качестве искомого и' ' E CSn+i можно взять саму сущность у.

Если iln(z) < iln(x), то имеем три случая:

1. iln(z) < Ип(х) ЛИп(у) < iln(z), следовательно, iln(y) < Ип(х), а значит

Hn+i (у) < СО;

2. iln(z) < iln(x) Л iln(y) < iln(OD(z)j, следовательно, iln+i(y) < iln+i(OD(z)j. Поскольку в этом случае OD(z) E CSn+i, то в качестве искомого и'' E CSn+i можно взять OD(z);

3. Hn(z) < iln(x) Ay E CSn, следовательно, у E CSn+1, и в качестве искомого и'' E CSn+1 можно взять саму сущность у. Таким образом, проанализированы все возможные случаи, и можно заключить, что

Нп+1(У) < Hn+i(x)V3u'' E CSn+i.iln+i(y) < iln+i(u''). Правило find(x,z,y). Информационный поток (и',u,writem) E Fn+1 из гипотезы - это поток (x,y,writem).

Согласно предусловию правила, {(x,z,writem),(z,y,writem)} Q Fn. Следовательно, в соответствии с индуктивной гипотезой,

(iln(z) < iln(x) V Зи'' E CSn. iln(z) < iln(u''))

A (iln(y) < iln(z) V Зи'' E CSn. iln(y) < Hn(u'')).

Итого имеем четыре случая:

1. iln(z) < Нп(х) A iln(y) < iln(z), следовательно, iln+1(y) < iln+1(x);

2. iln(z) < iln(x) A Зи'' E CSn. iln(y) < iln(u''), следовательно, Зи'' E С$п+1.Нп+1(У>) < Нп+1(и ).

3. Нп(у) < iln(z) A Зи'' E CSn. iln(z) < iln(u''), следовательно, Зи'' E

(y) < H-n+1 (W).

4. (Зи '' E CSn. iln(z) < iln(u'')) A (Зи '' E CSn. iln(y) < iln(u'')), следовательно, Зи'' E CSn+1.iln+1(y) < iln+1(u'').

Таким образом, проанализированы все возможные случаи, и можно заключить, что Нп+1(У) < Hn+1(x) V Зи'' E CSn+1.iln+1(y) < iln+1(u'').

Теорема доказана.

5. Пример использования политики мандатного контроля целостности

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

• Downloader загружает образ обновления с удаленного ресурса. Это приложение напрямую взаимодействует с недоверенной удаленной системой, и потенциально над ним может быть захвачен контроль. Поэтому данному приложению назначен низкий уровень целостности.

• Verifier проверяет цифровую подпись образа обновления. Это доверенное приложение, которое может считывать низкоцелостный образ обновления с целью проверки его цифровой подписи.

• Updater обновляет систему. Это доверенное приложение, которое должно получать данные только из высокоцелостных файлов.

• FileSystem реализует файловое хранилище (является драйвером для файлов). Эти приложения реализуют следующий сценарий. Downloader загружает образ обновления и сохраняет его с использованием сервисов FileSystem. Затем Verifie r проверяет цифровую подпись образа обновления. Если подпись является корректной, приложение дает инструкцию FileSystem на создание нового высокоцелостного файла, который является копией оригинального образа обновления. Наконец, Updater считывает новый файл и применяет обновление.

5.1 Определение интерфейсов

Перед написанием политики безопасности необходимо определить интерфейсы компонентов системы.

Следующий фрагмент определяет интерфейс операционной системы, который используется ядром для сообщения монитору безопасности о создании новых сущностей:

interface execute {

exec (in Handle image);

}

Указанный в этом интерфейсе метод exec используется для создания новых сущностей. Метод принимает идентификатор образа, из которого необходимо создать новую сущность.

Следующий фрагмент определяет интерфейс, по которому сущность FileSystem передает необходимый контекст монитору безопасности: interface FileSystem_Security { create (in Handle client,

in Handle directory, in Handle object, in Label label);

// ...

}

Интерфейс определяет, как FileSystem взаимодействует с монитором безопасности для контроля доступа к файлам. В частности, когда FileSystem создает новые объекты, оно отправляет сообщение с использованием метода create. В ответ сущность получает решение о предоставлении доступа, в соответствии с которым она должна продолжить свою работу. Следовательно, драйвер ресурсов предоставляет контекст и действует согласно решениям о предоставлении доступа к его ресурсам, а монитор безопасности реализует политику безопасности. Также определяется интерфейс самой сущности FileSystem: interface FileSystem { // .

write (in Handle object, in Data data, out DataLength count, out RetCode ret); read (in Handle object,

in DataLength count, out Data data, out RetCode ret);

}

Другие приложения могут использовать этот интерфейс для работы с файлами.

5.2 Определение политики безопасности

Для определения политики безопасности системы необходимо разработать спецификацию на языке PSL. Мандатный контроль целостности представлен в языке классом политик mandatory_integrity_control, который определяет множество правил, соответствующих правилам модели. Спецификация политики безопасности определяет соответствие этих правил и взаимодействий в системе. При каждой попытке взаимодействия монитор безопасности исполняет правила для определения решения о допустимости взаимодействия.

Для использования класса политик необходимо создать на его основе объект политики, указав для него конфигурацию. Для объекта класса

mandatory_i ntegrity_control необходимо указать уровни целостности. Политика безопасности определяет для каждого межпроцессного взаимодействия, какие правила класса политик будут исполнены монитором для разрешения или запрета взаимодействия. В число таких взаимодействий входят создание сущностей и объектов и другие взаимодействия.

В нашем примере сначала определяется объект политик integrity как экземпляр класса mandatory_integrity_control: policy object integrity =

mandatory_integrity_control { config : {

levels : ["LOW", "MEDIUM", "HIGH"]

}

}

В конфигурации этого объекта политик указаны три уровня целостности LOW, MEDIUM и HIGH. Если уровни целостности заданы в виде списка значений (как в данном примере), то задан полный порядок на множестве уровней целостности. Следовательно, LOW < MEDIUM < HIGH.

Далее задается политика создания сущностей: execute method=exec, dst=Downloader { integrity.execute { target : dst, image : message.image, level : "LOW" }

}

execute method=exec, dst=Verifier { integrity.execute { target : dst, image : message.image, level : "HIGH", levelR: "LOW" }

}

execute method=exec, dst=Updater { integrity.execute { target : dst, image : message.image, level : "HIGH" }

}

execute method=exec, dst=FileSystem { integrity.execute { target : dst, image : message.image, level : "HIGH" }

}

Язык спецификации политик предоставляет директиву execute для назначения правил, которые должны быть исполнены монитором безопасности при создании сущностей, и предоставления монитору необходимого контекста. В данном примере ядро предоставляет контекст посредством метода exec интерфейса execute. Доступ к этому контексту может быть получен посредством объекта message (например, message.image). Также неявно передаются два идентификатора: src -идентификатор сущности, обратившейся к ядру для создания новой сущности с идентификатором dst.

Правило integrity.execute имеет следующие параметры: target определяет создаваемую сущность, image определяет объект, из которого должна быть создана сущность, level и level R задают уровни целостности (ils и ilsr в правиле execute) новой сущности. Если levelR опущен, то 1evelR=1 evel.

Секция request соответствует всем IPC-запросам (первым частям синхронного межпроцессного взаимодействия) и подразумевает два неявным параметра: src для инициатора запроса и dst для получателя. Следующий фрагмент определяет, что для каждого IPC-запроса, integrity.call применяет правило call с аргументами source (src) и target (dst). request {

integrity.call { source : src, target : dst }

}

Секция security соответствует прямым обращениям сущностей к монитору безопасности. В ней есть неявный параметр src - идентификатор этой сущности. При создании файлов FileSystem, как драйвер файловых ресурсов, предоставляет контекст монитору безопасности путем вызова метода create интерфейса Fi1eSystem_Security: security src=Fi1eSystem { match method=create { integrity.create {

initiator : message.client, target : message.object, container : message.directory, driver : src, level : message.label }

}

}

Сообщения, которые FileSystem отправляет монитору безопасности, предоставляют следующий контекст:

• идентификатор сущности, которая инициирует запрос на создание объекта (message. client);

• идентификатор объекта, который должен быть создан (message.object). Этот идентификатор создается сущностью Fi leSystem;

• идентификатор контейнера, в котором объект должен быть создан (message.directory). Контейнер определяется сущностью FileSystem и не может иметь уровень целостности, больший, чем уровень целостности сущности FileSystem;

• идентификатор драйвера файловых ресурсов (src);

• метка, определяющая уровень целостности, который должен быть назначен создаваемому файлу (message . label).

Если container не указан, то данная операция соответствует правилу create_root, и initiator должен быть равен driver. Только драйверы могут создавать корневые контейнеры для ресурсов, которые они предоставляют. Следовательно, уровень целостности драйвера никогда не может быть ниже уровня целостности его ресурсов. Правила, соответствующие запросам на чтение и запись к FileSystem, определяются следующим образом: request dst=Fi1eSystem { match method=read { integrity.read {

reader : src,

object : message.object }

}

match method=write { integrity.write { writer : src, object : message.object }

}

}

Методы read и write сущности FileSystem соответствуют правилам модели read(reader, FileSystem, object) и write (writer, FileSystem, object) соответственно, то есть происходит автоматическое указание драйвера объекта равным параметру методов dst.

5.3 Применение политики

Рассмотрим, как разработанная политика позволяет обеспечивать целостность системы (рис. 11). В соответствии с данной политикой, загруженный образ обновления имеет уровень целостности LOW. Verifier может считать данный файл и проверить его цифровую подпись. Если верификация успешна, Verifier создает новый файл с содержимым старого файла и уровнем целостности HIGH. Для применения обновления сущность Updater должна получить доступ на чтение к образу обновления посредством метода read сущности Fil eSystem. Определение того, будет ли данный доступ предоставлен или нет, происходит в соответствии с правилом read. Это означает, что монитор безопасности выполняет следующие проверки:

(il(Updater) < il(f )) V (—(H(Updater) < il(f)) A (ilr(Updater) < il(f))),

il(f) < il(FileSystem), где f - идентификатор образа обновления. Если файл был верифицирован, то H(f) = HIGH, и условие il(Updater) < il(f) истинно. Следовательно, монитор безопасности разрешит предоставление рассматриваемого доступа, и Updater сможет применить обновление.

Если файл не был верифицирован, то il(f) = LOW, и условие il(Updater) < il(f) ложно. Вторая часть дизъюнкции также ложна, поскольку хоть и — (il(Updater) < il(f)) истинно, но ilr(Updater) < il(f) ложно. Следовательно, монитор безопасности запретит выдачу такого доступа на чтение, и Updater не сможет применить обновление. Таким образом, монитор безопасности предотвратит попытки обновления системы с использованием образов обновления, уровень целостности которых не равен HIGH.

Предположим, что существует еще одна файловая система с уровнем целостности MEDIUM. В этом случае с использованием ее сервисов сущность Downloader смогла бы записать образ обновления, сущность Verifier - проверить его, но сущность Updater не смогла бы получить доступ на чтение к этому файлу. Это связано с тем, что правило по получению доступа на чтение к объекту проверяет, что уровень целостности этого объекта не выше уровня целостности драйвера, посредством которого осуществляется доступ. Другими словами, для доступа к файлу f посредством драйвера driver условие

il(Updater) = HIGH A il(Updater) < il(f) A il(f) < il(driver) может быть удовлетворено только если HIGH < il(driver), что не выполняется, если il(driver) = MEDIUM. Таким образом, если система содержит драйверы с различными

уровнями целостности, то политика мандатного контроля целостности автоматически

Fig. 11. Update image processing and application scheme. F is the image file

6. Заключение

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

Сформулирована и доказана теорема о допущении моделью либо только разрешенных информационных потоков, либо об ограничении зоны захвата контроля в случае наличия захваченных компонентов. Разработан язык спецификации политик мандатного контроля целостности. Транслятор этого языка создает исполнимый монитор безопасности, выполняющий проверки мандатного контроля целостности при доступе к ресурсам приложений, работающих под управлением операционной системы KasperskyOS. Продемонстрирован пример использования языка для разработки политики безопасности системы с безопасным обновлением. Показано, как мандатный контроль целостности запрещает использование образов обновления с непроверенной цифровой подписью.

Список литературы / References

[1]. Jaeger T. Operating System Security. Morgan and Claypool Publishers, 2008, 220 p.

[2]. Landwehr C. Formal Models for Computer Security. ACM Computing Surveys, vol. 13, issue 3, 1981, pp. 247-278.

[3]. Федеральная служба по техническому и экспортному контролю. Информационное сообщение о требованиях по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий от 29 марта 2019 г. / FSTEC Russia. Information message on information security requirements establishing levels of confidence in information security tools and information technology security tools dated March 29, 2019. Available at: https://fstec.ru/normotvorcheskaya/informatsionnye-i-analiticheskie-materialy/1812-

informatsionnoe-soobshchenie-fstek-rossii-ot-29-marta-2019-g-n-240-24-1525 (in Russian), accessed 14.01.2020.

[4]. Young M. et al. The duality of memory and communication in the implementation of a multiprocessor operating system. In Proc. of the 11th Symposium on Operating Systems Principles, 1987, pp. 63-76.

[5]. Hohmuth M., Peter M., Hartig H., Shapiro J. Reducing TCB Size by Using Untrusted Components: Small Kernels versus Virtual-Machine Monitors. In Proc. of the 11th ACM SIGOPS European Workshop, 2004..

[6]. Biggs S., Lee D., Heiser G. The Jury Is. In Proc. of the 9th Asia-Pacific Workshop on Systems. 2018, Article No. 16.

[7]. Herder J. N., Bos H., Gras B., Homburg P., Tanenbaum A. S. Construction of a Highly Dependable Operating System. In Proc. of the Sixth European Dependable Computing Conference, 2006, pp. 312.

[8]. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками. Горячая линия-Телеком, 2013, 338 с. / Devyanin P.N. Security models of computer systems. Control for access and information flows. Hotline-Telecom, 2013, 338 p. (in Russian).

[9]. Biba K. Integrity Considerations for Secure Computer Systems. Technical report MTR-3153, The MITRE Corporation, 1977.

[10]. Lipner S. Non-Discretionary Controls for Commercial Applications. In Proc. of the 1982 IEEE Symposium on Security and Privacy, 1982. pp. 2-10.

[11]. Clark D., Wilson D. A Comparison of Commercial and Military Computer Security Policies. In Proceedings of the 1987 IEEE Symposium on Security and Privacy, 1987, pp. 184-195.

[12]. Lee, T. Using Mandatory Integrity to Enforce "Commercial" Security. In Proc. of the 1988 IEEE Symposium on Security and Privacy, 1988, pp. 140-146.

[13]. Brewer D., Nash M. The Chinese Wall Security Policy. In Proc. of the 1989 IEEE Symposium on Security and Privacy, 1989, pp. 206-214.

[14]. Liu Z., Wang T., Li W. An Integrity Control Model for Operating System. In Proc. of the 2009 International Conference on Management and Service Science, 2009, pp. 1-4.

[15]. Bell D., LaPadula L. Secure Computer System: Unified Exposition and Multics Interpretation. Technical Report MTR-2997 Rev. 1, The MITRE Corporation, 1976.

[16]. Li N., Mao Z., Chen H. Usable Mandatory Integrity Protection for Operating Systems. In Proc. of the 2007 IEEE Symposium on Security and Privacy, 2007, pp. 164-178.

[17]. Zhai E. et al. SecGuard: Secure and Practical Integrity Protection Model for Operating Systems. In Proc.of the 13th Asia-Pacific Web Conference, 2011, pp. 370-375.

[18]. Devyanin P. et al. Using Refinement in Formal Development of OS Security Model. Lecture Notes in Computer Science, vol. 9609. 2015, pp. 107-115.

[19]. Devyanin P. et al. Formal Verification of OS Security Model with Alloy and Event-B. Lecture Notes in Computer Science, vol. 8477, 2014, pp. 309-313.

[20]. П.Н. Девянин и др. Моделирование и верификация политик безопасности управления доступом в операционных системах. Горячая линия-Телеком, 20196 214 стр. / P.N. Devyanin, D.V. Efremov, V.V. Kulyamin, A.K. Petrenko, A.V. Khoroshilov, I.V. Shchepetkov. Modeling and verification of access control security policies in operating systems. Hotline - Telecom, 2019, 214 p.

[21]. Yosifovich P., Russinovich M., Solomon D., Ionescu A. Windows Internals, Part 1: System architecture, processes, threads, memory management, and more (7th Edition). Microsoft Press. 2017. 800 p.

[22]. Rushby J. Design and Verification of Secure Systems. In Proc. of the 8th ACM Symposium on Operating Systems Principles, 1981, pp. 12-21.

[23]. Alves-Foss J., Oman P., Taylor C. The MILS Architecture for High-Assurance Embedded Systems. International Journal of Embedded Systems, vol. 2, no. 3/4, 2006, pp. 239-247.

[24]. Spencer R., Smalley S., Loscocco P., Hibler M., Andersen D., Lepreau J. The Flask Security Architecture: System Support for Diverse Security Policies. In Proc. of the 8th USENIX Security Symposium, 1999.

[25]. Baier C., Katoen J.-P. Principles of Model Checking. The MIT Press. 2008. 975 pp.

[26]. Bishop M., Snyder L. The Transfer of Information and Authority in a Protection System. In Proc. of the 7th ACM symposium on Operating systems principles, 1979, pp. 45-54.

[27]. Bishop M. Conspiracy and Information Flow in the Take-Grant Protection Model. Journal of Computer Security, vol. 4, no. 4, 1996, pp. 331-359.

Информация об авторах / Information about authors

Владимир Сергеевич БУРЕНКОВ - кандидат технических наук, разработчик-исследователь. Сфера научных интересов: модели программно-аппаратных систем, формальные методы верификации.

Vladimir Sergeevich BURENKOV - PhD, research developer. Research interests: models of computer systems, formal verification methods.

Дмитрий Александрович КУЛАГИН - кандидат технических наук, ведущий разработчик. Сфера научных интересов: информационная безопасность, компиляторы, операционные системы.

Dmitry Aleksandrovich KULAGIN - PhD, development team lead. Research interests: information security, compilers, operating systems.