Что нового

В KasperskyOS Community Edition 1.0 появились следующие возможности и доработки:

• Добавлена поддержка аппаратной платформы Raspberry Pi 4 Model B.
• Добавлена поддержка SD-карты для аппаратной платформы Raspberry Pi 4 Model B.
• Добавлена поддержка Ethernet для аппаратной платформы Raspberry Pi 4 Model B.
• Добавлена поддержка портов ввода-вывода GPIO для аппаратной платформы Raspberry Pi 4 Model B.
• Добавлены сетевые сервисы DHCP, DNS, NTP и примеры работы с ними.
• Добавлена библиотека для работы с протоколом MQTT и примеры ее использования.

О KasperskyOS Community Edition

KasperskyOS Community Edition (CE) — общедоступная версия KasperskyOS, предназначенная для освоения основных принципов разработки приложений под KasperskyOS. KasperskyOS Community Edition позволит вам увидеть, как концепции, заложенные в KasperskyOS, работают на практике. KasperskyOS Community Edition включает в себя примеры приложений с исходным кодом, подробные пояснения, а также инструкции и инструменты для сборки приложений.

KasperskyOS Community Edition пригодится вам для:

• изучения принципов и приемов разработки "secure by design" на практических примерах;
• изучения KasperskyOS как возможной платформы для реализации своих проектов;
• прототипирования решений (прежде всего, Embedded/IoT) на основе KasperskyOS;
• портирования приложений/компонентов/драйверов на KasperskyOS;
• изучения вопросов безопасности в разработке ПО.

Для получения KasperskyOS Community Edition перейдите по ссылке.

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

Об этом документе

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

Руководство предназначено специалистам, обладающим следующими навыками: знание языков C/C++, опыт разработки под POSIX-совместимые системы, знакомство с GNU Binary Utilities (далее также "binutils").

Вы можете применять информацию в этом руководстве для выполнения следующих задач:

• установка и удаление KasperskyOS Community Edition;
• использование KasperskyOS Community Edition.

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

Ниже приведены часто используемые термины, связанные с KasperskyOS Community Edition:

• KasperskyOS – микроядерная операционная система для построения безопасных программно-аппаратных систем.
• Kaspersky Security System – технология, позволяющая создавать декларативное описание политики безопасности решения, а также генерировать на основе этого описания модуль безопасности Kaspersky Security Module.
• Kaspersky Security Module – модуль ядра, дающий разрешение или запрет на каждое IPC-взаимодействие в решении.
• Решение – ядро KasperskyOS, модуль безопасности Kaspersky Security Module, а также прикладное и системное ПО, интегрированные для работы в составе программно-аппаратного комплекса.
• Сущность – запущенная на исполнение программа в KasperskyOS.
• Служба – набор связанных по смыслу методов, доступных через механизм IPC (например, служба ядра для выделения памяти или служба сущности-драйвера для работы с блочным устройством).
• Дескриптор (handle) – идентификатор ресурса (например, участка памяти, порта или сетевого интерфейса). Дескриптор используется для доступа к ресурсу.
• IPC – механизм, использующийся сущностями для взаимодействия друг с другом и с ядром.
• Политика безопасности решения – логика управления IPC-взаимодействиями в решении, реализуемая модулем безопасности Kaspersky Security Module.

Системные требования

Для установки KasperskyOS Community Edition и запуска примеров под QEMU необходимы:

1. Операционная система: Debian GNU/Linux "Buster" версии 10.7 x64.
2. Процессор: процессор с архитектурой x86-64 (для большей производительности требуется поддержка аппаратной виртуализации).
3. Оперативная память: для комфортной работы с инструментами сборки рекомендуется иметь не менее 4 Гб оперативной памяти.
4. Дисковое пространство: не менее 3 ГБ свободного пространства в разделе /opt (в зависимости от разрабатываемого решения);

Для запуска примеров на аппаратной платформе Raspberry Pi, необходимо использовать модель Raspberry Pi 4 Model B с объемом оперативной памяти равным 2, 4, или 8 Гб.

Комплект поставки

В комплект поставки KasperskyOS Community Edition входят:

• deb-пакет для установки KasperskyOS Community Edition, содержащий:
  • образ ядра операционной системы KasperskyOS;
  • компоненты KasperskyOS Community Edition;
  • набор инструментов для разработки решения (компилятор NK, компилятор GCC, отладчик GDB, набор утилит binutils, эмулятор QEMU и сопутствующие инструменты);
  • лицензионное соглашение;
  • файл с информацией о стороннем коде (Legal Notices).
• Информация о версии (Release Notes);
• Руководство разработчика KasperskyOS Community Edition (онлайн-документация).

Следующие компоненты, входящие в комплект поставки KasperskyOS Community Edition, являются "Runtime компонентами" в соответствии с условиями лицензионного соглашения:

• Образ ядра операционной системы KasperskyOS.

Остальные части комплекта поставки не являются "Runtime компонентами". Условия и возможности использования каждого компонента могут быть дополнительно указаны в разделе "Информация о стороннем коде".

Включенные сторонние библиотеки и приложения

Для упрощения процесса разработки приложений в состав KasperskyOS Community Edition также включены следующие сторонние библиотеки и приложения:

• Boost (v.1.71) – собрание библиотек классов, использующих функциональность языка C++ и предоставляющих удобный кроссплатформенный высокоуровневый интерфейс для лаконичного кодирования различных повседневных подзадач программирования (работа с данными, алгоритмами, файлами, потоками и т. п.)

  Документация: https://www.boost.org/doc/

• Arm Mbed TLS (v.2.16) – реализация протоколов TLS и SSL, а также соответствующих криптографических алгоритмов и необходимого кода поддержки.

  Документация: https://tls.mbed.org/kb

• Civetweb (v.1.11) – простой в использовании, мощный, встраиваемый веб-сервер на C / C ++ с дополнительной поддержкой CGI, SSL и Lua.

  Документация: http://civetweb.github.io/civetweb/UserManual.html

• Eclipse Mosquitto (v1.6.4) – брокер сообщений, реализующий протокол MQTT.

  Документация: https://mosquitto.org/documentation/

Также см. Информация о стороннем коде.

Ограничения и известные проблемы

Поскольку KasperskyOS Community Edition предназначен для обучения, мы интегрировали в пакет ряд ограничений:

1. Не поддерживается симметричная многопроцессорность (SMP). Используется только одно ядро процессора.
2. Не поддерживается динамическая загрузка библиотек.
3. Максимальное поддерживаемое количество запущенных приложений (сущностей): 32.
4. При завершении работы сущности любым способом (например, return из основного потока исполнения) выделенные сущностью ресурсы не освобождаются, а сама сущность переводится в "спящее" состояние. Сущности не могут быть запущены повторно.
5. Не поддерживается запуск двух и более сущностей с одинаковым EDL-описанием.
6. Система останавливается, если не осталось работающих сущностей или если один из потоков драйверной сущности завершился (штатным или нештатным образом).

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 запускает все остальные сущности, входящие в решение.

Начало работы

Этот раздел содержит информацию, необходимую для начала работы с KasperskyOS Community Edition.

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

Установка

KasperskyOS Community Edition поставляется в виде deb-пакета. Для установки KasperskyOS Community Edition мы рекомендуем использовать установщик пакетов gdebi.

Для развертывания пакета с помощью gdebi запустите с root-правами команду:

Пакет будет установлен в директорию /opt/KasperskyOS-Community-Edition-<version>.

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

Удаление

Для удаления KasperskyOS Community Edition выполните с root-правами команду:

При этом будут удалены все установленные файлы в директории /opt/KasperskyOS-Community-Edition-<version>.

Настройка среды разработки

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

Настройка редактора кода

Для упрощения процесса разработки решений на базе KasperskyOS перед началом работы рекомендуется:

• Установить в редакторе кода расширения и плагины для используемых языков программирования (C и/или C++).
• Добавить заголовочные файлы, поставляемые в KasperskyOS Community Edition, в проект разработки.

  Заголовочные файлы расположены в следующей директории: /opt/KasperskyOS-Community-Edition-<version>/sysroot-arm-kos/include.

Пример настройки Visual Studio Code

Например, работа с исходным кодом при разработке под KasperskyOS может проводиться в Visual Studio Code.

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

1. Создайте новую рабочую область (workspace) или откройте существующую рабочую область в Visual Studio Code.

   Рабочая область может быть открыта неявно, с помощью пунктов меню File > Open folder.

2. Убедитесь, что расширение C/C++ for Visual Studio Code установлено.
3. В меню View выберите пункт Command Palette.
4. Выберите пункт C/C++: Edit Configurations (UI).
5. В поле Include path добавьте путь /opt/KasperskyOS-Community-Edition-<version>/sysroot-arm-kos/include.
6. Закройте окно C/C++ Configurations.

Сборка и запуск примеров

Сборка примеров

Сборка примеров осуществляется с помощью системы сборки CMake, входящей в состав KasperskyOS Community Edition.

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

/opt/KasperskyOS-Community-Edition-<version>/examples

Сборка примеров для запуска на QEMU

Чтобы выполнить сборку примера, перейдите в директорию с примером и выполните команду:

В результате работы скрипта cross-build.sh создается образ решения на базе KasperskyOS, который включает пример. Файл образа решения kos-qemu-image сохраняется в директории <название примера>/build/einit.

Сборка примеров для запуска на Raspberry Pi 4 B

Чтобы выполнить сборку примера:

1. Перейдите в директорию с примером.
2. Откройте файл скрипта cross-build.sh в текстовом редакторе.
3. В последней строке скрипта замените команду make sim на команду make kos-image.
4. Сохраните файл скрипта, а затем выполните команду:

   $ sudo ./cross-build.sh

В результате работы скрипта cross-build.sh создается образ решения на базе KasperskyOS, который включает пример. Файл образа решения kos-image сохраняется в директории <название примера>/build/einit.

Запуск примеров на QEMU

Запуск примеров на QEMU в Linux с графической оболочкой

Запуск примера на QEMU в Linux с графической оболочкой осуществляется скриптом cross-build.sh, который также выполняет сборку примера. Чтобы запустить скрипт, перейдите в директорию с примером и выполните команду:

Запуск некоторых примеров требует использования дополнительных параметров QEMU. Команды для запуска таких примеров приведены в описаниях этих примеров.

Запуск примеров на QEMU в Linux без графической оболочки

Чтобы запустить пример на QEMU в Linux без графической оболочки, перейдите в директорию с примером, соберите пример и выполните следующие команды:

Запуск примеров на Raspberry Pi 4 B

Коммутация компьютера и Raspberry Pi 4 B

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

1. Соедините пины преобразователя USB-UART на базе FT232 с соответствующими GPIO-пинами Raspberry Pi 4 B (см. рис. ниже).

   

   Схема соединения преобразователя USB-UART и Raspberry Pi 4 B

2. Соедините USB-порт компьютера и преобразователь USB-UART.
3. Установите PuTTY или другую аналогичную программу для чтения данных из COM-порта. Настройте параметры следующим образом: bps = 115200, data bits = 8, stop bits = 1, parity = none, flow control = none.

Чтобы компьютер и Raspberry Pi 4 B могли взаимодействовать через сеть Ethernet, выполните следующие действия:

1. Соедините сетевые карты компьютера и Raspberry Pi 4 B с коммутатором или друг с другом.
2. Выполните настройку сетевой карты компьютера, чтобы ее IP-адрес был в одной подсети с IP-адресом сетевой карты Raspberry Pi 4 B (параметры сетевой карты Raspberry Pi 4 B задаются в файле dhcpcd.conf, который находится по пути <название примера>/resources/...).

Подготовка загрузочной SD-карты для Raspberry Pi 4 B

Загрузочную SD-карту для Raspberry Pi 4 B можно подготовить автоматически и вручную.

Чтобы подготовить загрузочную SD-карту автоматически, подключите SD-карту к компьютеру и выполните следующие команды:

Чтобы подготовить загрузочную SD-карту вручную, выполните следующие действия:

1. Выполните сборку загрузчика U-Boot для платформы ARMv7, который будет автоматически запускать пример. Для этого выполните следующие команды:

   $ sudo apt install gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf git bison flex

   $ git clone https://github.com/u-boot/u-boot.git u-boot-armv7

   $ cd u-boot-armv7 && git checkout tags/v2020.10

   $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rpi_4_32b_defconfig

   # В меню, которое появится при выполнении следующей команды, включите

   # флаг Enable a default value for bootcmd. В поле bootcmd value введите

   # значение fatload mmc 0 ${loadaddr} kos-image; bootelf ${loadaddr}.

   # Затем выйдите из меню, сохранив параметры.

   $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

   $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- u-boot.bin

2. Отформатируйте SD-карту. Для этого подключите SD-карту к компьютеру и выполните следующие команды:

   $ wget https://downloads.raspberrypi.org/raspbian_lite_latest

   $ unzip raspbian_lite_latest

   # В следующей команде [X] – последний символ в имени блочного устройства

   # для SD-карты.

   $ sudo dd bs=4M if=$(ls *raspbian*lite.img) of=/dev/sd[X] conv=fsync

3. Скопируйте загрузчик U-Boot на SD-карту, выполнив следующие команды:

   # В следующих командах путь ~/mnt/fat32 используется для примера. Вы

   # можете использовать другой путь.

   $ mkdir -p ~/mnt/fat32

   # В следующей команде [X] – последний буквенный символ в имени блочного

   # устройства для раздела на отформатированной SD-карте.

   $ sudo mount /dev/sd[X]1 ~/mnt/fat32/

   $ sudo cp u-boot.bin ~/mnt/fat32/u-boot.bin

4. Скопируйте конфигурационный файл для загрузчика U-Boot на SD-карту. Для этого перейдите в директорию /opt/KasperskyOS-Community-Edition-<version>/examples и выполните следующие команды:

   $ sudo cp config.txt ~/mnt/fat32/config.txt

   $ sync

   $ sudo umount ~/mnt/fat32

Запуск примера на Raspberry Pi 4 B

Чтобы запустить пример на Raspberry Pi 4 B, выполните следующие действия:

1. Перейдите в директорию с примером и соберите пример.
2. Скопируйте на загрузочную SD-карту образ решения на базе KasperskyOS. Для этого подключите загрузочную SD-карту к компьютеру и выполните следующие команды:

   # В следующей команде [X] – последний буквенный символ в имени блочного

   # устройства для раздела на загрузочной SD-карте.

   # В следующих командах путь ~/mnt/fat32 используется для примера. Вы

   # можете использовать другой путь.

   $ sudo mount /dev/sd[X]1 ~/mnt/fat32/

   $ sudo cp build/einit/kos-image ~/mnt/fat32/kos-image

   $ sync

   $ sudo umount ~/mnt/fat32

3. Подключите загрузочную SD-карту к Raspberry Pi 4 B.
4. Подайте питание на Raspberry Pi 4 B и дождитесь, пока запустится пример.

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

Часть 1. Простейшее приложение (POSIX)

В состав KasperskyOS Community Edition входит набор библиотек (libc, libm, libpthread), которые обеспечивают частичную совместимость разрабатываемых приложений с набором стандартов POSIX.

В этой части руководства рассматриваются:

• вывод строки на экран с помощью fprintf();
• использование компонента VFS для работы с сетью и файловыми системами;
• создание инициализирующей сущности Einit;
• ограничения поддержки POSIX.

Пример hello

По сложившейся традиции в мире разработки ПО, первое, с чего стоит начать знакомство с любой технологией – это поприветствовать с помощью нее мир. Не будем нарушать эту традицию в KasperskyOS и начнем с примера, выводящего на экран строку Hello world!.

Код hello.c выглядит привычным и простым для разработчика на языке C – он полностью совместим с POSIX:

Чтобы запустить файл Hello в KasperskyOS, понадобится несколько дополнительных действий.

EDL-описание сущности Hello

Статическое описание сущности Hello состоит из единственного файла Hello.edl, в котором необходимо прописать имя сущности:

Во второй части руководства показаны примеры более сложных EDL-описаний, а также появляются CDL- и IDL-описания.

Создание инициализирующей сущности Einit

Для того чтобы сущность Hello запустилась после загрузки операционной системы, достаточно указать ее имя в файле init.yaml и собрать из него сущность Einit.

Схема сборки примера hello

Общая схема сборки примера hello выглядит следующим образом:

Сборка и запуск примера hello

См. "Сборка и запуск примеров".

VFS: работа с файлами и сетью

VFS: обзор

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

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

• одну или несколько файловых систем;
• сетевой стек;
• сетевой стек и сетевой драйвер.

Компонент VFS можно использовать как напрямую (путем статической компоновки), так и через IPC (как отдельную сущность). Использование функциональности VFS по IPC позволяет разработчику решения:

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

Сборка сущности VFS

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

Сборка сетевой VFS

Для сборки "сетевой" сущности VFS, содержащей сетевой драйвер, необходимо файл с функцией main() скомпоновать с библиотеками vfs_server, vfs_net и dnet_implementation:

Использование "сетевой" сущности VFS, скомпонованной с сетевым драйвером

Чтобы использовать сетевой драйвер по IPC (как отдельную сущность), необходимо вместо dnet_implementation использовать библиотеку dnet_client:

Использование "сетевой" сущности VFS и сетевого драйвера в виде отдельной сущности

Сборка файловой VFS

Для сборки "файловой" сущности VFS необходимо файл с функцией main() скомпоновать с библиотеками vfs_server и vfs_fs, а также библиотеками реализации файловых систем:

В этом примере сущность VFS подготовлена для соединения с сущностью ramdisk-драйвера.

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

Использование "файловой" сущности VFS и драйвера в виде отдельной сущности

Сущность Env

Служебная сущность Env предназначена для передачи запускаемым сущностям аргументов и переменных окружения. При запуске каждая сущность автоматически отправляет запрос сущности Env и получает необходимые данные.

Включение сущности Env в решение позволяет монтировать файловые системы при запуске VFS, соединять одну клиентскую сущность с двумя сущностями VFS и решать многие другие задачи.

Чтобы использовать сущность Env в своем решении, необходимо:

1. Разработать код сущности Env, используя макросы из env/env.h.

2. Собрать образ сущности, скомпоновав ее с библиотекой env_server.

3. В init-описании указать, что необходимо запустить сущность Env и соединить с ней выбранные сущности (Env при этом является сервером). Имя канала задается макросом ENV_SERVICE_NAME, объявленным в файле env/env.h.

4. Включить образ сущности Env в образ решения.

Код сущности Env

В коде сущности Env используются следующие макросы и функции, объявленные в файле env/env.h:

• ENV_REGISTER_ARGS(name,argarr) – сущности с именем name будут переданы аргументы из массива argarr;
• ENV_REGISTER_VARS(name,envarr) – сущности с именем name будут переданы переменные окружения из массива envarr;
• ENV_REGISTER_PROGRAM_ENVIRONMENT(name,argarr,envarr) – сущности с именем name будут переданы как аргументы, так и переменные окружения;
• envServerRun() – инициализировать серверную часть сущности, чтобы она могла отвечать на запросы.

Пример:

Пример init.yaml для использования сущности Env

В следующем примере сущность Client будет соединена с сущностью Env, образ которой находится в папке env:

Соединение сущности-клиента с одной и двумя сущностями VFS

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

Соединение с одной сущностью VFS

Имя IPC-канала между сущностью-клиентом и сущностью VFS должно задаваться макросом _VFS_CONNECTION_ID, объявленным в файле vfs/defs.h. При этом как "сетевые", так и "файловые" вызовы будут направляться в эту сущность VFS.

Пример:

Соединение с двумя сущностями VFS

Пусть сущность-клиент соединена с двумя разными сущностями VFS – назовем их "сетевая" VFS и "файловая" VFS.

Чтобы "сетевые" вызовы из сущности-клиента направлялись только в "сетевую" VFS, используется переменная окружения _VFS_NETWORK_BACKEND:

• Для "сетевой" сущности VFS: _VFS_NETWORK_BACKEND=server:<имя IPC-канала до "сетевой" VFS>
• Для сущности-клиента: _VFS_NETWORK_BACKEND=client: <имя IPC-канала до "сетевой" VFS>

Для направления "файловых" вызовов используется аналогичная переменная окружения _VFS_FILESYSTEM_BACKEND:

• Для "файловой" сущности VFS: _VFS_FILESYSTEM_BACKEND=server:<имя IPC-канала до "файловой" VFS>
• Для сущности-клиента: _VFS_FILESYSTEM_BACKEND=client: <имя IPC-канала до "файловой" VFS>

В результате функции для работы с сетью и файлами будут направляться в две разные сущности VFS.

В следующем примере сущность Client соединена с двумя сущностями VFS – "сетевой" VfsFirst и "файловой" VfsSecond:

Код сущности Env:

Монтирование файловых систем при запуске VFS

Компонент VFS по умолчанию обеспечивает доступ к:

• Файловой системе RAMFS. По умолчанию RAMFS монтирована в корневой каталог.
• Объектному ROMFS-хранилищу. Хранилище содержит неисполняемые (в т.ч. конфигурационные) файлы, добавленные при сборке в образ решения. По умолчанию файловая система ROMFS не монтирована, но доступ к хранилищу возможен косвенным образом – например, через аргумент -f.

Если требуется монтировать другие файловые системы, это можно сделать как после запуска VFS, используя вызов mount(), так и непосредственно в момент запуска сущности VFS, передав ей следующие аргументы и переменные окружения:

• -l <запись в формате fstab>

  Аргумент -l позволяет монтировать файловую систему.

• -f <путь к файлу fstab>

  Аргумент -f позволяет передать файл с записями в формате fstab для монтирования файловых систем. Файл будет искаться в ROMFS-хранилище. Если переменная UMNAP_ROMFS определена, то файл будет искаться на файловой системе, смонтированной с помощью переменной ROOTFS.

• UNMAP_ROMFS

  Если переменная UNMAP_ROMFS определена, то ROMFS-хранилище будет удалено. Это позволяет сэкономить память и изменить поведение при использовании аргумента -f.

• ROOTFS = <запись в формате fstab>

  Переменная ROOTFS позволяет монтировать файловую систему в корневой каталог. В комбинации с переменной UNMAP_ROMFS и аргументом -f позволяет искать fstab-файл на монтированной файловой системе, а не в ROMFS-хранилище.

Пример:

Ограничения поддержки POSIX

В KasperskyOS ограниченно реализован интерфейс POSIX с ориентацией на стандарт POSIX.1-2008 (без поддержки XSI). Прежде всего ограничения связаны с обеспечением безопасности.

Ограничения затрагивают:

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

Ограничения представлены:

• нереализованными интерфейсами;
• интерфейсами, которые реализованы с отклонениями от стандарта POSIX.1-2008;
• интерфейсами-заглушками, которые не выполняют никаких действий, кроме присвоения переменной errno значения ENOSYS и возвращения значения -1.

Ограничения взаимодействия между процессами

Ограничения взаимодействия между потоками выполнения посредством сигналов

Ограничения стандартного ввода-вывода

Ограничения асинхронного ввода-вывода

Ограничения использования робастных мьютексов

Ограничения работы с терминалом

Ограничения работы с оболочкой

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

Часть 2. Взаимодействие сущностей

В предыдущей части руководства показано, как построить взаимодействие с сущностями, поставляемыми в составе KasperskyOS Community Edition. Для этого достаточно добавить несколько строк в файл init.yaml и подключить клиентскую библиотеку сущности (vfs_remote).

Но как самостоятельно создать серверную сущность (то есть приложение, предоставляющее функциональность другим, клиентским, сущностям)? Для этого потребуется использовать IPC-транспорт, вспомогательные утилиты и библиотеки, поставляемые в составе KasperskyOS Community Edition.

В этой части руководства рассматриваются:

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

Инструменты IPC-транспорта

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

Для решения этих и других проблем организации IPC-транспорта в KasperskyOS есть специальный набор инструментов:

• Транспорт NkKosTransport
• EDL-, CDL- и IDL-описания
• Компилятор NK
• Init-описание и утилита einit
• Локатор сервисов (Service Locator)

Транспорт NkKosTransport

Транспорт NkKosTransport является удобной надстройкой над системными вызовами Call, Recv и Reply. Он позволяет работать отдельно с фиксированной частью и ареной сообщений.

Для вызова транспорта используются функции nk_transport_call(), nk_transport_recv() и nk_transport_reply().

Пример:

Структура NkKosTransport и методы работы с ней объявлены в файле transport-kos.h:

Подробнее о фиксированной части и арене см. "Структура IPC-сообщения".

Подробнее об использовании NkKosTransport см. "Транспорт NkKosTransport".

EDL-, CDL- и IDL-описания

Для описания интерфейсов, которые реализуют серверные сущности, используются языки EDL, CDL и IDL.

Подробнее см. "Описание сущностей, компонентов и интерфейсов (EDL, CDL, IDL)".

Файлы описаний (*.edl, *.cdl и *.idl) при сборке обрабатываются компилятором NK. В результате создаются файлы *.edl.h, *.cdl.h, и *.idl.h, содержащие транспортные методы и типы, используемые как на клиенте, так и на сервере.

Компилятор NK

На основе EDL-, CDL- и IDL-описаний компилятор NK (nk-gen-c) генерирует набор транспортных методов и типов. Транспортные методы и типы нужны для формирования, отправки, приема и обработки IPC-сообщений

Важнейшие транспортные методы:

• Интерфейсные методы. При вызове на клиенте интерфейсного метода серверу отправляется IPC-запрос для вызова соответствующего метода.
• Dispatch-методы (диспетчеры). При получении запроса сервер вызывает диспетчер, который в свою очередь вызывает реализацию соответствующего метода.

Важнейшие транспортные типы:

• Типы, определяющие структуру фиксированной части сообщения. Передаются в интерфейсные методы, диспетчеры и функции транспорта (nk_transport_recv(), nk_transport_reply()).
• Типы прокси-объектов. Прокси-объект используется как аргумент интерфейсного метода.

Подробнее см. "Сгенерированные методы и типы".

Init-описание и утилита einit

Утилита einit позволяет автоматизировать создание кода инициализирующей сущности Einit. Эта сущность первой запускается при загрузке KasperskyOS и запускает остальные сущности, а также создает каналы (соединения) между ними.

Чтобы сущность Einit при запуске создала соединение между сущностями A и B, в файле init.yaml нужно указать:

Подробнее см. "Запуск сущностей".

Локатор сервисов (Service Locator)

Локатор сервисов – библиотека, содержащая следующие функции:

• ServiceLocatorConnect() – позволяет узнать клиентский IPC-дескриптор канала с указанным именем.
• ServiceLocatorRegister() – позволяет узнать серверный IPC-дескриптор канала с указанным именем.
• ServiceLocatorGetRiid() – позволяет узнать RIID (порядковый номер реализации интерфейса) по имени реализации интерфейса.

Значения IPC-дескриптора и RIID используются при инициализации транспорта NkKosTransport.

Чтобы использовать локатор сервисов, нужно в коде сущности подключить файл sl_api.h:

Подробнее см. "Локатор сервисов (Service Locator)".

Пример echo

Пример echo демонстрирует использование IPC-транспорта.

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

О примере echo

Пример echo описывает простейший случай взаимодействия двух сущностей:

1. Сущность Client передает сущности Server число (value).
2. Сущность Server изменяет это число и передает новое число (result) сущности Client.
3. Сущность Client выводит число result на экран.

   

Чтобы организовать такое взаимодействие сущностей, потребуется:

1. Соединить сущности Client и Server, используя init-описание.
2. Реализовать на сервере интерфейс с единственным методом Ping, который имеет один входной аргумент – исходное число (value) и один выходной аргумент – измененное число (result).

   Описание метода Ping на языке IDL:

   Ping(in UInt32 value, out UInt32 result);

   

3. Создать файлы статических описаний на языках EDL, CDL и IDL. С помощью компилятора NK сгенерировать файлы, содержащие транспортные методы и типы (прокси-объект, диспетчеры и т.д.).
4. В коде сущности Client инициализировать все необходимые объекты (транспорт, прокси-объект, структуру запроса и др.) и вызвать интерфейсный метод.
5. В коде сущности Server подготовить все необходимые объекты (транспорт, диспетчер компонента и диспетчер сущности и др.), принять запрос от клиента, обработать его и отправить ответ.

Пример echo состоит из следующих исходных файлов:

• client/src/client.c – реализация сущности Client;
• server/src/server.c – реализация сущности Server;
• resources/Server.edl, resources/Client.edl, resources/Ping.cdl, resources/Ping.idl – статические описания;
• init.yaml – init-описание.

Реализация сущности Client в примере echo

В коде сущности Client используются транспортные типы и методы, которые будут сгенерированы во время сборки решения компилятором NK на основе IDL-описания интерфейса Ping.

Однако чтобы получить необходимые для реализации сущности описания типов и сигнатуры методов, вы можете воспользоваться компилятором NK непосредственно после создания EDL-описания сущности, CDL-описаний компонентов и IDL-описаний используемых интерфейсов взаимодействия. В результате необходимые типы и сигнатуры методов будут объявлены в сгенерированных файлах *.h.

В реализации сущности Client необходимо:

1. Получить клиентский IPC-дескриптор соединения (канала), используя функцию локатора сервисов ServiceLocatorConnect().

   На вход нужно передать имя IPC-соединения server_connection, заданное ранее в файле init.yaml.

2. Инициализировать транспорт NkKosTransport, передав полученный IPC-дескриптор в функцию NkKosTransport_Init().
3. Получить идентификатор необходимого интерфейса (RIID), используя функцию локатора сервисов ServiceLocatorGetRiid().
4. На вход нужно передать полное имя реализации интерфейса Ping. Оно состоит из имен экземпляра компонента (Echo.ping) и интерфейса (ping), заданных ранее в Server.edl и Ping.cdl.
5. Инициализировать прокси-объект, передав транспорт и идентификатор интерфейса в функцию Ping_proxy_init().
6. Подготовить структуры запроса и ответа.
7. Вызвать интерфейсный метод Ping_Ping(), передав прокси-объект, а также указатели на запрос и ответ.

Реализация сущности Server в примере echo

В коде сущности Server используются транспортные типы и методы, которые будут сгенерированы во время сборки решения компилятором NK на основе EDL-описания сущности Server.

Однако чтобы получить необходимые для реализации сущности типы и сигнатуры методов, вы можете воспользоваться компилятором NK непосредственно после создания EDL-описания сущности, CDL-описаний компонентов и IDL-описаний используемых интерфейсов взаимодействия. В результате необходимые типы и сигнатуры методов будут объявлены в сгенерированных файлах *.h.

В реализации сущности server необходимо:

1. Реализовать метод Ping().

   Сигнатура реализации метода Ping() должна в точности совпадать с сигнатурой интерфейсного метода Ping_Ping(), который объявлен в файле Ping.idl.h.

2. Получить серверный IPC-дескриптор соединения (канала), используя функцию локатора сервисов ServiceLocatorRegister().

   На вход нужно передать имя IPC-соединения server_connection, заданное ранее в файле init.yaml.

3. Инициализировать транспорт NkKosTransport, передав полученный IPC-дескриптор в функцию NkKosTransport_Init().
4. Подготовить структуры запроса и ответа.
5. Инициализировать dispatch-метод (диспетчер) компонента Ping, используя функцию Ping_component_init().
6. Инициализировать dispatch-метод (диспетчер) сущности Server, используя функцию Server_entity_init().
7. Получить запрос, вызвав nk_transport_recv().
8. Обработать полученный запрос, вызвав диспетчер Server_entity_dispatch().

   Диспетчер вызовет необходимую реализацию метода на основе полученного от клиента идентификатора интерфейса (RIID).

9. Отправить ответ сущности Client, вызвав nk_transport_reply().

Файлы описаний в примере echo

Описание сущности Client

Сущность Client не реализует ни одного интерфейса, поэтому в ее EDL-описании достаточно объявить имя сущности:

Описание сущности Server

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

Сущность Server содержит экземпляр компонента Ping:

Компонент Ping содержит реализацию интерфейса Ping:

Пакет Ping содержит объявление интерфейса Ping:

Init-описание

Чтобы сущность Client могла вызвать метод сущности Server, между ними требуется создать соединение (IPC-канал).

Для этого в init-описании укажите, что необходимо запустить сущности Client и Server, а также соединить их:

Поскольку сущность Server указана как - target, она будет выступать в роли серверной сущности, т.е. принимать запросы сущности Client и отвечать на них.

Сборка и запуск примера echo

См. "Сборка и запуск примеров".

Схема сборки примера echo выглядит следующим образом:

Часть 3. Политика безопасности решения

В предыдущих частях руководства показано, как реализовать взаимодействие между сущностями. При этом для простоты все решения собирались без модуля безопасности (ksm.module), которым представлена подсистема Kaspersky Security System.

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

В этой части руководства рассматриваются:;

• синтаксис языка PSL;
• модели безопасности, поддерживаемые в Kaspersky Security System;
• пример политики безопасности решения.

Общие сведения об описании политики безопасности решения

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

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

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

События безопасности – это сигналы об инициации взаимодействий сущностей между собой и с ядром KasperskyOS. К событиям безопасности относятся следующие события:

• отправка IPC-запросов клиентами;
• отправка IPC-ответов серверами или ядром;
• инициация запусков сущностей ядром или сущностями;
• запуск ядра;
• обращения сущностей к модулю безопасности Kaspersky Security Module через интерфейс безопасности.

События безопасности обрабатываются модулем безопасности.

Модели безопасности

В составе KasperskyOS SDK поставляются PSL-файлы, которые описывают следующие модели безопасности:

• Base – методы, реализующие простейшую логику;
• Pred – методы, реализующие операции сравнения;
• Bool – методы, реализующие логические операции;
• Math – методы, реализующие операции целочисленной арифметики;
• Struct – методы, обеспечивающие доступ к структурным элементам данных (например, доступ к параметрам интерфейсных методов, передаваемых в IPC-сообщениях);
• Regex – методы для валидации текстовых данных по регулярным выражениям;
• HashSet – методы для работы с одномерными таблицами, ассоциированными с ресурсами;
• StaticMap – методы для работы с двумерными таблицами типа "ключ–значение", ассоциированными с ресурсами;
• Flow – методы для работы с конечными автоматами, ассоциированными с ресурсами.

Обработка событий безопасности модулем безопасности Kaspersky Security Module

Модуль безопасности Kaspersky Security Module вызывает все методы (правила и выражения) моделей безопасности, связанные с произошедшим событием безопасности. Если все правила вернули результат "разрешено", модуль безопасности возвращает решение "разрешено". Если хотя бы одно правило вернуло результат "запрещено", модуль безопасности возвращает решение "запрещено".

Если хотя бы один метод, связанный с произошедшим событием безопасности, не может быть корректно выполнен, модуль безопасности возвращает решение "запрещено".

Если с произошедшим событием безопасности не связано ни одно правило, модуль безопасности возвращает решение "запрещено". То есть все взаимодействия компонентов решения между собой и с ядром KasperskyOS, которые явно не разрешены политикой безопасности решения, запрещены (принцип Default Deny).

Аудит безопасности

Аудит безопасности (далее также аудит) представляет собой следующую последовательность действий. Модуль безопасности Kaspersky Security Module сообщает ядру KasperskyOS сведения о решениях, принятых этим модулем. Затем ядро передает эти данные системной программе Klog, которая декодирует их и передает системной программе KlogStorage (передача данных осуществляется через IPC). Последняя выводит полученные данные через стандартный вывод или сохраняет в файл.

Данные аудита безопасности (далее данные аудита) – это сведения о решениях модуля безопасности Kaspersky Security Module, которые включают сами решения ("разрешено" или "запрещено"), описания событий безопасности, результаты вызовов методов моделей безопасности, а также данные о некорректности IPC-сообщений.

Синтаксис языка PSL

Базовые правила

1. Декларации могут располагаться в файле в любом порядке.
2. Одна декларация может быть записана в одну или несколько строк. Вторая и последующие строки декларации должны быть записаны с отступами относительно первой строки. Закрывающая фигурная скобка, которая завершает декларацию, может быть записана на уровне первой строки.
3. В многострочной декларации используются отступы разных размеров, чтобы отразить вложенность конструкций, составляющих эту декларацию. Строки многострочной конструкции, заключенные в фигурные скобки, и открывающая фигурная скобка должны быть записаны с отступом относительно первой строки этой конструкции. Закрывающая фигурная скобка многострочной конструкции может быть записана с отступом или на уровне первой строки конструкции.
4. Поддерживаются однострочные и многострочные комментарии:

   /* Это комментарий

   И это тоже */

   // Ещё один комментарий

Типы деклараций

В языке PSL есть следующие типы деклараций:

• описание глобальных параметров политики безопасности решения;
• включение PSL-файлов;
• включение EDL-файлов;
• создание объектов моделей безопасности;
• привязка методов моделей безопасности к событиям безопасности;
• описание профилей аудита безопасности.

Описание глобальных параметров политики безопасности решения

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

• Execute-интерфейс, через который ядро KasperskyOS обращается к модулю безопасности Kaspersky Security Module, чтобы сообщить о запуске ядра или об инициации запуска сущностей ядром или другими сущностями. Чтобы задать этот интерфейс, нужно использовать декларацию:

  execute: kl.core.Execute

  В настоящее время в KasperskyOS поддерживается только один execute-интерфейс Execute, определенный в файле kl/core/Execute.idl. (Этот интерфейс состоит из одного метода main, который не имеет параметров и не выполняет никаких действий. Метод main зарезервирован для возможного использования в будущем.)

• [Опционально] Глобальный профиль аудита безопасности и начальный уровень аудита безопасности. Чтобы задать эти параметры, нужно использовать декларацию:

  audit default = <имя профиля аудита безопасности> <уровень аудита безопасности>

  Пример:

  audit default = global 0

  По умолчанию в качестве глобального используется пустой профиль аудита безопасности empty, описанный в файле toolchain/include/nk/base.psl из состава KasperskyOS SDK, и уровень аудита безопасности 0.

Включение PSL-файлов

Для включения PSL-файла нужно использовать декларацию:

Ссылка на PSL-файл представляет собой путь к PSL-файлу (без расширения и точки перед ним) относительно директории, которая включена в набор директорий, где компилятор nk-psl-gen-c ищет PSL-, IDL-, CDL-, EDL-файлы. (Этот набор директорий задается параметрами скрипта makekss вида "-I <путь к файлам>".) В качестве разделителя в описании пути используется точка. Декларация завершается последовательностью символов ._.

Пример:

Эта декларация включает файл flow_part.psl, который находится в директории policy_parts. Директория policy_parts должна находиться в одной из директорий, где компилятор nk-psl-gen-c выполняет поиск PSL-, IDL-, CDL-, EDL-файлов. Например, директория policy_parts может располагаться в одной директории с PSL-файлом, содержащим эту декларацию.

Включение PSL-файла с формальным представлением модели безопасности

Чтобы использовать методы требуемой модели безопасности, нужно включить PSL-файл с формальным представлением этой модели. PSL-файлы с формальными представлениями моделей безопасности находятся в <KOS_KASPERSKY> SDK по пути:

toolchain/include/nk

Пример:

Включение EDL-файлов

Чтобы включить EDL-файл для ядра KasperskyOS, нужно использовать декларацию:

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

Ссылка на EDL-файл представляет собой путь к EDL-файлу (без расширения и точки перед ним) относительно директории, которая включена в набор директорий, где компилятор nk-psl-gen-c ищет PSL-, IDL-, CDL-, EDL-файлы. (Этот набор директорий задается параметрами скрипта makekss вида "-I <путь к файлам>".) В качестве разделителя в описании пути используется точка.

Пример:

Компилятор nk-psl-gen-c находит IDL-, CDL-файлы через EDL-файлы, так как EDL-файлы содержат ссылки на соответствующие CDL-файлы, а CDL-файлы содержат ссылки на соответствующие CDL-, IDL-файлы.

Создание объектов моделей безопасности

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

Чтобы создать объект модели безопасности, нужно использовать декларацию:

Параметры объекта модели безопасности специфичны для модели безопасности. Описание параметров и примеры создания объектов разных моделей безопасности приведены в разделе "Модели безопасности".

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

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

Вид события безопасности

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

• request – отправка IPC-запросов;
• response – отправка IPC-ответов;
• error – отправка IPC-ответов, содержащих сведения об ошибках;
• security – попытки обращений сущностей к модулю безопасности Kaspersky Security Module через интерфейс безопасности;
• execute – инициация запусков сущностей или запуск ядра KasperskyOS.

Селекторы события безопасности

Селекторы события безопасности позволяют уточнить описание события безопасности заданного вида. Используются следующие селекторы:

• src=<имя класса сущностей/ядро> – сущности заданного класса или ядро KasperskyOS являются источниками IPC-сообщений;
• dst=<имя класса сущностей/ядро> – сущности заданного класса или ядро являются приемниками IPC-сообщений;
• interface=<имя интерфейса> – описывает следующие события безопасности:
  • клиенты пытаются обратиться к серверам или ядру через интерфейс с заданным именем;
  • сущности обращаются к модулю безопасности Kaspersky Security Module через интерфейс безопасности с заданным именем;
  • серверы или ядро отправляют клиентам результаты обработки обращений через интерфейс с заданным именем;
• endpoint=<квалифицированное имя службы> – описывает следующие события безопасности:
  • клиенты пытаются использовать службу серверов или ядра с заданным именем;
  • серверы или ядро отправляют клиентам результаты использования службы с заданным именем;
• method=<имя метода> – описывает следующие события безопасности:
  • клиенты пытаются обратиться к серверам или ядру, вызывая метод службы с заданным именем;
  • сущности обращаются к модулю безопасности, вызывая метод интерфейса безопасности с заданным именем;
  • серверы или ядро отправляют клиентам результаты вызова метода службы с заданным именем;
  • ядро сообщает о своем запуске модулю безопасности, вызывая метод execute-интерфейса с заданным именем;
  • ядро инициирует запуски сущностей, вызывая метод execute-интерфейса с заданным именем;
  • сущности инициируют запуски других сущностей, в результате чего ядро вызывает метод execute-интерфейса с заданным именем.

Классы сущностей, интерфейсы, службы, методы должны называться так, как они называются в IDL-, CDL-, EDL-описаниях. Ядро должно называться kl.core.Core.

Если селекторы не указаны, участниками события безопасности считаются все сущности и ядро (кроме событий вида security, где ядро не участвует).

Можно использовать комбинации селекторов. При этом селекторы можно разделять запятыми.

На использование селекторов есть ограничения. Для событий безопасности вида execute нельзя использовать селекторы interface и endpoint. Для событий безопасности вида security нельзя использовать селекторы dst и endpoint.

Также есть ограничения на комбинации селекторов. Для событий безопасности видов request, response и error селектор method можно использовать только совместно с одним или обоими селекторами endpoint и interface. (Селекторы method, endpoint и interface должны быть согласованы, то есть метод должен соответствовать службе или интерфейсу, служба должна соответствовать интерфейсу.) Для событий безопасности вида request селектор endpoint можно использовать только совместно с селектором dst. Для событий безопасности видов response и error селектор endpoint можно использовать только совместно с селектором src.

Профиль аудита безопасности

Профиль аудита безопасности задается конструкцией audit <имя профиля аудита безопасности>. Если профиль аудита безопасности не задан, используется глобальный профиль аудита безопасности.

Вызываемые правила моделей безопасности

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

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

Также в качестве входных данных для методов моделей безопасности (правил и выражений) могут использоваться параметры интерфейсных методов. (О получении доступа к параметрам интерфейсных методов см. "Модель безопасности Struct"). Кроме этого, входными данными для методов моделей безопасности могут быть значения SID сущностей и ядра KasperskyOS, которые задаются ключевыми словами src_sid и dst_sid. Первое означает SID сущности (или ядра), которая является источником IPC-сообщения. Второе означает SID сущности (или ядра), которая является приемником IPC-сообщения (при обращениях к модулю безопасности Kaspersky Security Module dst_sid использовать нельзя).

Вложенные конструкции для привязки методов моделей безопасности к событиям безопасности

В одной декларации можно выполнить привязку методов моделей безопасности к разным события безопасности одного вида. Для этого нужно использовать match-секции, которые представляют собой конструкции вида:

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

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

Конструкцию choice можно использовать внутри match-секции. Условная секция использует селекторы события безопасности и профиль аудита безопасности своего контейнера, но можно задать отдельный профиль аудита безопасности для условной секции.

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

Описание профилей аудита безопасности

Для выполнения аудита безопасности нужно ассоциировать объекты моделей безопасности с профилем (профилями) аудита безопасности. Профиль аудита безопасности (далее также профиль аудита) объединяет в себе конфигурации аудита безопасности (далее также конфигурации аудита), каждая из которых задает объекты моделей безопасности, покрываемые аудитом, а также условия выполнения аудита. Можно задать глобальный профиль аудита (подробнее см. "Описание глобальных параметров политики безопасности решения") и/или назначить профиль (профили) аудита на уровне деклараций привязки методов моделей безопасности к событиям безопасности, и/или назначить профиль (профили) аудита на уровне match-секций или choice-секций (подробнее см. "Привязка методов моделей безопасности к событиям безопасности").

Чтобы описать профиль аудита безопасности, нужно использовать декларацию:

Уровень аудита безопасности

Уровень аудита безопасности (далее уровень аудита) является глобальным параметром политики безопасности решения и представляет собой беззнаковое целое число, которое задает активную конфигурацию аудита безопасности. (Слово "уровень" здесь означает вариант конфигурации и не предполагает обязательной иерархии.) Уровень аудита можно изменять в процессе работы модуля безопасности Kaspersky Security Module. Для этого используется специальный метод модели безопасности Base, вызываемый при обращении сущностей к модулю безопасности через интерфейс безопасности (подробнее см. "Модель безопасности Base"). Начальный уровень аудита задается совместно с назначением глобального профиля аудита (подробнее см. "Описание глобальных параметров политики безопасности решения"). В качестве глобального можно явно назначить пустой профиль аудита empty.

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

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

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

Имя объекта модели безопасности

Имя объекта модели безопасности указывается, чтобы методы, которые предоставляются этим объектом, могли быть покрыты аудитом. Эти методы будут покрыты аудитом при их вызовах, если условия выполнения аудита будут соблюдены.

Условия выполнения аудита безопасности

Условия выполнения аудита безопасности задаются отдельно для каждого объекта модели безопасности.

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

• ["granted"] – аудит выполняется, если вызванное правило вернуло результат "разрешено";
• ["denied"] – аудит выполняется, если вызванное правило вернуло результат "запрещено";
• ["granted", "denied"] – аудит выполняется, если вызванное правило вернуло результат "разрешено" или "запрещено";
• [] – аудит не выполняется независимо от того, какой результат вернуло вызванное правило.

Условия выполнения аудита, связанные с результатами вызовов правил, не применяются к выражениям. Эти условия должны быть заданы (любой возможной конструкцией), даже если модель безопасности содержит только выражения, поскольку этого требует синтаксис языка PSL.

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

Профиль аудита безопасности для тракта аудита безопасности

Тракт аудита безопасности включает ядро, а также сущности Klog и KlogStorage, которые соединены IPC-каналами по схеме "ядро – Klog – KlogStorage". Методы моделей безопасности, которые связаны с передачей данных аудита через этот тракт, не должны покрываться аудитом. В противном случае это приведет к лавинообразному росту данных аудита, так как передача данных будет порождать новые данные.

Чтобы "подавить" аудит, заданный профилем более широкой области действия (например, глобальным или профилем на уровне декларации привязки методов моделей безопасности к события безопасности), нужно назначить пустой профиль аудита empty на уровне декларации привязки методов моделей безопасности к событиям безопасности или на уровне match-секции либо choice-секции.

Типы данных в языке PSL

Типы данных, поддерживаемые в языке PSL, приведены в таблице ниже.

Типы данных в языке PSL

Псевдонимы некоторых типов PSL

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

Псевдонимы и определения некоторых типов данных в языке PSL

Отображение типов IDL на типы PSL

Для описания параметров интерфейсных методов используются типы данных языка IDL. Входные данные для методов моделей безопасности имеют типы из языка PSL. Набор типов данных в языке IDL отличается от набора типов данных в языке PSL. Поскольку параметры интерфейсных методов, передаваемые в IPC-сообщениях, могут использоваться как входные данные для методов моделей безопасности, автору политики безопасности решения нужно понимать, как типы IDL отображаются на типы PSL.

Целочисленные типы IDL отображаются на целочисленные типы PSL, а также на вариантные типы PSL, объединяющие эти целочисленные типы (в том числе с другими типами). Например, знаковые целочисленные типы IDL отображаются на тип Signed в PSL, целочисленные типы IDL отображаются на тип ScalarLiteral в PSL.

Тип Handle в IDL отображается на тип HandleDesc в PSL.

Объединения и структуры IDL отображаются на словари PSL.

Массивы и последовательности IDL отображаются на массивы и последовательности PSL соответственно.

Строковые буферы в IDL отображаются на текстовый тип PSL.

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

Пример простейшей политики безопасности решения

Ниже приведена простейшая политика безопасности решения вида "все разрешено" для решения, состоящего из пользовательских сущностей Client и Server, а также сущности Einit и ядра KasperskyOS, представленного сущностью kl.core.Core.

Эта политика разрешает:

• все взаимодействия сущностей (отправку любых запросов и ответов);
• запуск всех сущностей;

Модели безопасности

Модель безопасности Pred

Модель безопасности Pred позволяет выполнять операции сравнения.

PSL-файл с описанием модели безопасности Pred находится в KasperskyOS SDK по пути:

toolchain/include/nk/basic.psl

Объект модели безопасности Pred

В файле basic.psl содержится декларация, которая создает объект модели безопасности Pred с именем pred. Соответственно, включение файла basic.psl в описание политики безопасности решения обеспечивает создание объекта модели безопасности Pred по умолчанию.

Объект модели безопасности Pred не имеет параметров и не может быть покрыт аудитом безопасности.

Создавать дополнительные объекты модели безопасности Pred не требуется.

Методы модели безопасности Pred

Модель безопасности Pred содержит выражения, которые выполняют операции сравнения и возвращают значения типа Boolean. Для вызова этих выражений нужно использовать операторы сравнения:

• <ScalarLiteral> == <ScalarLiteral> – "равно";
• <ScalarLiteral> != <ScalarLiteral> – "не равно";
• <Number> < <Number> – "меньше";
• <Number> <= <Number> – "меньше или равно";
• <Number> > <Number> – "больше";
• <Number> >= <Number> – "больше или равно".

Также модель безопасности Pred содержит выражение empty, которое позволяет определить, содержат ли данные свои структурные элементы. Выражение возвращает значения типа Boolean. Если данные не содержат своих структурных элементов (например, множество является пустым), выражение возвращает true, иначе возвращает false. Чтобы вызвать выражение, нужно использовать конструкцию:

Модель безопасности Bool

Модель безопасности Bool позволяет выполнять логические операции.

PSL-файл с описанием модели безопасности Bool находится в KasperskyOS SDK по пути:

toolchain/include/nk/basic.psl

Объект модели безопасности Bool

В файле basic.psl содержится декларация, которая создает объект модели безопасности Bool с именем bool. Соответственно, включение файла basic.psl в описание политики безопасности решения обеспечивает создание объекта модели безопасности Bool по умолчанию.

Объект модели безопасности Bool не имеет параметров и не может быть покрыт аудитом безопасности.

Создавать дополнительные объекты модели безопасности Bool не требуется.

Методы модели безопасности Bool

Модель безопасности Bool содержит выражения, которые выполняют логические операции и возвращают значения типа Boolean. Для вызова этих выражений нужно использовать логические операторы:

• ! <Boolean> – "логическое НЕ";
• <Boolean> && <Boolean> – "логическое И";
• <Boolean> || <Boolean> – "логическое ИЛИ";
• <Boolean> ==> <Boolean> – "импликация" (! <Boolean> || <Boolean>).

Также модель безопасности Bool содержит выражения all, any и cond.

Выражение all выполняет "логическое И" для произвольного числа значений типа Boolean. Возвращает значения типа Boolean. Если передать через параметр пустой список значений ([]), возвращает true. Чтобы вызвать выражение, нужно использовать конструкцию:

Выражение any выполняет "логическое ИЛИ" для произвольного числа значений типа Boolean. Возвращает значения типа Boolean. Если передать через параметр пустой список значений ([]), возвращает false. Чтобы вызвать выражение, нужно использовать конструкцию:

Выражение cond выполняет тернарную условную операцию. Возвращает значения типа ScalarLiteral. Чтобы вызвать выражение, нужно использовать конструкцию:

Помимо выражений модель безопасности Bool включает правило assert, которое работает так же, как одноименное правило модели безопасности Base.

Модель безопасности Math

Модель безопасности Math позволяет выполнять операции целочисленной арифметики.

PSL-файл с описанием модели безопасности Math находится в KasperskyOS SDK по пути:

toolchain/include/nk/basic.psl

Объект модели безопасности Math

В файле basic.psl содержится декларация, которая создает объект модели безопасности Math с именем math. Соответственно, включение файла basic.psl в описание политики безопасности решения обеспечивает создание объекта модели безопасности Math по умолчанию.

Объект модели безопасности Math не имеет параметров и не может быть покрыт аудитом безопасности.

Создавать дополнительные объекты модели безопасности Math не требуется.

Методы модели безопасности Math

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

• <Number> + <Number> – "сложение". Возвращает значения типа Number.
• <Number> - <Number> – "вычитание". Возвращает значения типа Number.
• <Number> * <Number> – "умножение". Возвращает значения типа Number.

Другая часть включает следующие выражения:

• neg <Signed> – "изменение знака числа". Возвращает значения типа Singed.
• abs <Singed> – "получение модуля числа". Возвращает значения типа Singed.
• sum <List<Number>> – "сложение чисел из списка". Возвращает значения типа Number. Если передать через параметр пустой список значений ([]), возвращает 0.
• product <List<Number>> – "перемножение чисел из списка". Возвращает значения типа Number. Если передать через параметр пустой список значений ([]), возвращает 1.

Для вызова этих выражений нужно использовать конструкцию:

Модель безопасности Struct

Модель безопасности Struct позволяет получать доступ к структурным элементам данных.

PSL-файл с описанием модели безопасности Struct находится в KasperskyOS SDK по пути:

toolchain/include/nk/basic.psl

Объект модели безопасности Struct

В файле basic.psl содержится декларация, которая создает объект модели безопасности Struct с именем struct. Соответственно, включение файла basic.psl в описание политики безопасности решения обеспечивает создание объекта модели безопасности Struct по умолчанию.

Объект модели безопасности Struct не имеет параметров и не может быть покрыт аудитом безопасности.

Создавать дополнительные объекты модели безопасности Struct не требуется.

Методы модели безопасности Struct

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

• <{...}>.<имя поля> – "получение доступа к полю словаря". Тип возвращаемых данных соответствует типу поля словаря.
• <List | Set | Sequence | Array>.[<номер элемента>] – "получение доступа к элементу данных". Тип возвращаемых данных соответствует типу элементов. Нумерация элементов начинается с нуля. При выходе за границы набора данных выражение завершается некорректно, и модуль безопасности Kaspersky Security Module возвращает решение "запрещено".
• <HandleDesc>.handle – "получение SID". Возвращает значения типа Handle. (О взаимосвязи между дескрипторами и значениями SID см. "Управление доступом к ресурсам").
• <HandleDesc>.rights – "получение маски прав дескриптора". Возвращает значения типа UInt32.

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

Имя параметра нужно указать в соответствии с IDL-описанием.

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

Модель безопасности Base

Модель безопасности Base позволяет реализовать простейшую логику.

PSL-файл с описанием модели безопасности Base находится в KasperskyOS SDK по пути:

toolchain/include/nk/base.psl

Объект модели безопасности Base

В файле base.psl содержится декларация, которая создает объект модели безопасности Base с именем base. Соответственно, включение файла base.psl в описание политики безопасности решения обеспечивает создание объекта модели безопасности Base по умолчанию. Методы этого объекта можно вызывать без указания имени объекта.

Объект модели безопасности Base не имеет параметров.

Объект модели безопасности Base может быть покрыт аудитом безопасности. Условия выполнения аудита, специфичные для модели безопасности Base, отсутствуют.

Необходимость создавать дополнительные объекты модели безопасности Base возникает в следующих случаях:

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

Методы модели безопасности Base

Модель безопасности Base содержит следующие правила:

• grant ()

  Имеет параметр типа (). Возвращает результат "разрешено".

  Пример:

  /* Клиенту класса foo разрешено обращаться

  * серверу класса bar. */

  request src=foo dst=bar { grant () }

• assert <Boolean>

  Возвращает результат "разрешено", если через параметр передать значение true. Иначе возвращает результат "запрещено".

  Пример:

  /* Любому клиенту в решении будет разрешено обращаться к серверу класса foo,

  * вызывая метод Send службы net.Net, если через параметр port метода Send

  * будет передаваться значение больше 80. Иначе любому клиенту в решении

  * будет запрещено обращаться к серверу класса foo, вызывая метод Send

  * службы net.Net. */

  request dst=foo endpoint=net.Net method=Send { assert (message.port > 80) }

• deny <Boolean | ()>

  Возвращает результат "запрещено", если через параметр передать значение true или (). Иначе возвращает результат "разрешено".

  Пример:

  /* Серверу класса foo запрещено отвечать

  * клиенту класса bar. */

  response src=foo dst=bar { deny () }

• set_level <UInt8>

  Устанавливает уровень аудита безопасности равным значению, переданному через параметр. Возвращает результат "разрешено". (Подробнее об уровне аудита безопасности см. "Описание профилей аудита безопасности".)

  Пример:

  /* Сущность класса foo получит решение "разрешено" от модуля безопасности

  * Kaspersky Security Module, если вызовет метод интерфейса безопасности SetAuditLevel,

  * чтобы изменить уровень аудита безопасности. */

  security src=foo method=SetAuditLevel { set_level (message.audit_level) }

Модель безопасности Regex

Модель безопасности Regex позволяет реализовать валидацию текстовых данных по статически заданным регулярным выражениям.

PSL-файл с описанием модели безопасности Regex находится в KasperskyOS SDK по пути:

toolchain/include/nk/regex.psl

Объект модели безопасности Regex

В файле regex.psl содержится декларация, которая создает объект модели безопасности Regex с именем re. Соответственно, включение файла regex.psl в описание политики безопасности решения обеспечивает создание объекта модели безопасности Regex по умолчанию.

Объект модели безопасности Regex не имеет параметров.

Объект модели безопасности Regex может быть покрыт аудитом безопасности. При этом можно задавать условия выполнения аудита, специфичные для модели безопасности Regex. Для этого в описании конфигурации аудита нужно использовать следующие конструкции:

• emit : ["match"] – аудит выполняется, если вызван метод match;
• emit : ["select"] – аудит выполняется, если вызван метод select;
• emit : ["match", "select"] – аудит выполняется, если вызван метод match или select;
• emit : [] – аудит не выполняется.

Необходимость создавать дополнительные объекты модели безопасности Regex возникает в следующих случаях:

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

Методы модели безопасности Regex

Модель безопасности Regex содержит следующие выражения:

• match {text : <Text>, pattern : <Text>}

  Возвращает значение типа Boolen. Если текст text соответствует регулярному выражению pattern, возвращает true. Иначе возвращает false.

  Пример:

  assert (re.match {text : message.text, pattern : "^[0-9]*$"})

• select {text : <Text>}

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

  Пример:

  choice (re.select {text : "hello world"}) {

  "^hello .*": grant ()

  ".*world$" : grant ()

  _ : deny ()

  }

Модель безопасности HashSet

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

PSL-файл с описанием модели безопасности HashSet находится в KasperskyOS SDK по пути:

toolchain/include/nk/hashmap.psl

Объект модели безопасности HashSet

Чтобы использовать модель безопасности HashSet, нужно создать объект (объекты) этой модели.

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

Объект модели безопасности HashSet имеет следующие параметры:

• type Entry – тип значений в таблицах (поддерживаются целочисленные типы, тип Boolean, а также словари и кортежи на базе целочисленных типов и типа Boolean);
• config – конфигурация пула таблиц:
  • set_size – размер таблицы;
  • pool_size – число таблиц в пуле.

Все параметры объекта модели безопасности HashSet являются обязательными.

Пример:

Объект модели безопасности HashSet может быть покрыт аудитом безопасности. Условия выполнения аудита, специфичные для модели безопасности HashSet, отсутствуют.

Необходимость создавать несколько объектов модели безопасности HashSet возникает в следующих случаях:

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

Правило init модели безопасности HashSet

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

Возвращает результат "разрешено", если создало ассоциацию таблицы с ресурсом.

Возвращает результат "запрещено" в следующих случаях:

• В пуле нет свободных таблиц.
• Ресурс с идентификатором безопасности sid уже ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности HashSet.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Правило fini модели безопасности HashSet

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

Возвращает результат "разрешено", если удалило ассоциацию таблицы с ресурсом.

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности HashSet.
• Идентификатор безопасности sid вне допустимого диапазона.

Правило add модели безопасности HashSet

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

Возвращает результат "разрешено" в следующих случаях:

• Правило добавило значение entry в таблицу.
• В таблице уже содержится значение entry.

Возвращает результат "запрещено" в следующих случаях:

• Таблица полностью заполнена.
• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности HashSet.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Правило remove модели безопасности HashSet

Удаляет значение entry из таблицы, ассоциированной с ресурсом, который имеет идентификатор безопасности sid.

Возвращает результат "разрешено" в следующих случаях:

• Правило удалило значение entry из таблицы.
• В таблице нет значения entry.

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности HashSet.
• Идентификатор безопасности sid вне допустимого диапазона.

Выражение contains модели безопасности HashSet

Проверяет, содержится ли значение entry в таблице, ассоциированной с ресурсом, который имеет идентификатор безопасности sid.

Возвращает значение типа Boolean. Если значение entry содержится в таблице, возвращает true. Иначе возвращает false.

Выполняется некорректно в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности HashSet.
• Идентификатор безопасности sid вне допустимого диапазона.

Если выражение выполнено некорректно, модуль безопасности Kaspersky Security Module возвращает решение "запрещено".

Пример:

Модель безопасности StaticMap

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

Ключи в таблице имеют одинаковый тип и является уникальными и неизменяемыми. Значения ключей в таблице имеют одинаковый тип.

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

PSL-файл с описанием модели безопасности StaticMap находится в KasperskyOS SDK по пути:

toolchain/include/nk/staticmap.psl

Объект модели безопасности StaticMap

Чтобы использовать модель безопасности StaticMap, нужно создать объект (объекты) этой модели.

Объект модели безопасности StaticMap содержит пул двумерных таблиц типа "ключ–значение", которые имеют одинаковый размер. Ресурс может быть ассоциирован только с одной таблицей из пула таблиц каждого объекта модели безопасности StaticMap.

Объект модели безопасности StaticMap имеет следующие параметры:

• type Value – тип значений ключей в таблицах (поддерживаются целочисленные типы);
• config – конфигурация пула таблиц:
  • keys – таблица, содержащая ключи и их значения по умолчанию (ключи имеют тип Key = Text | List<UInt8>);
  • pool_size – число таблиц в пуле.

Все параметры объекта модели безопасности StaticMap являются обязательными.

Пример:

Объект модели безопасности StaticMap может быть покрыт аудитом безопасности. Условия выполнения аудита, специфичные для модели безопасности StaticMap, отсутствуют.

Необходимость создавать несколько объектов модели безопасности StaticMap возникает в следующих случаях:

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

Правило init модели безопасности StaticMap

Ассоциирует свободную таблицу из пула таблиц с ресурсом, который имеет идентификатор безопасности sid. Ключи инициализируются значениями по умолчанию.

Возвращает результат "разрешено", если создало ассоциацию таблицы с ресурсом.

Возвращает результат "запрещено" в следующих случаях:

• В пуле нет свободных таблиц.
• Ресурс с идентификатором безопасности sid уже ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Правило fini модели безопасности StaticMap

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

Возвращает результат "разрешено", если удалило ассоциацию таблицы с ресурсом.

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Правило set модели безопасности StaticMap

Задает значение value ключу key в рабочем экземпляре таблицы, ассоциированной с ресурсом, который имеет идентификатор безопасности sid.

Возвращает результат "разрешено", если задало значение value ключу key. (Текущее значение ключа будет перезаписано, даже если оно равно новому.)

Возвращает результат "запрещено" в следующих случаях:

• Ключ key не содержится в таблице.
• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Правило commit модели безопасности StaticMap

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

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

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Правило rollback модели безопасности StaticMap

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

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

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Выражение get модели безопасности StaticMap

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

Возвращает значение типа Value.

Выполняется некорректно в следующих случаях:

• Ключ key не содержится в таблице.
• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Если выражение выполнено некорректно, модуль безопасности Kaspersky Security Module возвращает решение "запрещено".

Пример:

Выражение get_uncommited модели безопасности StaticMap

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

Возвращает значение типа Value.

Выполняется некорректно в следующих случаях:

• Ключ key не содержится в таблице.
• Ресурс с идентификатором безопасности sid не ассоциирован с таблицей из пула таблиц используемого объекта модели безопасности StaticMap.
• Идентификатор безопасности sid вне допустимого диапазона.

Если выражение выполнено некорректно, модуль безопасности Kaspersky Security Module возвращает решение "запрещено".

Модель безопасности Flow

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

PSL-файл с описанием модели безопасности Flow находится в KasperskyOS SDK по пути:

toolchain/include/nk/flow.psl

Объект модели безопасности Flow

Чтобы использовать модель безопасности Flow, нужно создать объект (объекты) этой модели.

Один объект модели безопасности Flow позволяет ассоциировать множество ресурсов со множеством конечных автоматов, которые имеют одинаковую конфигурацию. Ресурс может быть ассоциирован только с одним конечным автоматом каждого объекта модели безопасности Flow.

Объект модели безопасности Flow имеет следующие параметры:

• type State – тип, определяющий множество состояний конечного автомата (вариантный тип, объединяющий текстовые литералы);
• config – конфигурация конечного автомата:
  • states – множество состояний конечного автомата (должно совпадать со множеством состояний, заданных типом State);
  • initial – начальное состояние конечного автомата;
  • transitions – описание допустимых переходов между состояниями конечного автомата.

Все параметры объекта модели безопасности Flow являются обязательными.

Пример:

Диаграмма состояний конечного автомата в примере

Объект модели безопасности Flow может быть покрыт аудитом безопасности. При этом можно задавать условия выполнения аудита, специфичные для модели безопасности Flow. Для этого в описании конфигурации аудита нужно использовать следующую конструкцию:

omit : [<"состояние 1">[,] ...] – аудит не выполняется, если конечный автомат находится в одном из перечисленных состояний.

Необходимость создавать несколько объектов модели безопасности Flow возникает в следующих случаях:

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

Правило init модели безопасности Flow

Создает конечный автомат и ассоциирует его с ресурсом, который имеет идентификатор безопасности sid. Созданный конечный автомат имеет конфигурацию, заданную в параметрах используемого объекта модели безопасности Flow.

Возвращает результат "разрешено", если создало ассоциацию конечного автомата с ресурсом.

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid уже ассоциирован с конечным автоматом используемого объекта модели безопасности Flow.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Правило fini модели безопасности Flow

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

Возвращает результат "разрешено", если удалило ассоциацию конечного автомата с ресурсом.

Возвращает результат "запрещено" в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с конечным автоматом используемого объекта модели безопасности Flow.
• Идентификатор безопасности sid вне допустимого диапазона.

Правило enter модели безопасности Flow

Переводит конечный автомат, ассоциированный с ресурсом, который имеет идентификатор безопасности sid, в состояние state.

Возвращает результат "разрешено", если перевело конечный автомат в состояние state.

Возвращает результат "запрещено" в следующих случаях:

• Переход в состояние state из текущего состояния не допускается конфигурацией конечного автомата.
• Ресурс с идентификатором безопасности sid не ассоциирован с конечным автоматом используемого объекта модели безопасности Flow.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Правило allow модели безопасности Flow

Проверяет, что состояние конечного автомата, ассоциированного с ресурсом, который имеет идентификатор безопасности sid, входит в набор состояний states.

Возвращает результат "разрешено", если состояние конечного автомата входит в набор состояний states.

Возвращает результат "запрещено" в следующих случаях:

• Состояние конечного автомата не входит в набор состояний states.
• Ресурс с идентификатором безопасности sid не ассоциирован с конечным автоматом используемого объекта модели безопасности Flow.
• Идентификатор безопасности sid вне допустимого диапазона.

Пример:

Выражение query модели безопасности Flow

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

Выполняется некорректно в следующих случаях:

• Ресурс с идентификатором безопасности sid не ассоциирован с конечным автоматом используемого объекта модели безопасности Flow.
• Идентификатор безопасности sid вне допустимого диапазона.

Если выражение выполнено некорректно, модуль безопасности Kaspersky Security Module возвращает решение "запрещено".

Пример:

Пример ping

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

О примере ping

Пример ping включает в себя две сущности: Client и Server.

Сущность Server предоставляет два идентичных метода Ping и Pong, которые получают число и возвращают измененное число:

Сущность Client вызывает оба этих метода в различной последовательности. Если вызов метода запрещен политикой безопасности решения, выводится сообщение Failed to call...

В примере ping реализуется политика безопасности решения (security.psl) на базе модели безопасности модели безопасности Flow.

Состав примера ping

Пример ping состоит из следующих файлов:

• client/src/client.c
• resources/edl/Client.edl
• server/src/server.c
• resources/edl/Server.edl, resources/cdl/Control.cdl, resources/idl/Connection.idl
• init.yaml
• security.psl

Реализация сущности Client в примере ping

Сущность Client для вызывает методы Ping и Pong в различной последовательности.

Реализация сущности Server в примере ping

Файлы описаний в примере ping

Описание сущности Client

Сущность Client не реализует ни одного интерфейса, поэтому в EDL-описании достаточно объявить имя сущности.

Описание сущности Server

Сущность Server реализует интерфейс Connection, содержащий два метода – Ping и Pong. Как и в примере echo, требуется объявить отдельный компонент (например Control), содержащий реализацию интерфейса Connection.

В EDL-описании сущности Server необходимо указать, что она содержит экземпляр компонента Control:

В CDL-описании компонента Control необходимо указать, что он содержит реализацию интерфейса Connection:

В пакете Connection необходимо объявить интерфейс Connection, содержащий два метода – Ping и Pong:

Init-описание

Чтобы сущность Client могла вызвать метод сущности Server, между ними требуется создать IPC-канал.

Политика безопасности решения в примере ping

Политика безопасности решения в этом примере разрешает запуск всех сущностей и позволяет любой сущности обращаться к сущностям Core и Server. При этом обращениями к сущности Server управляют методы модели безопасности Flow.

Конечный автомат, описанный в конфигурации объекта request_state модели безопасности Flow, имеет два состояния: ping_next и pong_next. Исходное состояние – ping_next. Разрешены только переходы из ping_next в pong_next и обратно.

При вызове методов Ping и Pong проверяется текущее состояние объекта request_state. В состоянии ping_next разрешен только вызов Ping, при этом состояние изменится на pong_next. Аналогично, в состоянии pong_next разрешен только вызов Pong, при этом состояние изменится на ping_next.

Таким образом, методы Ping и Pong разрешено вызывать только по очереди.

Сборка и запуск примера ping

См. "Сборка и запуск примеров".

Тестирование политики безопасности решения на языке Policy Assertion Language (PAL)

Базовый сценарий использования Policy Assertion Language (PAL) – это создание тестовых сценариев для проверки политик безопасности решения, написанных с использованием PSL.

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

Общий синтаксис

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

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

Для объявления группы тестовых сценариев используется блочная декларация assert:

Синтаксис запросов

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

Здесь:

• <ожидание> – ожидаемое решение: grant, deny или any.

  При ожидании any решение модуля безопасности игнорируется, но ошибка при выполнении запроса пометит тестовый сценарий как неудачный.

  Если ожидаемое решение не указано явно, ожидается решение grant.

• <заголовок> – опциональный параметр, содержащий текстовый заголовок описываемого запроса.
• <операция> – один из видов обращения к модулю безопасности: execute, security, request или response.
• <селекторы события> – допустимые селекторы события совпадают с селекторами, использующимися при привязке методов моделей безопасности к событиям безопасности. Например можно указать сущность-получатель сообщения или вызываемый метод.
• {сообщение} – параметр, содержащий значение аргументов вызываемого метода. Значение этого параметра должно соответствовать операции и селекторам запроса. По умолчанию передается пустое количество аргументов {}.

Пример:

Сокращенная форма запросов

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

• При выполнении операции execute, можно сохранить дескриптор запускаемой сущности в переменную с помощью оператора <-.
• Сокращенная форма для операции security: <сущность> ! <путь.к.методу> {сообщение}

  При выполнении разворачивается в полную форму: security src=<сущность> method=<путь.к.методу> {сообщение}

• Сокращенная форма для операции request: <клиент> ~> <сервер> : <путь.к.имплементации.метода> {сообщение}

  При выполнении разворачивается в полную форму: request src=<клиент> dst=<сервер> endpoint=<путь.к.имплементации> method=<метод> {сообщение}

• Сокращенная форма для операции response: <клиент> <~ <сервер> : <путь.к.имплементации.метода> {сообщение}

  При выполнении разворачивается в полную форму: response src=<сервер> dst=<клиент> endpoint=<путь.к.имплементации> method=<метод> {сообщение}

Пример:

Запуск тестов

Чтобы запустить написанные на PAL тестовые сценарии, необходимо использовать флаг --tests run при запуске компилятора nk-psl-gen-c:

Компилятор nk-psl-gen-c сгенерирует код модуля безопасности и код тестовых сценариев, а затем скомпилирует их с помощью gcc и запустит.

Чтобы сгенерировать код тестовых сценариев, но не компилировать и запускать их, необходимо использовать флаг --tests generate.

KasperskyOS API

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

Все используемые в решении сущности, компоненты и интерфейсы должны быть статически описаны с помощью языков EDL, CDL и IDL. Соответствующие описания хранятся в файлах *.edl, *.cdl и *.idl.

Файлы описаний используются при сборке решения для следующих целей:

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

Модель "сущность-компонент-интерфейс"

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

В KasperskyOS есть три вида файлов статических описаний:

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

Сущность Server включает в себя экземпляры компонентов Terminal и Serial, содержащих различные реализации интерфейса Console

EDL

Каждая сущность в KasperskyOS должна быть описана на языке Entity Definition Language в отдельном файле <имя сущности>.edl.

EDL-файл содержит следующие разделы (порядок важен):

1. Имя сущности. Обязательный раздел, начинающаяся с ключевого слова entity, за которым следует имя сущности.

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

2. Интерфейс безопасности, используемый сущностью. Раздел не является обязательным и должен быть добавлен, только если сущность использует интерфейс безопасности. Декларируется ключевым словом security, за которым следует полное имя интерфейса.
3. Перечень реализаций интерфейсов, предоставляемых сущностью. Не является обязательным и описывается в секции interfaces. Каждая реализация интерфейса указывается отдельной строкой в следующем формате:

   interfaces {

   <имя реализации интерфейса>:<имя интерфейса>

   }

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

   Имя реализации интерфейса не может содержать символ подчеркивания (_).

4. Список экземпляров компонентов, входящих в сущность. Не является обязательным и описывается в секции components. Каждый экземпляр компонента указывается отдельной строкой в следующем формате:

   components {

   <имя экземпляра компонента>:<имя компонента>

   }

   Для каждого указанного компонента необходимо создать отдельный файл <имя компонента>.cdl, содержащий описание компонента на языке CDL. В сущность можно добавить несколько экземпляров одного и того же компонента, причем каждый может иметь отдельное состояние (см. ниже пример сущности UartDriver).

   Имя экземпляра компонента не может содержать символ подчеркивания (_).

Секции interfaces и components не являются обязательными и добавляются только для серверных сущностей. Реализации интерфейсов, объявленные в секции interfaces, а также реализации, входящие в компоненты из секции components могут использоваться сущностями-клиентами.

EDL поддерживает однострочные и многострочные комментарии в стиле C++:

Примеры EDL-файлов

В простейшем случае сущность не использует интерфейс безопасности и не предоставляет функциональности другим сущностям, подобно сущности hello из примера hello. EDL-описание такой сущности содержит только ключевое слово entity и имя сущности.

В следующем примере сущность EFoo содержит единственную реализацию интерфейса и не использует интерфейс безопасности.

В следующем примере сущность UartDriver содержит два экземпляра компонента UartComp – по одному на каждое UART-устройство.

Сущность UartDriver не использует интерфейс безопасности.

CDL

Каждый используемый в решении компонент должен быть описан на языке CDL в отдельном файле <имя компонента>.cdl.

CDL-файл содержит следующие разделы:

1. Имя компонента. Перед именем компонента ставится ключевое слово component.

   Имя компонента должно начинаться с заглавной буквы и не может содержать символ подчеркивания (_).

2. Интерфейс безопасности, содержащийся в этом компоненте. Раздел не является обязательным и должен быть добавлен, только если в компоненте содержится интерфейс безопасности. Декларируется ключевым словом security, за которым следует полное имя интерфейса.
3. Перечень реализаций интерфейсов, которые включены в этот компонент. Интерфейсы декларируются в секции interfaces, внутри которой каждая реализация интерфейса указывается отдельной строкой в следующем формате:

   interfaces {

   <имя реализации интерфейса>:<имя интерфейса>

   }

   Компонент может содержать несколько реализаций одного интерфейса. Все реализуемые интерфейсы необходимо описать на языке IDL в IDL-файлах.

   Имя реализации интерфейса не может содержать символ подчеркивания (_).

4. Список экземпляров компонентов, вложенных в этот компонент. Раздел не является обязательным и добавляется в том случае, если компонент содержит вложенные компоненты. Компоненты декларируются в секции components, внутри которой каждый экземпляр компонента указывается отдельной строкой в следующем формате:

   components {

   <имя экземпляра компонента>:<имя компонента>

   }

   Для каждого указанного компонента необходимо создать отдельный файл <имя компонента>.cdl, содержащий описание компонента на языке CDL. В компонент можно добавить несколько экземпляров одного и того же компонента, причем каждый может иметь отдельное состояние.

   Имя экземпляра компонента не может содержать символ подчеркивания (_).

СDL поддерживает однострочные и многострочные комментарии в стиле C++.

Примеры CDL-файлов

В простейшем случае компонент содержит единственную реализацию интерфейса, подобно компоненту ping из примера echo.

В следующем примере компонент CoFoo содержит реализации двух интерфейсов, объявленных в двух разных пакетах Foo и Baz (т.е. в файлах Foo.idl и Bar.idl):

В следующем примере компонент CoFoo содержит единственную реализацию интерфейса, а также вложенный компонент.

IDL

Все реализуемые в решении интерфейсы необходимо описать в IDL-файлах.

В каждом IDL-файле может быть объявлен только один интерфейс.

IDL-файл содержит следующие разделы:

1. Имя интерфейса.

   Единственный обязательный раздел.

   Имя интерфейса должно начинаться с заглавной буквы и не может содержать символ подчеркивания (_).

   Объявление имени имеет следующий формат:

   package <имя описываемого интерфейса>

   Имя интерфейса может быть составным. В этом случае оно используется для формирования пути к IDL-файлу, например:

   /* Module.idl расположен по следующему пути: a/b/c/Module.idl */

   package a.b.c.Module

2. Импорт внешних пакетов.

   Инструкция импорта пакета имеет следующий формат:

   import <имя внешнего пакета>

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

3. Объявление структур, вариантных типов, именованных констант и синонимов.
4. Объявление методов интерфейса.

   Объявление методов интерфейса имеет следующий синтаксис:

   interface {

   <Объявления методов>

   }

   Внутри фигурных скобок находятся объявления методов, имеющие следующий синтаксис:

   <Имя метода> (<аргументы>);

   Имя метода не может содержать символ подчеркивания (_). Рекомендуется начинать имена методов с заглавной буквы.

   Аргументы разделяются на входные (in) и выходные (out) и перечисляются через запятую. Пример объявления интерфейса:

   interface {

   // Объявление метода Ping

   Ping(in UInt32 value, out UInt32 result);

   }

   Для возврата кодов ошибок, возникающих в результате обработки запроса сущностью-сервером, не рекомендуется использовать out-аргументы. Вместо них рекомендуется использовать специальные error-аргументы. Подробнее см. Работа с ошибками в IDL.

IDL поддерживает однострочные и многострочные комментарии в стиле C++.

Примеры IDL-файлов

В простейшем случае IDL-описание содержит только имя и объявление интерфейса:

Пример более сложного IDL-описания: