Мы регулярно проводим вебинары для разработчиков, объединенные в серию KasperskyOS Night Practice. На них мы показываем, как практически создаются кибериммунные продукты на базе нашей операционной системы. 19 апреля прошел очередной вебинар, который был посвящен разработке программного диода данных на KasperskyOS. Исходный код примера программного диода можно скачать с Github. А на канале сообщества в Telegram вы можете скачать презентации, посвященные затронутым на вебинаре темам.
Во время трансляции и после мероприятия к нам поступило много вопросов. Делимся с вами ответами экспертов команды KasperskyOS Community Edition.
Правильно ли я понимаю, что основное назначение системы — это использование ее в качестве шлюза?
KasperskyOS это разноплановая операционная система, на базе которой можно создавать не только шлюзы. На сегодняшний день уже проходят пилотирование тонкие клиенты, ведется исследовательская работа по созданию мобильных экранных устройств. Также мы сотрудничаем с производителями электронных блоков управления для автомобильной техники.
Ваше решение применялось для разграничения доступа к нефтеперекачивающему оборудованию, в котором информация о подшипниках передавалась по интернету? Или это был абстрактный пример?
В большей мере речь идет о проектах с контролем насосного оборудования. Да, конечно, есть реальные проекты, например, с известной российской компанией «СтанкоМашКомплекс», в которых промышленные станки с многомиллионной стоимостью подключались в облако и передавались заказчику по схеме с мониторингом загрузки станка и повременной оплатой его использования. Количество таких проектов растет.
Насколько такие решения соответствуют № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»
Шлюзы пока не относятся к КИИ и не подлежат обязательной сертификации. Очевидно, что при решении задач контроля КИИ они должны будут пройти сертификацию, и у нас есть связанные с этим планы. В соответствии с ее требованиями к устройству шлюза, операционной системе и функциональности мы будем решать, когда и в каких формах ее проводить.
Плюсы и проблемы цифровизации понятны. Интересно, насколько дорого в деньгах и по времени установки и отладки это обойдется для условного завода, который хочет себе такую систему?
Обычно настройка шлюза занимает не более недели, а типовой проект длится до трех месяцев.
Возможен ли вариант настройки аварийной балансировки на несколько источников или приемников?
Сами шлюз и KasperskyOS средств балансировки не имеют, но мы рассматривали возможность балансировки с помощью внешних агентов и управления питанием шлюза.
А представленный пример диода данных может работать только в QEMU?
Код примера можно запустить на Raspberry Pi для которого и создавалась KasperskyOS Community Edition, но мы этого в проекте не делали для экономии времени. Если вам интересна реализация «на железе», то да — это возможно, но код примера надо будет немного поправить.
Может ли представленный пример кода диода работать на Raspberry PI 4, на плате которого только один сетевой интерфейс?
Пример может быть запущен на Raspberry Pi 4. Если разделить VFS на две части, обеспечив соответственно обращения к разными сетевым интерфейсам, можно добиться нужного сценария. Такие приемы использовались при разработке коммерческого решения KISG 100. Однако следует признать, что так как в RasPi4 один аппаратный сетевой интерфейс, практически значимое решение Диода данных в такой конфигурации не построишь. Тем не менее при выполнении определенных условий, например, подключения к малинке по USB дополнительной сетевой карты, такое решение вполне возможно.
Можно ли перезапускать сущности после падения? Хоть каким-то способом?
Зависит от версии ядра операционной системы. Из узкоспециализированной системы для запуска приложений KasperskyOS постепенно превращается в полноценную платформу и появление такой возможности не заставит себя долго ждать.
Что помимо загрузчика u-boot содержится в флешке для Raspberry Pi с образом KasperskyOS? Драйверы? Может ли их модификация повлиять на безопасность решения?
Короткий ответ – бывает по-разному. В ряде решений на KasperskyOS есть доверенная загрузка ОС, проверка целостности самого загрузчика и проверка целостности пакета приложений, а также другие дополнительные возможности обеспечения безопасности.
Для политик SELinux есть linter для проверки. Есть ли что-то аналогичное для KOS?
На KasperskyOS компилятор при сборке решений может проверять синтаксис политик на ошибки. Также могут помочь юнит-тесты. Учитывая перспективы разработки тулинга KasperskyOS, скорее всего, что и инструмент проверки политик не за горами. Дополнительно надо отметить, что в SDK есть примеры с тестами, которые можно посмотреть и разобраться в использованных политиках.
Что можно создавать динамически в процессе работы KOS: политику безопасности, IPC-связи между сущностями?
Хороший вопрос. Несколько лет назад KasperskyOS была в большой степени статической системой. Сейчас активно разрабатываются новые динамические возможности. Уже в работе возможность запуска новых процессов, возможность динамически устанавливать каналы связи между этими процессами. Несмотря на то, что политики и домены безопасности описываются все еще статически, у политик могут быть состояния, словари для хранения состояний, конечные автоматы, что позволяет говорить об их динамичности. Со временем такие политики ведут себя по-разному и могут реагировать на манифесты приложений или пользовательский ввод.
Является ли KasperskyOS закрытой в плане допуска разработчиков к ней? Насколько просто будет любителям поковырять саму ОС и/или писать под нее свои хелловорды?
Наша система KasperskyOS CE SDK открыта, а сообщество разработчиков, работающих с ней, активно развивается, поэтому заходите на специальную страницу, скачивайте SDK, документацию, изучайте и включайтесь в проекты, а мы будем вам в этом помогать.
Планируется ли открывать исходный код ОС для возможности его свободного исследования всеми желающими на предмет поиска уязвимостей?
Сейчас этот вопрос обсуждается в руководстве «Лаборатории Касперского».
Можем ли мы в KasperskyOS использовать callback?
Несмотря что IPC в KasperskyOS синхронен, есть запрос и ждем на него ответ и пока ждем, ничего в потоке не сделаем. Однако, есть возможность имитировать callback, что, как правило, делается через длительный запрос. Спросили — и висим до тех пор, пока не захотим получить какой-то обратный вызов. Так делать можно, но в нашем примере с диодом мы этим не пользовались.
Есть ли в состав KasperskyOS открытые примеры интеграции драйверов и прикладных программ, изначально предназначенных для Linux?
С точки зрения прикладных программ – да, регулярно этим занимаемся и POSIX-совместимость этому сильно помогает. Что касается драйверов, в KasperskyOS нет слоя совместимости с Linuх и при создании драйверов необходимо работать с собственными API.
Есть ли в KasperskyOS аналог утилиты ipconfig? Планируется ли в дальнейшем создание чего-то подобного? Или какие есть альтернативные способы узнать текущие соединения, настроить их?
В примерах, включенных в KasperskyOS SDK Community Edition, для настройки сетевых интерфейсов используется сущность dhcpcd, поставляемая в комплекте с SDK. Также имеется возможность работать с сетевыми интерфейсами напрямую из кода C/C++.
Могли бы Вы привести пример, как можно использовать сущность dhcpcd для настройки сетевых интерфейсов?
Как использовать dhcpcd для настройки сетей можно посмотреть в нескольких примерах, поставляемых с SDK, например, в multi_vfs_dhcpcd. Параметры сетей указываются в файле /etc/dhcpcd.conf, но путь может быть переопределен с помощью аргументов командной строки для сущности dhcpcd, устанавливаемых в сущности Env.
В документации на KasperskyOS v1.0 на стр.32 написано, что «Компонент VFS можно использовать, как напрямую (путем статической линковки), так и через IPC (как отдельную сущность)». Правильно ли я понимаю, что имеется в виду, что в случае статической линковки и работы с файлами предлагается драйвер блочного устройства и модуль файловой системы вкомпилировать прямо в прикладную программу?
На данный момент драйвер блочного устройства всегда запускается отдельным процессом. Поэтому прикладную программу предлагается компилировать только c библиотеками VFS и реализацией требуемых файловых систем. Именно так устроен пример embedded_vfs.
Статическая линковка с используемым компонентом удобна для отладки, т.к. все работает в одном адресном пространстве. Также можно рассчитывать на более быструю обработку вызовов, т.к. нет временных затрат на IPC и работу KSM-модуля. Однако с точки зрения безопасности всегда рекомендуется использовать компонент по IPC, в виде отдельного процесса.
Подписывайтесь на каналы нашего сообщества в соцсетях:
Мы регулярно проводим вебинары для разработчиков, объединенные в серию KasperskyOS Night Practice. На них мы показываем, как практически создаются кибериммунные продукты на базе нашей операционной системы. 19 апреля прошел очередной вебинар, который был посвящен разработке программного диода данных на KasperskyOS. Исходный код примера программного диода можно скачать с Github. А на канале сообщества в Telegram вы можете скачать презентации, посвященные затронутым на вебинаре темам.
Во время трансляции и после мероприятия к нам поступило много вопросов. Делимся с вами ответами экспертов команды KasperskyOS Community Edition.
Правильно ли я понимаю, что основное назначение системы — это использование ее в качестве шлюза?
KasperskyOS это разноплановая операционная система, на базе которой можно создавать не только шлюзы. На сегодняшний день уже проходят пилотирование тонкие клиенты, ведется исследовательская работа по созданию мобильных экранных устройств. Также мы сотрудничаем с производителями электронных блоков управления для автомобильной техники.
Ваше решение применялось для разграничения доступа к нефтеперекачивающему оборудованию, в котором информация о подшипниках передавалась по интернету? Или это был абстрактный пример?
В большей мере речь идет о проектах с контролем насосного оборудования. Да, конечно, есть реальные проекты, например, с известной российской компанией «СтанкоМашКомплекс», в которых промышленные станки с многомиллионной стоимостью подключались в облако и передавались заказчику по схеме с мониторингом загрузки станка и повременной оплатой его использования. Количество таких проектов растет.
Насколько такие решения соответствуют № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»
Шлюзы пока не относятся к КИИ и не подлежат обязательной сертификации. Очевидно, что при решении задач контроля КИИ они должны будут пройти сертификацию, и у нас есть связанные с этим планы. В соответствии с ее требованиями к устройству шлюза, операционной системе и функциональности мы будем решать, когда и в каких формах ее проводить.
Плюсы и проблемы цифровизации понятны. Интересно, насколько дорого в деньгах и по времени установки и отладки это обойдется для условного завода, который хочет себе такую систему?
Обычно настройка шлюза занимает не более недели, а типовой проект длится до трех месяцев.
Возможен ли вариант настройки аварийной балансировки на несколько источников или приемников?
Сами шлюз и KasperskyOS средств балансировки не имеют, но мы рассматривали возможность балансировки с помощью внешних агентов и управления питанием шлюза.
А представленный пример диода данных может работать только в QEMU?
Код примера можно запустить на Raspberry Pi для которого и создавалась KasperskyOS Community Edition, но мы этого в проекте не делали для экономии времени. Если вам интересна реализация «на железе», то да — это возможно, но код примера надо будет немного поправить.
Может ли представленный пример кода диода работать на Raspberry PI 4, на плате которого только один сетевой интерфейс?
Пример может быть запущен на Raspberry Pi 4. Если разделить VFS на две части, обеспечив соответственно обращения к разными сетевым интерфейсам, можно добиться нужного сценария. Такие приемы использовались при разработке коммерческого решения KISG 100. Однако следует признать, что так как в RasPi4 один аппаратный сетевой интерфейс, практически значимое решение Диода данных в такой конфигурации не построишь. Тем не менее при выполнении определенных условий, например, подключения к малинке по USB дополнительной сетевой карты, такое решение вполне возможно.
Можно ли перезапускать сущности после падения? Хоть каким-то способом?
Зависит от версии ядра операционной системы. Из узкоспециализированной системы для запуска приложений KasperskyOS постепенно превращается в полноценную платформу и появление такой возможности не заставит себя долго ждать.
Что помимо загрузчика u-boot содержится в флешке для Raspberry Pi с образом KasperskyOS? Драйверы? Может ли их модификация повлиять на безопасность решения?
Короткий ответ – бывает по-разному. В ряде решений на KasperskyOS есть доверенная загрузка ОС, проверка целостности самого загрузчика и проверка целостности пакета приложений, а также другие дополнительные возможности обеспечения безопасности.
Для политик SELinux есть linter для проверки. Есть ли что-то аналогичное для KOS?
На KasperskyOS компилятор при сборке решений может проверять синтаксис политик на ошибки. Также могут помочь юнит-тесты. Учитывая перспективы разработки тулинга KasperskyOS, скорее всего, что и инструмент проверки политик не за горами. Дополнительно надо отметить, что в SDK есть примеры с тестами, которые можно посмотреть и разобраться в использованных политиках.
Что можно создавать динамически в процессе работы KOS: политику безопасности, IPC-связи между сущностями?
Хороший вопрос. Несколько лет назад KasperskyOS была в большой степени статической системой. Сейчас активно разрабатываются новые динамические возможности. Уже в работе возможность запуска новых процессов, возможность динамически устанавливать каналы связи между этими процессами. Несмотря на то, что политики и домены безопасности описываются все еще статически, у политик могут быть состояния, словари для хранения состояний, конечные автоматы, что позволяет говорить об их динамичности. Со временем такие политики ведут себя по-разному и могут реагировать на манифесты приложений или пользовательский ввод.
Является ли KasperskyOS закрытой в плане допуска разработчиков к ней? Насколько просто будет любителям поковырять саму ОС и/или писать под нее свои хелловорды?
Наша система KasperskyOS CE SDK открыта, а сообщество разработчиков, работающих с ней, активно развивается, поэтому заходите на специальную страницу, скачивайте SDK, документацию, изучайте и включайтесь в проекты, а мы будем вам в этом помогать.
Планируется ли открывать исходный код ОС для возможности его свободного исследования всеми желающими на предмет поиска уязвимостей?
Сейчас этот вопрос обсуждается в руководстве «Лаборатории Касперского».
Можем ли мы в KasperskyOS использовать callback?
Несмотря что IPC в KasperskyOS синхронен, есть запрос и ждем на него ответ и пока ждем, ничего в потоке не сделаем. Однако, есть возможность имитировать callback, что, как правило, делается через длительный запрос. Спросили — и висим до тех пор, пока не захотим получить какой-то обратный вызов. Так делать можно, но в нашем примере с диодом мы этим не пользовались.
Есть ли в состав KasperskyOS открытые примеры интеграции драйверов и прикладных программ, изначально предназначенных для Linux?
С точки зрения прикладных программ – да, регулярно этим занимаемся и POSIX-совместимость этому сильно помогает. Что касается драйверов, в KasperskyOS нет слоя совместимости с Linuх и при создании драйверов необходимо работать с собственными API.
Есть ли в KasperskyOS аналог утилиты ipconfig? Планируется ли в дальнейшем создание чего-то подобного? Или какие есть альтернативные способы узнать текущие соединения, настроить их?
В примерах, включенных в KasperskyOS SDK Community Edition, для настройки сетевых интерфейсов используется сущность dhcpcd, поставляемая в комплекте с SDK. Также имеется возможность работать с сетевыми интерфейсами напрямую из кода C/C++.
Могли бы Вы привести пример, как можно использовать сущность dhcpcd для настройки сетевых интерфейсов?
Как использовать dhcpcd для настройки сетей можно посмотреть в нескольких примерах, поставляемых с SDK, например, в multi_vfs_dhcpcd. Параметры сетей указываются в файле /etc/dhcpcd.conf, но путь может быть переопределен с помощью аргументов командной строки для сущности dhcpcd, устанавливаемых в сущности Env.
В документации на KasperskyOS v1.0 на стр.32 написано, что «Компонент VFS можно использовать, как напрямую (путем статической линковки), так и через IPC (как отдельную сущность)». Правильно ли я понимаю, что имеется в виду, что в случае статической линковки и работы с файлами предлагается драйвер блочного устройства и модуль файловой системы вкомпилировать прямо в прикладную программу?
На данный момент драйвер блочного устройства всегда запускается отдельным процессом. Поэтому прикладную программу предлагается компилировать только c библиотеками VFS и реализацией требуемых файловых систем. Именно так устроен пример embedded_vfs.
Статическая линковка с используемым компонентом удобна для отладки, т.к. все работает в одном адресном пространстве. Также можно рассчитывать на более быструю обработку вызовов, т.к. нет временных затрат на IPC и работу KSM-модуля. Однако с точки зрения безопасности всегда рекомендуется использовать компонент по IPC, в виде отдельного процесса.
Подписывайтесь на каналы нашего сообщества в соцсетях:
