Fuchsia позиционируется как ОС общего назначения. Там, где в ней сталкивается, например, безопасность и производительность побеждает производительность. В отличие от KasperskyOS, Fuchsia имеет большую поверхность атаки – в ней много системных вызовов. Кроме того, Fuchsia не имеет встроенного монитора обращений в стиле FLASK (даже в Linux он есть, см. SELinux, AppArmor и т.п.). Но у KasperskyOS и Fuchsiaесть и общие черты: обе системы микроядерные, обе используют OCAP (современная дискреционная модель распространения прав на ресурсы между субъектами), обе похоже реализуют подход к разделению хранилищ, обе по умолчанию не оперируют понятием «UNIX-пользователь»

Во-первых, MacOS не является закрытой системой, это сертифицированный UNIX, наследие NextStep. Для нее можно разрабатывать свои приложения.
Во-вторых, внутри KasperskyOS есть частичная поддержка POSIX, соответственно на нее вполне можно портировать сторонние приложения (за некоторым исключением).

KasperskyOS Community Edition не устанавливается поверх Debian. Поверх Debian устанавливается только SDK для сборки образа, с которого потом будет загружаться целевая машина.

Технически для того чтобы иметь такую богатую функциональность, как у Windows, ОС должна стать динамической. Например, в ней должна быть возможность подключать и отключать оборудование «на лету», устанавливать приложения, запускать и останавливать сервисы. Мы сейчас работаем в этом направлении.

Сегодня мы ведем исследования разработки по адаптации KasperskyOS для работы на профессиональных мобильных устройствах. Это могут быть корпоративные коммуникаторы (например, для ритейла или логистики) или специализированные устройств (в том числе для промышленности и топливно-энергетического сектора). Речь о создании смартфона для массового B2С-сегмента пока не идет.

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

Если коротко, то большая часть проблем, связанных с быстродействием, которые существовали у микроядерных ОС первого поколения, в микроядерных ОС второго поколения решена. Это удалось сделать благодаря переходу от асинхронных IPC к синхронным. KasperskyOS относится ко второму поколению, поэтому ее быстродействие находится на хорошем уровне.

Наша ОС предназначена для использования в интернете вещей и управлении технологическими процессами в отраслях с высокими требованиями к кибербезопасности. Это, например, промышленность, энергетика, государственные учреждения, транспортная инфраструктура. Если говорить про Community Edition, то сейчас она прежде всего направлена на рынок встраиваемых систем (embedded), работающих без GUI (или с использованием локального GUI).

На сегодняшний день KasperskyOS сама по себе с электронными подписями не работает и к СКЗИ не относится. В рамках решения KSRW USB-ключи с электронной подписью, вставленные в разъемы тонкого клиента, пробрасываются на сервер и обрабатываются там.

Опыта внедрения в продукты в составе АСУ ТП на сегодняшний день нет. Шлюзы интернета вещей (например, KISG 1000) используются для трансфера промышленных данных в ИТ-среду. Эта функциональность в целом отличается от функциональности АСУ ТП, но может дополнять и расширять ее.

Пока мы не знаем ни одного аппаратного решения, которое реализовывало бы минимум из SELinux. Если бы оно появилось, было бы интересно посмотреть. Плюс стыковка его с ОС должна выполняться с использованием драйвера, который должен быть доверенным и т.п. В случае появления такого, будем учиться его использовать.

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

Серебряной пули нет — доверенные компоненты необходимо тщательно проверять, там отставание возможно, но и внешних зависимостей должно быть качественно меньше (в идеале вообще без них). А для недоверенной кодовой базы компрометация — нормальное явление. За счет декомпозиции и политик безопасности такие проблемы by design не должны приводить к катастрофическим последствиям, поэтому можно использовать самые свежие версии библиотек, если они проходят функциональные тесты.

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

Ядро KasperskyOS не переиспользует код других операционных систем. Модель безопасности (не обязательно мандатная) задается разработчиком при сборке системы и может быть настроена под нужды конкретного проекта.

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

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

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

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

Архитектура KasperskyOS предполагает, что драйверы исполняются на пользовательском уровне, а не на уровне ядра. На уровне ядра работают только доверенные компоненты, верифицированные «Лабораторией Касперского». Физическое разграничение процессов пользовательского уровня от доступа друг к другу реализовано с использованием MMU.

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

Все упомянутые вами направления выглядят релевантно. На сегодняшнем горизонте один из сложных технических вызовов — это создать обладающую кибериммунитетом систему с богатой функциональностью. Например, специализированное мобильное устройство. Сложность в том, что для этого нужно сделать систему более динамической, например иметь возможность подключать и отключать оборудование «на лету». Значимость информационных технологий для жизни человечества такова, что потребность в доверенной основе для любого применения (в быту, в индустриальной среде, на транспорте и далее везде) очевидна. Так что мы уверены, что со временем кибериммунитет будет проникать во все большее количество сфер и индустрий.

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

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

Разработка самого функционального кода практически не отличается от разработки под Linux. Дополнительных усилий требует программирование модуля безопасности. В нашем YouTube-канале есть рассказ про параллельную разработку под Linux и под KasperskyOS.

Такая проблема действительно есть. Если рассматривать каждый процесс как отдельный субъект, сложность возможных схем взаимодействия между ними оказывается колоссальной. Но со времен древних греков существует такой инструмент, как абстракция. От политик, фокусирующихся на конкретных сообщениях и конкретных субъектах, необходимо переходить к субъектно-объектным взаимодействиям и группировке объектов и субъектов по некоторым признакам. Сейчас мы сами сталкиваемся с необходимостью такого смещения фокуса, ведь отслеживание связей всех со всеми отлично работало в простых встраиваемых решениях, совсем другое дело — системы с возможностью установки сторонних приложений, графическим интерфейсом и прочими особенностями систем общего назначения.

Можно, в курсе по разработке под KasperskyOS на Stepik подробно рассказано и показано, как это сделать

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

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

Объем изменений невелик и в основном находится на стыке прикладного и системного уровня.

Загрузочный образ примера hello-world для RPi4b занимает 2,4 МБ. Фактически это ядро плюс один printf.

Если кратко — да, требуется.

Да, конечно.

Из известных нам библиотек, связанных с ML, точно под KasperskyOS портирован OpenCV (в версии для CPU). В ближайших планах «Лаборатории Касперского» работы по ML-пакетам для GPU отсутствуют. Если у вас есть какой-то рабочий проект, обратитесь для совместного обсуждения на электронную почту os@kaspersky.com.

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

Сейчас один из наших R&D-проектов посвящен именно такой реализации realtime-системы, когда одно ядро выполняет полезную работу, а второе занято обеспечением безопасности. Проект в самом разгаре, о результатах говорить пока рано, stay tuned.

Поддержка affinity отсутствует в бесплатной Community Edition v.1.1. В ряде других продуктов на базе KasperskyOS она есть, технических препятствий нет.

В текущей версии ядра коммерческой KasperskyOS (не Community Edition) есть возможность закрепить процесс за процессорным ядром с определенным номером (affinity), если это будет задано разработчиком. Если это явно не задано, sсheduler выберет наиболее свободное ядро.

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

На данный момент этот язык используется для написания компилятора политик безопасности и генераторов кода.

Golang и Rust сейчас являются кандидатами к включению в роадмап. Все зависит от вашей поддержки.

Rust внутри «Лаборатории Касперского используется, но статистика (сколько человек и в каких объемах) не ведется.

Сама программа готова, мы занимаемся поиском площадки с целью запустить bug bounty по ядру KasperskyOS в 2023 году.

В 2022 году мы начали активную работу с вузами. В МАИ уже обучили более 100 студентов работе с KasperskyOS и элементам кибериммунной разработки. В проведенном там ноябрьском хакатоне приняли участие команды из 9 вузов.

В 2023 году мы планируем расширять сотрудничество с вузами. С двумя вузами мы уже договорились о включении занятий по кибериммунному подходу в учебные программы. Мы открыты для взаимодействия. По данному вопросу пишите на cyberimmunity-edu@kaspersky.com.

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

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

У нас получалось запустить KDE 5 Plasma пару лет назад, но проект остановился на этапе исследования. На текущий момент поддержка сторонних DE не планируется.

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

Тестовые бенчмарки (включая kmscube) запускали максимально в 1920х1080. Большее разрешение не тестировали, на данном этапе в этом нет необходимости.

На процессоре Intel, но в целом для virtio-gpu это неважно. Можно запустить хоть на арме, хоть на любой другой архитектуре. На самом деле мы также запускали Q3 нативно на нашем i915 драйвере (intel UHD 600 GPU) и на i.MX6 (vivante GPU). Производительность там еще больше, но virtio-gpu — это, в первую очередь, про отладку и тестирование.

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

В первую очередь TLA+, Event-B, Alloy.

Если вопрос про проверяемые свойства для спецификаций на TLA+, то да, можно сказать, на LTL (с учетом нюансов TLA+, таких как stuttering и др.). Другая часть свойств (инварианты) — просто логические предикаты над состояниями, без темпоральных модальностей.

Для TLC, при проверке очередей, пространства состояний были десятки-сотни миллионов, диаметр был под несколько сотен (примерно до 500). Довольно часто мы упирались в память на машине (128 ГБ). В некоторых случаях решали через проекции (view), иногда помогал Apalache. Сейчас мы собираем небольшой кластер для model-checking (в первую очередь TLC). GPU (swarm model-checking) пока не использовали.

На данный момент мы формализуем не так много требований, как хотелось бы. Там, где формализуем, используем чаще всего TLA+. Почему? Наиболее удобно во многих случаях для спецификации и верификации поведенческих свойств. На втором месте Alloy. Alloy и TLA+ оказались очень удобной связкой на практике. Alloy — структурные свойства и структурная корректность, TLA+ — динамические свойства и корректность поведения.

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

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

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

Вопрос не совсем из области формальных методов, но близко. Если имеются в виду санитайзеры и подобное — то да, используются те, что есть в Сlang/GCC. Кроме тех, что неприменимы для ядра в силу различных причин, например TSAN. Если речь про автоматический поиск разных инвариантов времени выполнения и подобное — то пока нет, такое мы не используем.

KasperskyOS — это проприетарная операционная система, и планов по превращению ее в проект в рамках open source лицензирования нет.

Если брать Community Edition — ядро и ряд критичных компонентов поставляются в скомпилированном виде, менее важные поставляются в исходных кодах. Состав образа ОС (помимо обязательной части: ядра, модуля безопасности) определяется пользователем при помощи CMake-описаний.

Мы движемся в этом направлении. В отсутствие популярных отечественных площадок для размещения source code сейчас мы ориентируемся на GitHub.

На сегодняшний день такого роадмапа нет. Список пакетов open source к портированию сейчас определяется исходя из запросов наших партнеров и собственных потребностей команды. Если у вас есть какие-то собственные идеи, вы можете предложить их на нашем форуме https://kas.pr/kosforum

В рамках реализации поддержки платформы, естественно, пишутся или портируются необходимые драйвера на компоненты. Соответственно, на аналогичных платах компоненты подхватятся автоматом. Если у вас есть какой-то конкретный проект, связанный с этой платой, обратитесь по адресу os@kaspersky.com для совместного анализа недостающих компонентов.

Эта плата пригодна для реализации достаточно широкого спектра задач, связанных со вводом/выводом цифровых сигналов и обменом данными по сети, реализации каких-то функций управления с веб-интерфейсом. Все зависит от вашей фантазии!

Про проект Repka Pi мы в курсе, однако на начало декабря 2022 г. эта плата публично не доступна. Безусловно, мы готовы сотрудничать с отечественными поставщиками устройств и плат на обоюдно выгодных условиях.

Поддержка устройств USB HID на портах USB 3.0 появилась в KasperskyOS CE 1.1, релиз которой состоялся в октябре 2022 года.

Обратиться к устройству через аппаратные ресурсы из прикладной программы можно уже сейчас (например, https://support.kaspersky.ru/help/KCE/1.1/ru-RU/libkos_ports.htm), однако для написания полноценного драйвера необходимы манипуляции с ядром. В 2023 году мы планируем выпуск специального фреймворка для упрощения разработки драйверов и соответствующего учебного курса.