В этой статье я расскажу, из чего должен состоять проект программы для KasperskyOS. За основу я возьму проект для учебного курса на Stepik. Сам учебный курс находится здесь.
… пробежимся по основным особенностям KasperskyOS, чтобы понимать причины тех или иных архитектурных особенностей.
KasperskyOS Community Edition в текущем исполнении (на уровне версии 1.1.1) предназначена для использования в качестве ОС, встраиваемой в различные устройства.
Следствие первое — результатом сборки проекта является не какой-то исполнимый файл, а загружаемый образ для какого-то устройства. В этом отношении KasperskyOS напоминает Yocto, OpenWRT и тому подобные проекты. Образ содержит в себе бутлоадер, ядро ОС, систему безопасности и, собственно, прикладные исполнимые файлы.
Следствие второе — в том решении, что собирается в итоге компиляции такого образа, «из коробки» сейчас отсутствует консоль, какой-то графический интерфейс, командный интерпретатор или оболочка. Чтобы как-то в динамике управлять происходящим внутри программы — разработчик это должен предусмотреть самостоятельно.
Следствие третье — платформа разработки и платформа исполнения не совпадают. Причем, совсем (разработка обычно ведётся на х86, а KasperskyOS CE сейчас предназначена для запуска на процессорах ARM). То есть в состав инструментария входит кросс-компилятор.
KasperskyOS предназначена для использования в таких местах, где есть требования к кибербезопасности результирующего решения, но невозможно установить наложенные средства защиты.
Реализация защиты становится частью операционной системы и всего решения. Для воплощения такой защиты используется старый принцип — «разделяй и властвуй» 🙂 То есть, весь прикладной код делится на части, взаимодействие между которыми строго контролируется. Принципы построения такой архитектуры не являются целью этой статьи, но с ними можно познакомиться на мини-курсах.
Проект прикладного решения для KasperskyOS состоит из трех слоев:
Посмотрим по слоям.
Сам по себе ничего интересного собой не представляет. Пишется на языках С (под компилятор gcc, используется в указанном примере) или C++ (компилятор g++). Должен состоять из одного или более (ссылающихся друг на друга) файлов, один из которых cодержит функцию main(). Обычно эти файлы располагаются в папках, соответствующих именам классов процессов.
Но есть одна тонкость более высокого уровня. Архитектура рабочего приложения, более сложного чем «hello world» для обеспечения безопасности скорее всего будет содержать более одного процесса. Каждый процесс в рамках KasperskyOS упаковывается в отдельный исполнимый файл и, соответственно, имеет собственный main(). Kaspersky Security Module контролирует взаимодействия только отдельных исполнимых файлов между собой, а также с ядром.
В рамках примера “hello_vfs” фактически работают четыре исполнимых файла:
Эти две части необходимы для автоматической компиляции транспортного кода и Kaspersky Security Module.
Генерируемый транспортный код отвечает за запаковку, адресную передачу и распаковку IPC-сообщений между процессами. Именно он и образует в нужных местах «отверстия» в логических стенках, разделяющих процессы между собой. Транспортный код формируется на основе описаний сущностей (EDL), компонентов (CDL) и их интерфейсов (IDL).
В случае статического описания IPC-канала из соответствующих файлов берется описание структуры сообщения. Отправитель и получатель указываются в файле init.yaml.in. При динамическом формировании канала для выполнения этих действий используются функции API ядра KasperskyOS.
Kaspersky Security Module отвечает за своевременное «открытие» и «закрытие» этих «отверстий». Код KSM также генерируется на основе набора файлов PSL, обычно находящихся в папке einit, и формирует отдельный исполнимый файл. Каждый IPC-запрос, идущий между доменами безопасности (а фактически — между исполнимыми файлами), ядро перенаправляет в ksm.module для получения вердикта о разрешении на выполнение этого запроса. Возвращающийся ответ также будет проверен модулем безопасности.
К этому этапу готовы отдельные скомпилированные компоненты и библиотеки, которые необходимо собрать в единое целое (загружаемый образ для целевой платформы или эмулятора). Для выполнения этого процесса в SDK KasperskyOS применяется система CMake. Управляется она набором файлов CMakeLists.txt, ссылающихся друг на друга при помощи операторов add_subdirectory().
В головном CMakeLists определяются ссылки на папки с внешними (из состава SDK) и внутренними (из состава проекта) исходными и прекомпилированными файлами. В управляющих файлах нижележащих папок назначается соответствие между именем класса и файлом с исходником, устанавливаются зависимости от библиотек, включаемых внутрь соответствующих исполнимых файлов.
Последним вызывается СMakeLists, определяющий сборку файла einit (т.к. при этом проверяется готовность всех остальных компонентов, включая KSM) и выполняющий финальную сборку образов для запуска.
В этой статье я расскажу, из чего должен состоять проект программы для KasperskyOS. За основу я возьму проект для учебного курса на Stepik. Сам учебный курс находится здесь.
… пробежимся по основным особенностям KasperskyOS, чтобы понимать причины тех или иных архитектурных особенностей.
KasperskyOS Community Edition в текущем исполнении (на уровне версии 1.1.1) предназначена для использования в качестве ОС, встраиваемой в различные устройства.
Следствие первое — результатом сборки проекта является не какой-то исполнимый файл, а загружаемый образ для какого-то устройства. В этом отношении KasperskyOS напоминает Yocto, OpenWRT и тому подобные проекты. Образ содержит в себе бутлоадер, ядро ОС, систему безопасности и, собственно, прикладные исполнимые файлы.
Следствие второе — в том решении, что собирается в итоге компиляции такого образа, «из коробки» сейчас отсутствует консоль, какой-то графический интерфейс, командный интерпретатор или оболочка. Чтобы как-то в динамике управлять происходящим внутри программы — разработчик это должен предусмотреть самостоятельно.
Следствие третье — платформа разработки и платформа исполнения не совпадают. Причем, совсем (разработка обычно ведётся на х86, а KasperskyOS CE сейчас предназначена для запуска на процессорах ARM). То есть в состав инструментария входит кросс-компилятор.
KasperskyOS предназначена для использования в таких местах, где есть требования к кибербезопасности результирующего решения, но невозможно установить наложенные средства защиты.
Реализация защиты становится частью операционной системы и всего решения. Для воплощения такой защиты используется старый принцип — «разделяй и властвуй» 🙂 То есть, весь прикладной код делится на части, взаимодействие между которыми строго контролируется. Принципы построения такой архитектуры не являются целью этой статьи, но с ними можно познакомиться на мини-курсах.
Проект прикладного решения для KasperskyOS состоит из трех слоев:
Посмотрим по слоям.
Сам по себе ничего интересного собой не представляет. Пишется на языках С (под компилятор gcc, используется в указанном примере) или C++ (компилятор g++). Должен состоять из одного или более (ссылающихся друг на друга) файлов, один из которых cодержит функцию main(). Обычно эти файлы располагаются в папках, соответствующих именам классов процессов.
Но есть одна тонкость более высокого уровня. Архитектура рабочего приложения, более сложного чем «hello world» для обеспечения безопасности скорее всего будет содержать более одного процесса. Каждый процесс в рамках KasperskyOS упаковывается в отдельный исполнимый файл и, соответственно, имеет собственный main(). Kaspersky Security Module контролирует взаимодействия только отдельных исполнимых файлов между собой, а также с ядром.
В рамках примера “hello_vfs” фактически работают четыре исполнимых файла:
Эти две части необходимы для автоматической компиляции транспортного кода и Kaspersky Security Module.
Генерируемый транспортный код отвечает за запаковку, адресную передачу и распаковку IPC-сообщений между процессами. Именно он и образует в нужных местах «отверстия» в логических стенках, разделяющих процессы между собой. Транспортный код формируется на основе описаний сущностей (EDL), компонентов (CDL) и их интерфейсов (IDL).
В случае статического описания IPC-канала из соответствующих файлов берется описание структуры сообщения. Отправитель и получатель указываются в файле init.yaml.in. При динамическом формировании канала для выполнения этих действий используются функции API ядра KasperskyOS.
Kaspersky Security Module отвечает за своевременное «открытие» и «закрытие» этих «отверстий». Код KSM также генерируется на основе набора файлов PSL, обычно находящихся в папке einit, и формирует отдельный исполнимый файл. Каждый IPC-запрос, идущий между доменами безопасности (а фактически — между исполнимыми файлами), ядро перенаправляет в ksm.module для получения вердикта о разрешении на выполнение этого запроса. Возвращающийся ответ также будет проверен модулем безопасности.
К этому этапу готовы отдельные скомпилированные компоненты и библиотеки, которые необходимо собрать в единое целое (загружаемый образ для целевой платформы или эмулятора). Для выполнения этого процесса в SDK KasperskyOS применяется система CMake. Управляется она набором файлов CMakeLists.txt, ссылающихся друг на друга при помощи операторов add_subdirectory().
В головном CMakeLists определяются ссылки на папки с внешними (из состава SDK) и внутренними (из состава проекта) исходными и прекомпилированными файлами. В управляющих файлах нижележащих папок назначается соответствие между именем класса и файлом с исходником, устанавливаются зависимости от библиотек, включаемых внутрь соответствующих исполнимых файлов.
Последним вызывается СMakeLists, определяющий сборку файла einit (т.к. при этом проверяется готовность всех остальных компонентов, включая KSM) и выполняющий финальную сборку образов для запуска.
