Vladimir Malygin

Добрый день. Мы постоянно расширяем поддержку аппаратных платформ, в том числе работаем и с отечетсвенными производителями. Проголосуйте за конкретные платформы на нашей продуктовой странице https://kas.pr/kosfeatures , или если у вас есть конкретные предложения в рамках своих проектов напишите нам и мы будем рады обсудить с вами формы сотрудничества и поддержки. А пока предлагаем вам поработать с нашей публичной SDK KasperskyOS Community Edition, которую можете потестировать в QEMU или на Raspberry Pi.

На данный момент драйвер блочного устройства всегда запускается отдельным процессом. Поэтому в прикладную программу предлагается вкомпилировать только библиотеки VFS и реализации требуемых файловых систем. Именно так устроен пример embedded_vfs. Статическая линковка с используемым компонентом удобна для отладки, т.к. всё работает в одном адресном пространстве. Также можно рассчитывать на более быструю обработку вызовов, т.к. нет временных затрат на IPC и работу KSM-модуля. Однако с точки зрения безопасности всегда рекомендуется использовать компонент по IPC, в виде отдельного процесса.

Развертывание KasperskyOS Community Edition в docker не накладывает ограничений на формирование образа файловой системы в KOS CE решении.

Чтобы получить список всех блочных устройств, которые доступны сущности, она должна позвать API BlkDevEnumPorts. API зовется в цикле, пока не будет возвращен код BLKDEV_ENOENT. char portName[256] = { 0 }; do { rc = BlkDevEnumPorts(0, sizeof(portName), portName); if (rc == BLKDEV_EOK) { printf("Found port %s\n", portName); } } while (rc != BLKDEV_ENOENT); Cуществует функция BlkDevLookup, позволяющая найти блочное устройство, соответствующее определенному паттерну (например, по GUID партиции). Что касается паттерна того, как будет называться какое устройство — на текущий момент это зависит от драйвера, при регистрации устройств каждый драйвер сам назначает имя.

Да, есть. Если у вас имеется конкретный проект, то напишите нам о нем и совместно поищем оптимальное решение для вашей задачи, вплоть до повышения приоритета разработки под Risc-V.

Реальный доступ к файлу в этой схеме будет происходить только внутри VFS. То есть, будет 2 связи: A <-> VFS и B <-> VFS . Дальнейшие транзитивные связи VFS к blkdev и pcie тут опускаю — это зависит от архитектуры. Каждый из перечисленных вызовов — отдельное IPC. Возможно сделать так, что в A будет влинкован VFS и, таким образом, A будет полноценным VFS-ом и для своего клиентского кода и для сущности B. Тогда будет только 1 связь A <-> B. В этом случае, все вызовы в А будут локальными вызовами, без IPC, а в B будут уходить через IPC к A.

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

В KasperskyOS пока нет четкого соглашения по иерархии каталогов, все сильно зависит от конкретного продукта, разработанного на ее основе. «/c» — произвольная точка монтирования.

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

Примеры использования dhcpcd для настройки сетей есть в нескольких примерах, поставляемых с SDK, например, в multi_vfs_dhcpcd. Параметры сетей указываются в файле /etc/dhcpcd.conf, но путь может быть переопределен с помощью аргументов командной строки для сущности Dhcpcd, устанавливаемых в сущности Env.

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

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

Шифрование IPC сообщений без модификации прикладного кода в KasperskyOS невозможно. Конфиденциальность передаваемых в сообщениях данных обеспечивается аппаратной изоляцией процессов друг от друга. Шифрование сообщений в рамках одной физической системы выглядит непрактичным и несет большие накладные расходы.

С точки зрения прикладных программ – да, регулярно этим занимаемся и POSIX совместимость этому сильно помогает. Что касается драйверов в KasperskyOS нет слоя совместимости с Linuх и при создании драйверов необходимо работать со собственными API.

KasperskyOS Community Edition предоставляет единственный метод отладки, с использованием GDB-stub, встроенного в виртуальную машину QEMU. Этот метод отладки весьма ограничен. Например, QEMU GDB-stub не знает ничего о процессах и потоках гостевой операционной системы. В ядре KasperskyOS уже поддержан полноценный GDB-stub. Включение его в поставку KasperskyOS Community Edition обсуждается. Если вы работаете со своим проектом на KasperskyOS, то опишите проект и вставшие задачи отладки, и мы найдем решение.

Сейчас этот вопрос обсуждается в руководстве Лаборатории Касперского.

В KasperskyOS изначально не предполагается понятий пользователей и групп. Эти понятия не требовались для большинства применений, на которые ориентировалась система. В большинстве существующих применений, где важно разделять доступ к файлам с разным уровнем конфиденциальности, мы применяем подход похожий на современные мобильные платформы: процессы запускаются в "песочнице" и видят только подмножество всей доступной файловой системы. Это достигается за счет запуска нескольких копий VFS и правильного построения связей между сущностями в системе. Прорабатывается возможность добавления в систему пользователей и сессий, с привязанными к ним контекстами безопасности. Это позволит распределять права доступа к объектам в провайдерах ресурсов (например VFS), используя произвольные политики, основанные на DAC, MAC, RBAC и т.д. Такую возможность легко добавить в систему, используя уже реализованные механизмы: security interfaces и OCAP. В VFS сейчас присутствует ограниченная поддержка ACL, но только для того, чтобы сформировать нужные права для Linux при кросс-монтировании.

В данном случае /c — произвольная точка монтирования. Какой-либо строго зафиксированной схемы расположения каталогов в KasperskyOS нет. Все зависит от конкретного решения.

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

Прецеденты реализации у одного из наших партнёров есть, технических проблем в подобных задачах нет. Данный протокол - не уровня сети, а уровня приложения, препятствий к его реализации пользователями в Kaspersky OS нет.

Для этого процесс-сервер VFS должен быть явно доступен всем процессам-клиентам через EDL/CDL/IDL-описания. Политики безопасности могут быть описаны для каждой пары клиент-сервер раздельно, либо с использованием regex-выражений. Детали можно изучить в примерах документации - https://support.kaspersky.com/help/KCE/1.0/ru-RU/separate_storage_example.htm

KasperskyOS — операционная система для продуктов и решений с повышенными требованиями к кибербезопасности, она применима там, где классические подходы к безопасности IT-систем недостаточно эффективны. Для защиты интернета вещей у нас есть линейка кибериммунных шлюзов Kaspersky IoT Secure Gateway 100/1000. Тонкие клиенты на базе KasperskyOS входят в решение для создания инфраструктуры удаленных рабочих мест Kaspersky Secure Remote Workspace, сейчас они доступны и для пилотирования, и для приобретения. Мы также ведем ряд исследовательских проектов, где видим перспективы для KasperskyOS. Это, например, создание доверенной среды исполнения на базе ARM TrustZone. Для применения в системах промышленной автоматизации, энергетики и защиты умных автомобилей мы двигаемся в направлении того, чтобы сделать KasperskyOS системой реального времени. Также у нас есть исследовательский проект по адаптации операционной системы под экранные мобильные устройства. Главное преимущество наших решений по сравнению с существующими на рынке — это кибериммунный подход. Мы считаем, что когда-нибудь IT-инфраструктура — миллиарды умных устройств, индустриальных систем контроля, офисных сетей, компьютеров, носимых девайсов, космических станций и т.д. — в значительной мере станет кибериммунной, защищенной еще на этапе проектирования и разработки, и наложенные средства безопасности (например, антивирусы) больше не понадобятся. Для этого потребуется много времени, но мы и наши технологические партнеры прилагаем все силы для того, чтобы безопасное будущее стало реальностью как можно скорее.

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

Как международная компания мы активно развиваем сотрудничество с зарубежными партнерами. Например, недавно мы интегрировали в нашу платформу для умных автомобилей Kaspersky Automotive Adaptive Platform технологии беспроводных обновлений от американской компании Airbiquity. Кибериммунный шлюз для промышленного интернета вещей KISG 100 построен на базе аппаратной платформы Siemens и интегрирован с цифровой платформой Siemens MindSphere. Наша операционная система работает на тонких клиентах компании TONK – технологического и бизнес-партнера китайской компании Fujian Centerm Information, которая входит в тройку крупнейших мировых производителей тонких клиентов. Экосистема наших партнеров постоянно развивается и растет, прямо сейчас в проработке находится еще несколько компаний, выпускающих и программное обеспечение, и программно-аппаратные комплексы. Также мы тесно сотрудничаем с международными аналитическими агентствами. Например, вместе с европейской компанией ARC Advisory мы продвигаем кибериммунный подход к построению информационных систем на мировом рынке.

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