KasperskyOS: обзор

Основные понятия KasperskyOS

Решение на базе KasperskyOS

Решение на базе KasperskyOS состоит из ядра, модуля безопасности, а также прикладного и системного ПО, интегрированных для работы в составе программно-аппаратного комплекса. Процессы в KasperskyOS называются сущностями. Ядро гарантирует, что сущности изолированы и могут взаимодействовать только через ядро (с помощью системных вызовов). Каждая сущность в решении имеет статическое описание, определяющее интерфейсы, доступные другим сущностям. Для описания интерфейсов используются специально разработанные языки – EDL, CDL и IDL.

Кибериммунный подход

Для разработки безопасных решений на базе KasperskyOS используется кибериммунный подход. Этот подход основан на выборе способа разбиения системы на сущности и задании определенных правил их взаимодействия (т.н. политика безопасности решения). Политика безопасности реализуется модулем безопасности Kaspersky Security Module, который входит в решение.

Подробнее о кибериммунном подходе

Kaspersky Security System

Технология Kaspersky Security System позволяет разрабатывать и реализовывать разнообразные политики безопасности. При этом можно комбинировать несколько моделей безопасности, добавлять свои модели и гибко настраивать правила взаимодействия сущностей. Для формального описания политики безопасности решения используется специально разработанный язык PSL. На основе PSL-описания генерируется модуль безопасности Kaspersky Security Module для использования в конкретном решении.

KasperskyOS Community Edition

KasperskyOS Community Edition содержит инструменты для разработки безопасных решений на базе KasperskyOS, включая:

• образ ядра операционной системы KasperskyOS;
• компилятор NK, предназначенный для генерации модуля безопасности Kaspersky Security Module и вспомогательного транспортного кода;
• прочие инструменты для разработки решения (компилятор GCC, отладчик GDB, набор утилит binutils, эмулятор QEMU и сопутствующие инструменты);
• набор библиотек, обеспечивающих частичную совместимость со стандартом POSIX;
• компоненты KasperskyOS Community Edition;
• документацию;
• примеры простейших решений на базе KasperskyOS.

Кибериммунитет

Концепция кибериммунитета основана на следующих понятиях:

• цели и предположения безопасности;
• понятия модели MILS (домен безопасности, ядро разделения и монитор обращений);
• доверенная вычислительная база (TCB).

Ниже рассмотрены эти понятия, после чего даны определения кибериммунной системы и кибериммунного подхода.

Цели и предположения безопасности

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

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

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

Понятия модели MILS

В рамках модели MILS (Multiple Independent Levels of Security) безопасная информационная система состоит из изолированных доменов безопасности и ядра разделения, контролирующего взаимодействия доменов друг с другом. Ядро разделения обеспечивает изоляцию доменов и управление информационными потоками между ними.

Каждая попытка взаимодействия между доменами безопасности проверяется на соответствие определенным правилам, которые задаются политикой безопасности системы. Если взаимодействие запрещено текущей политикой, оно не пропускается (блокируется). Политику безопасности в архитектуре MILS реализует отдельный компонент – монитор обращений. Для каждого взаимодействия доменов безопасности монитор обращений возвращает решение (булево значение), соответствует ли это взаимодействие политике безопасности. Ядро разделения вызывает монитор каждый раз, когда один домен обращается к другому.

Доверенная вычислительная база (TCB)

Доверенная вычислительная база (Trusted Computing Base, TCB) – совокупность всего программного кода, уязвимость в котором приводит к невозможности выполнения информационной системой заданных целей безопасности. В модели MILS ядро разделения и монитор обращений составляют основу доверенной вычислительной базы.

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

Кибериммунная система

Информационная система является кибериммунной (или обладает кибериммунитетом), если она разделена на изолированные домены безопасности, все взаимодействия между которыми независимо контролируются, и предоставляет:

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

Кибериммунный подход

Кибериммунный подход – это способ построения кибериммунных систем.

Кибериммунный подход основан на:

• разбиении системы на изолированные домены безопасности;
• независимом контроле всех взаимодействий между доменами безопасности на соответствие заданной политике безопасности;
• обеспечении надежности доверенной кодовой базы.

Преимущества кибериммунного подхода

Кибериммунный подход позволяет:

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

Изоляция и взаимодействие сущностей

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

Сущности

Каждый процесс в KasperskyOS – это субъект в политике безопасности решения. При запуске процесса ядро KasperskyOS ассоциирует с ним контекст, необходимый для его исполнения, а модуль Kaspersky Security Module – контекст безопасности, необходимый для контроля его взаимодействий с другими процессами.

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

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

Дополнительная информация по сущностям

Для модуля безопасности Kaspersky Security Module ядро является таким же субъектом, как и сущности. Сущности могут вызывать методы ядра, и эти взаимодействия контролируются аналогично вызовам методов других сущностей. Поэтому далее мы будем говорить, что ядро является отдельной сущностью с точки зрения Kaspersky Security Module.

Взаимодействие сущностей (IPC)

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

Клиент и сервер используют три системных вызова: Call(), Recv() и Reply():

1. Клиент направляет серверу сообщение-запрос. Для этого один из потоков исполнения клиента выполняет вызов Call() и блокируется до получения ответа от сервера или ядра (например, в случае ошибки).
2. Серверный поток, выполнивший вызов Recv(), находится в ожидании сообщений. При получении запроса этот поток разблокируется, обрабатывает запрос и отправляет сообщение-ответ с помощью вызова Reply().
3. При получении сообщения-ответа (или ошибки) клиентский поток разблокируется и продолжает исполнение.

   

Обмен сообщениями как вызов метода

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

IPC‑каналы

Чтобы две сущности могли обмениваться сообщениями, между ними должен быть установлен IPC-канал (далее также канал или соединение). Канал задает роли сущностей, т.е. имеет "клиентскую" и "серверную" стороны. При этом одна сущность может иметь несколько каналов, в которых она является клиентом, и несколько каналов, где она – сервер.

В KasperskyOS предусмотрено два способа создания IPC-каналов:

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

Описания интерфейсов сущности (EDL, CDL, IDL)

Для контроля взаимодействий между сущностями необходимо, чтобы структура пересылаемых IPC-сообщений была прозрачна для модуля безопасности. В KasperskyOS это достигается с помощью статического декларирования интерфейсов сущностей. Для этого используются специальные языки: Entity Definition Language (EDL), Component Definition Language (CDL) и Interface Definition Language (IDL). Если IPC-сообщение не соответствует описанию интерфейса, оно будет отклонено модулем безопасности.

Виды статических описаний

Описание интерфейсов сущности строится по модели "сущность-компонент-интерфейс":

• IDL‑описание декларирует интерфейс, а также пользовательские типы и константы (опционально). В сумме все IDL-описания решения охватывают все реализуемые в решении интерфейсы.
• В CDL-описании перечислены интерфейсы, реализуемые компонентом. Компоненты дают возможность группировать реализации интерфейсов. Компоненты могут включать в себя другие компоненты.
• В EDL-описании сущности декларируются экземпляры компонентов, входящие в эту сущность. В частности, сущность может не включать в себя ни один компонент.

Пример

Ниже приведены статические описания решения, состоящего из сущности Client, не реализующей ни одного интерфейса, и сущности Server, реализующей интерфейс FileOps.

См. подробнее о синтаксисе статических описаний.

IPC-транспорт

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

Транспортный код для разрабатываемых компонентов

Разработчик новых компонентов для KasperskyOS может сгенерировать транспортный код на основе статических описаний этого компонента. Для этого в составе KasperskyOS Community Edition поставляется компилятор NK. Компилятор NK позволяет генерировать транспортные методы и типы для использования как на клиентской стороне, так и на серверной.

Транспортный код для поставляемых компонентов

Функциональность большинства компонентов, поставляемых в составе KasperskyOS Community Edition, может быть использована в решении как локально, т.е. путем статической компоновки с разрабатываемым кодом, так и через IPC.

Для вынесения компонента в отдельную серверную сущность и использования его по IPC поставляются следующие транспортные библиотеки:

• Клиентская библиотека компонента преобразует локальные вызовы в IPC-запросы к сущности драйвера.
• Серверная библиотека компонента принимает IPC-запросы к сущности драйвера и преобразует их в локальные вызовы.

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

Подробнее см. "IPC и транспорт".

Контроль взаимодействий

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

Модуль безопасности Kaspersky Security Module

Технология Kaspersky Security System позволяет под каждое разрабатываемое решение сгенерировать код модуля безопасности Kaspersky Security Module, реализующего заданную политику безопасности. Модуль безопасности контролирует все взаимодействия между сущностями, т.е. является монитором безопасности в терминах MILS.

Контроль IPC-сообщений

Ядро обращается к модулю безопасности Kaspersky Security Module каждый раз, когда одна сущность отправляет сообщение другой сущности. Модуль безопасности проверяет, что структура сообщения соответствует описанию вызываемого метода. Если это так, модуль безопасности вызывает все связанные с этим сообщением правила и выносит решение: "разрешено" или "запрещено". Ядро применяет полученное решение, т.е. доставляет сообщение, только если это разрешено.

IPC-ответы подлежат контролю, как и IPC-запросы. Это может использоваться, например, чтобы гарантировать целостность ответов.

Ядро доставляет IPC-сообщение, только если Kaspersky Security Module разрешает доставку

Контроль запуска сущностей

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

Интерфейс безопасности

Сущности могут напрямую обращаться к Kaspersky Security Module, с помощью интерфейса безопасности, чтобы сообщить о своем состоянии или о контексте какого-либо события. При этом модуль безопасности применяет все правила, связанные с вызываемым методом интерфейса безопасности. Далее сущность может сама использовать полученное от модуля безопасности решение. Интерфейс безопасности используется, например, для реализации сущностей, управляющих доступом к ресурсам.

Язык описания политик PSL

Важнейшая часть технологии Kaspersky Security System – это язык PSL (Policy Specification Language). Он позволяет формально, близко к терминам самой задачи, описать политику безопасности решения. На основе полученного psl-описания генерируется код модуля безопасности Kaspersky Security Module под конкретное решение. Для этого используется компилятор NK, поставляемый в составе KasperskyOS Community Edition. Таким образом, psl-описание решения является связующим звеном между неформальным описанием политики и ее реализацией.

Язык PSL позволяет использовать различные структуры данных и комбинировать несколько моделей безопасности.

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

Виды ресурсов

В KasperskyOS есть два вида ресурсов:

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

Дескрипторы

Как системные, так и пользовательские ресурсы идентифицируются дескрипторами (англ. handles). Получая дескриптор, процесс получает доступ к ресурсу, который этот дескриптор идентифицирует. Процессы могут передавать дескрипторы другим процессам. Один и тот же ресурс может идентифицироваться несколькими дескрипторами, которые используют разные процессы.

Идентификаторы безопасности (SID)

Для системных и пользовательских ресурсов ядро KasperskyOS назначает идентификаторы безопасности. Идентификатор безопасности (англ. Security Identifier, SID) – это глобальный уникальный идентификатор ресурса (то есть у ресурса есть только один SID, а дескрипторов может быть несколько). Модуль безопасности Kaspersky Security Module идентифицирует ресурсы по их SID.

Контекст безопасности

Технология Kaspersky Security System позволяет применять механизмы безопасности, которые принимают на вход значения SID. При применении таких механизмов модуль безопасности Kaspersky Security Module различает ресурсы (и ядро KasperskyOS) и связывает с ними контексты безопасности. Контекст безопасности представляет собой данные, ассоциированные с SID, которые используются модулем безопасности для принятия решений.

Содержимое контекста безопасности зависит от используемых моделей безопасности. Контекст безопасности может содержать, например, состояние ресурса, уровни целостности субъектов и/или объектов доступа. Если контекст безопасности хранит состояние ресурса, это позволяет, например, разрешить выполнять действия над ресурсом, если только этот ресурс находится в каком-либо конкретном состоянии.

Модуль безопасности может изменять контекст безопасности, когда принимает решение. Например, могут изменяться сведения о состоянии ресурса (модуль безопасности проверил по контексту безопасности, что файл находится в состоянии "не используется", разрешил открыть файл на запись и записал в контекст безопасности этого файла новое состояние "открыт на запись").

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

Ядро KasperskyOS управляет доступом к ресурсам одновременно двумя взаимодополняющими способами: выполняя решения модуля безопасности Kaspersky Security Module и реализуя механизм безопасности на основе мандатных ссылок (англ. Object Capability, OCap).

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

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

Процессы, которые управляют пользовательскими ресурсами и доступом к этим ресурсам для других процессов, являются поставщиками ресурсов. (Поставщиками ресурсов являются, например, драйверы.) Поставщики управляют доступом к ресурсам двумя взаимодополняющими способами: выполняя решения модуля безопасности Kaspersky Security Module и используя механизм OCap, который реализуется ядром KasperskyOS.

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

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

Надежность TCB

Кибериммунная система должна предоставлять гарантии надежности всей доверенной вычислительной базы (TCB). Такие гарантии могут быть предоставлены, только если доверенная вычислительная база достаточно компактна. Ниже мы рассмотрим, как это требование реализуется в решениях на базе KasperskyOS.

Микроядерная архитектура

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

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

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

Надежность доверенных компонентов

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

Вынос доверенного компонента в отдельную сущность

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

Создание дубликатов компонента

Ещё один способ повысить надежность TCB – это ограничение влияния недоверенных компонентов на доверенные путем разделения их информационных потоков. Для этого один и тот же компонент может быть независимо использован в составе нескольких сущностей. Например, за реализации файловых систем и сетевого стека в KasperskyOS отвечает компонент VFS. Если включить экземпляры VFS в разные сущности, каждая из них будет работать с собственной реализацией файловой системы и/или сетевого стека. Таким образом достигается разделение информационных потоков доверенных и недоверенных сущностей и, соответственно, увеличение надежности TCB.

Образ решения на базе KasperskyOS

Загружаемый образ конечного решения на базе KasperskyOS содержит:

• образ ядра KasperskyOS;
• модуль безопасности;
• сущность Einit, которая запускает остальные сущности;
• все сущности, входящие в решение (включая драйверы, служебные сущности и сущности, реализующие бизнес-логику).

Сборка образа решения

Образ решения собирается при помощи специального скрипта, который поставляется в составе KasperskyOS Community Edition.

Образ ядра KasperskyOS, а также служебные сущности и сущности-драйверы поставляются в составе KasperskyOS Community Edition. Модуль безопасности и сущность Einit собираются под каждое конкретное решение.

Запуск решения

Запуск решения происходит следующим образом:

1. Загрузчик загружает ядро KasperskyOS.
2. Ядро находит и загружает модуль безопасности.
3. Ядро запускает сущность Einit.
4. Сущность Einit запускает все остальные сущности, входящие в решение.