Часто задаваемые вопросы

Отвечаем на популярные вопросы о KasperskyOS и KasperskyOS Community Edition
KasperskyOS
Что такое KasperskyOS? Это какой-то Linux?

Ядро KasperskyOS является собственной разработкой «Лаборатории Касперского» и не основывается на каком-либо существующем проекте (Linux или каком-то еще).

Зачем нужна KasperskyOS? 

KasperskyOS — микроядерная операционная система, созданная с нуля в «Лаборатории Касперского». Благодаря принципам, заложенным в ее архитектуру, на основе нашей ОС можно создавать решения, обладающие кибериммунитетом — встроенной защищенностью от подавляющего большинства видов кибератак. Это очень важно для цифровых инфраструктур, где необходим высокий уровень гарантий безопасности.

Что нового вы предлагаете в KasperskyOS? 

KasperskyOS — первая операционная система, с помощью которой можно наделять IT-продукты кибериммунитетом. Такие продукты практически невозможно взломать, а подавляющее большинство типов атак на кибериммунную систему не может повлиять на выполнение ею критических функций. Решениям, построенным на KasperskyOS, не нужны дополнительные средства защиты — все необходимое уже есть внутри системы.

Как работает ваша ОС? 

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

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

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

Что делает KasperskyOS безопасной? 

Исходная безопасность KasperskyOS заложена в ее архитектуре и философии.

Так, запускаться и работать может только то, что напрямую разрешено администраторами системы и разработчиками приложений. Уже на этапе проектирования IT-решения на KasperskyOS задаются политики безопасности, которые описывают каждое разрешенное действие.

В микроядре KasperskyOS всего около сотни тысяч строк кода — поверхность атаки минимальна. А за работоспособность в любых ситуациях отвечает строгая изоляция системных компонентов: даже если в каком-то из них произойдет сбой, ОС продолжит выполнять свои критические функции.

KasperskyOS разработана в соответствии с архитектурами MILS и FLASK с добавлением собственных технологий безопасности «Лаборатории Касперского».

Возможно ли взломать вашу ОС? 

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

То есть любое решение на KasperskyOS иммунно? 

Чтобы наделить продукт на основе KasperskyOS кибериммунитетом, необходимо строго следовать специальной методологии «Лаборатории Касперского».

Кибериммунными могут считаться только исходно безопасные (secure-by-design) IT-системы. Если вкратце, то, чтобы их создать, с самого начала разработки нужно обеспечить следующее:

  • Описание целей и предположений безопасности
  • Средства изоляции доменов безопасности и независимый контроль всех их взаимодействий
  • Гарантии достижения целей безопасности во всех возможных сценариях использования системы, включая описанные предположения (за исключением случаев, когда доверенная вычислительная база решения оказывается скомпрометирована)
  • Гарантии надежности всей доверенной вычислительной базы решения, отвечающие предполагаемому классу безопасности
Собирает ли KasperskyOS какие-либо данные? 

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

Ни один компонент системы не может сохранять и отправлять данные, если такая возможность не прописана для него в политиках.

В чем преимущество KasperskyOS перед ОС на базе ядра Linux?

У них разное позиционирование. Linux — это универсальная система для серверов, десктопов, мобильных устройств и т.д. Она хорошо адаптируется под разные применения. Тем не менее системных вызовов в ней так много, а модули внутри ядра имеют такую сложную цепочку связей, что мы не можем быть уверены в надежности проверки всех взаимодействий встроенными в ядро средствами безопасности, такими как SELinux. Каждый год находятся уязвимости или места, где те или иные политики не проверяются или не применяются к какому-либо системному вызову. А самое главное, если кто-то взломает монолитное ядро, он получит максимальные привилегии. В KasperskyOS же многие системные сервисы вынесены в пространство пользователя. Их взлом не даст злоумышеннику привелегий уровня ядра ОС.

В чем преимущество перед Astra Linux?

Не совсем корректно сравнивать KasperskyOS и Astra Linux. Astra Linux – операционная система общего назначения, в то время как мы делаем продукты на базе нашей ОС с четко определенными сценариями использования, для которых возможно построить модель угроз и создать кибериммунный продукт, используя шаги, про которые рассказывалось в докладе Сергея Яковлева «Устройство безопасности в KasperskyOS».

Если вопрос о том, в чем преимущество решений, построенных на KasperskyOS перед Astra Linux, то рекомендуем ознакомиться с докладами Сергея Рогачева про микроядра или Максима Донцова про secure by design.

Решения и направления
Можно ли уже сегодня приобрести у вас кибериммунные продукты? 

Да, во-первых, это линейка Kaspersky IoT Infrastructure Security для интернета вещей, ключевой элемент  которой — кибериммунные шлюзы, незаменимые устройства для современного бизнеса, проходящего через цифровую трансформацию 4.0. Сейчас в продаже доступны Kaspersky IoT Secure Gateway (KISG) 100 и KISG 1000. Кстати, KISG 100 признали одной из лучших в мире разработок 2020 года на 7-й Всемирной конференции по вопросам интернета в китайском Учжэне. Развитием и продажами шлюзов занимается дочерняя компания «Лаборатории Касперского», НПО «Адаптивные промышленные технологии» (Апротех).

Во-вторых, это решение Kaspersky Secure Remote Workspace, включающее в себя ПО для тонких клиентов — похожих на компьютеры пользовательских терминалов для подключения к корпоративной инфраструктуре виртуальных рабочих столов.

Также для прототипирования доступен SDK Kaspersky Automotive Adaptive Platform для разработки электронных блоков автомобилей.

Где может использоваться KasperskyOS? 

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

Среди устройств, которые уже работают на KasperskyOS, — тонкий клиент, ключевая часть решения Kaspersky Secure Remote Workspace, и шлюзы для интернета вещей, которые помогают создавать защищенные IoT-сети и проводить цифровую трансформацию промышленности. А в 2020 году решение Kaspersky Automotive Adaptive Platform было интегрировано в автомобильный ЭБУ.

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

Будет ли KasperskyOS доступна для В2С? 

KasperskyOS — специализированная операционная система. Пока что на ее основе можно создавать только решения для встроенных IT-систем с необходимым для конкретных заказчиков функционалом.

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

Как вы планируете поддерживать различные устройства и софт?

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

Регионы
В каких регионах будет продаваться KasperskyOS? 

Шлюзы Kaspersky IoT Secure Gateway 100 и 1000 уже доступны к приобретению в России и Беларуси. В Европе их продажи ведутся через испанского дистрибьютора V-Valley. В этом году планируется выход на рынки регионов МЕТА и АРАС. А еще прорабатываются пилотные проекты в Латинской Америке.

Дополнительно
Существуют ли ОС с аналогичной функциональностью?

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

Нужен ли антивирус, если стоит ваша ОС?

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

Именно поэтому мы спроектировали нашу ОС так, чтобы ее не нужно было дополнять наложенными средствами защиты. Ее архитектура не позволяет злоумышленникам влиять на работу системы даже в случае компрометации какого-либо компонента.

Не нашли ответ на свой вопрос?
Задать вопрос
Безопасность и кибериммунитет
Как подтверждается безопасность KasperskyOS?

Собственный код KasperskyOS постоянно проходит различное тестирование, включая фаззинг. Для ряда наиболее критичных компонентов выполняется формальная верификация и проверка моделей безопасности. Код подвергается статическому и динамическому анализу. Регулярно проводятся пентесты. Запланировано проведение Bug Bounty.

Кибериммунитет как концепция. Можно ли более детально пояснить, что подразумевается под этим понятием? Помимо разграничения прав доступа (что реализовано, наверное, уже практически во всех широко распространенных ОС), что еще закладывается в это понятие?

Кибериммунитет — это, прежде всего, подход, целью которого является создание системы, безопасной в силу дизайна (Secure by Design). Подобные системы разительно отличаются от обычных систем в защищенном исполнении тем, что они обладают минимальной поверхностью атаки не за счет использования наложенных средств защиты, а за счет правильно спроектированной архитектуры. Кибериммунные системы более устойчивы к взлому (компрометации), а в случае успешной атаки значительно усложняют ее распространение.

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

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

Архитектор решения определяет ilities, которые необходимо поддержать на уровне решения, например, конфиденциальность (confidentiality), доступность (availability) и другие. Для каждого подобного свойства должен быть системный компонент, который его обеспечивает, — уже реализованный в KasperskyOS (security pattern) или требующий реализации.

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

В результате мы получаем архитектуру, которая значительно затрудняет распространение атаки в системе и минимизирует вероятность взлома доверенных компонентов (тех, от которых зависит безопасность, реализация ilities).

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

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

Можно ли скомпрометировать монитор безопасности и как скоро это обнаружится? Как этому противодействует KasperskyOS?

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

Первое — код монитора написан на декларативном языке и монитор генерируется, а не пишется руками. Какое-то количество ошибок отпадает из-за этого.

Второе — сгенерированный монитор безопасности мы можем хорошо протестировать, особенно учитывая, что в процессе генерации из промежуточного представления можно создавать не только код монитора, но и некоторые модели. Они позволяют генерировать стопроцентное тестовое покрытие там, где это возможно, а там, где это невозможно, проверять некоторые части с помощью model checking.

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

Почему в KasperskyOS не поддерживается fork()?

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

Имеются ли в KasperskyOS средства защиты кода от изменения? Защита firmware?

У нас есть много средств для контроля исполнения кода. Ситуация, в которой злоумышленник может перезаписать код самой ОС или firmware нелегальна даже в обычных операционных системах, а уж у нас тем более. Защита от этого у нас на хорошем уровне в силу архитектурных подходов, о которых мы не раз рассказывали.

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

OCap может контролировать и системные ресурсы, и ресурсы пространства пользователя. Системные ресурсы – это регионы памяти, прерывания, порты ввода-вывода. Даже задачи и потоки у нас представлены объектами системных ресурсов, а значит ими можно безопасно управлять.

Объекты пользователя тоже могут быть представлены OCap. У нас есть специальный системный вызов (KnHandleCreateUserObject), которому нужно предоставить пользовательский контекст – какой-то указатель в адресном пространстве сервиса (провайдера ресурса), этот контекст сохраняется в специальный объект ядра.

Затем мы можем получить родительский хэндл на этот объект и дальше его передавать. Когда происходит обратная передача провайдеру ресурса хэндла на его объект, он узнает соответствующий указатель и маску прав доступа, с которой к нему обращаются. Он может сам проверить эту маску прав и разрешить или запретить доступ к этому пользовательскому объекту. Также мы можем написать политику KSS, которая способна залезть внутрь сообщения, посмотреть, что за SID находится за этим хэндлом, какая маска прав и тоже разрешить или запретить доступ. Так что да, все объекты в системе можно сделать OСap-совместимыми.

На основании чего сделан вывод, что выбранная модель KSS + PSL является безопасной? При генерации Си-кода происходит ли проверка тупиковых ситуаций?

У нас используется набор известных моделей безопасности и по некоторым из них приходилось доказывать, что в рамках нашей системы их работа корректна. На эту тему была публикация Владимира Буренкова. Может быть 100% гарантию мы можем дать не везде, но мы работаем над этим. В частности, привносим в разработку формальные методы. Например, в разработке монитора безопасности частично применяется такой инструмент, как K framework. Он позволяет описать не только синтаксическую, но и семантическую часть языка промежуточного представления. Зная семантику, можно проводить символьное исполнение, доказывать некоторые утверждения о политике.

Если драйвер использует DMA, как обеспечить кибериммунность?

Возможны два варианта ответа – все зависит от доступного оборудования.

Если железо поддерживает IOMMU, то вопрос изоляции отпадает автоматически: наша ОС изолирует адресные пространства процессов не только со стороны CPU, но и со стороны устройств.

Если железо не поддерживает IOMMU, решение нужно строить специальным образом. Мы выделяем часть драйвера, управляющую DMA-контроллером устройства, в изолированную сущность, хорошо проверяем ее на отсутствие уязвимостей и называем доверенным компонентом. Далее мы пишем политики взаимодействия так, чтобы к доверенному компоненту обращались только авторизованные компоненты и делали это лишь установленным образом. В этом случае ни один процесс в системе не может напрямую запрограммировать контроллер DMA некорректным образом, это может сделать только доверенный драйвер. А этот драйвер хорошо проверен и у нас есть определенная степень уверенности, что его трудно взломать.

Как на безопасность решения на базе KasperskyOS влияют аппаратные уязвимости (типа Meltdown и Spectre)?

Проектируя продукты на KasperskyOS, мы рассматриваем аппаратуру доверенной. При этом в случае нашей системы потенциальный вред, который могут нанести Meltdown, Spectre и им подобные, минимален.

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

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

Не совсем понятно насчет динамического добавления объектов ядра. Означает ли это динамическую реконфигурацию политик безопасности?

Появление новых объектов ядра не требует изменения политик безопасности. Большинство политик безопасности оперируют понятиями субъектов и объектов. По запросу какого-либо процесса, если политика не запрещает процессу этого класса подобное действие, может быть создан объект ядра, например для выделяемого региона памяти, порта ввода-вывода или DMA-региона.

Каждому такому объекту будет назначен уникальный идентификатор и монитор безопасности узнает о каждом новом объекте. Передача прав на работу с любым подобным объектом видна монитору безопасности и политика может ограничивать передачу части прав между определенными субъектами.

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

Что с безопасностью физического доступа? Можно ли политиками безопасности запретить исполнение с USB или с недоверенных устройств?

Политики безопасности позволяют разрешить сущностям только определенные методы. В случае именно с USB надо смотреть на конкретные сценарии использования. C RDP-клиентом мы поддерживаем только класс токенов.  Есть работа с USB-накопителями, но на уровне нашего продукта (тонкого клиента) не происходит выполнения какого-либо кода, все связанное с USB мы отдаем дальше, виртуальным рабочим столам.

Производительность и многоядерные системы
Является ли KasperskyOS системой жесткого реального времени? И гарантирует ли она детерминизм по времени выполнения системных вызовов?

KasperskyOS не является системой жесткого реального времени. Мы двигаемся в направлении поддержки soft-realtime: уже адаптировали планировщик, в нем появился соответствующий класс планирования. Впереди нас ждет много работы по переделке примитивов синхронизации, борьбе с инверсией приоритетов, переделке некоторых алгоритмов и структур данных, дабы добиться константности времени исполнения.

Насколько быстро работает KasperskyOS по сравнению с аналогичными ОС?

Вопрос неоднозначный. Производительность микроядерных систем традиционно оценивают по производительности механизма IPC.

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

Пока мы не соревнуемся в производительности с Linux и другими массовыми ОС, здесь они точно выигрывают. Но за счет разумных компромиссов KasperskyOS обеспечивает приемлемую производительность, позволяющую делать реальные безопасные продукты.

Насколько можно понять, в текущей реализации «узким горлышком» продуктов на основе KasperskyOS является KSS и синхронный механизм IPC. Единственная возможность ускорить систему — уменьшить число вызовов за счет увеличения буферов сообщений?

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

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

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

Доступ именно к сервисам ядра не приводит к сериализации: IPC на специальный ядерный endpoint выглядит для монитора безопасности как обычный IPC, но реализован в ядре иначе. Никакой «посылки» сообщения в этом случае не происходит. Если два потока на разных ядрах одновременно запросят у ядра какой-либо сервис, то они будут обслужены ровно также, как если бы они совершали какие-то системные вызовы в типовой монолитной ОС. Да, потоки могут засыпать на примитивах синхронизации внутри ядра, но в большинстве случаев эти запросы будут обрабатываться параллельно.

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

Драйверы
Как организовано взаимодействие драйверов и ядра?

Типичный драйвер управляет устройством через запись/чтение портов ввода вывода (MMIO/PIO). Также он взаимодействует с устройством посредством DMA. Устройство уведомляет драйвер о выполнении запросов и событиях через отправку прерываний. Таким образом от ядра драйверу необходима служба, которая позволяла бы получить доступ к портам ввода-вывода, выделять DMA-буферы и обрабатывать прерывания. Все эти возможности предоставляются IO-службой ядра.

Ожидание прерываний в драйвере реализовано аналогично вызову Call при IPC: поток обработки прерывания из драйвера совершает вызов Call в ядро и засыпает в ожидании прерывания. Когда соответствующее прерывание получено ядром – ядро будит соответствующий поток, спящий на Call, таким образом прерывание может быть обработано. Далее поток снова засыпает в ожидании.

Доступ к службам ядра является привилегированным и должен быть разрешен только драйверам и другим критическим компонентам архитектуры. Реализация доступа к службам ядра через механизм IPC позволяет использовать все возможные технологии Kaspersky Security Module для запрета/ограничения доступа программы к службам ядра.

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

Портирование драйверов у нас скорее исключение, а не основная практика. Чаще мы стараемся писать их самостоятельно. Тем не менее драйверы мы портируем и сама структура нашего драйверного фреймворка (исполнение в пространстве пользователя, выделение драйверов в отдельные процессы, взаимодействие между ними по IPC) дает некоторые гарантии. Если в драйвере окажется уязвимость, она не приведет к компрометации всего устройства, к нарушению целей безопасности. Это возможно как раз благодаря изоляции драйверов, политикам, которые мы специально прописываем для каждого решения, использованию IOMMU.

Как виртуализировать драйвер устройства для гостевой ОС и есть ли вообще гипервизор?

Гипервизор есть: микроядро содержит в себе модуль, который называется HV. В HV мы реализовали привилегированную часть гипервизора, которая напрямую обращается к железу, расширениям виртуализации, таким как VMX. Гипервизор работает не только на Intel, фрагментарно поддерживается и ARMv8. В пространстве пользователя есть реализация виртуальной машины, имитирующей типовое железо, мы называем эту программу VMAPP.

На Intel мы умеем загружать разные гостевые системы: все современные версии Windows (11 не тестировали), дистрибутивы Linux и BSD, любительские системы вроде Haiku и ReactOS.

Виртуальная машина поддерживает набор стандартных устройств x86-совместимого компьютера: чипсет Q35, legacy-контроллеры, сетевую карту E1000, контроллер EHCI, некоторые virtio-устройства.

Типовой сценарий использования – проброс оборудования, поэтому не требуется виртуализации большого набора устройств.

Гипервизор развивается достаточно медленно, потому что пока не пригодился ни в одном из наших продуктовых решений.

Как происходит обновление драйверов? Или совместно с обновлением драйверов будет происходить обновление монитора безопасности?

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

Следите ли вы за развитием и исправлением ошибок в тех драйверах, которые вы портировали? Переносите ли вы это в свои драйверы?

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

Первым шагом исходный код драйвера копируется и коммитится в репозиторий без изменений. Вторым шагом вносятся изменения, необходимые для его работы под KasperskyOS. Такой подход гарантирует, что переход на новые версии драйверов для нас практически бесплатный.

А как прерывания приходят в драйвер?  Через побудку потока драйвера и какой-либо событийный механизм?

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

При наличии синхронного IPC и отдельного класса задач в шедулере, не получится ли, что сбойное устройство заспамит систему и подвесит другие процессы?

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

Есть ли у вас инструменты для отладки драйверов без реального железа?

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

Есть ли руководства по интеграции в состав KasperskyOS драйверов и прикладных программ, изначально предназначенных для Linux?

Руководств по портированию драйверов и приложений из Linux на KasperskyOS нет. Портирование драйверов происходит на основе готовых драйверов и принятой драйверной модели.

Как предполагается реализовывать работу с периферийным и сетевым оборудованием?

Микроядерность предполагает, что драйверы устройств и подсистемы низкого уровня выносятся в изолированные процессы пространства пользователя. Драйверы периферии и сетевых карт реализуются полностью в пространстве пользователя: ошибка (уязвимость) в каком-либо драйвере не может нанести вред ядру операционной системы и другим компонентам. Это же касается сетевого стека, USB. Драйверы для большинства необходимых устройств мы разрабатываем сами, некоторые портируем из ОС с подходящими лицензиями.

KasperskyOS Community Edition
Что такое KasperskyOS Community Edition?

KasperskyOS Community Edition – это комплект для разработки программного обеспечения (далее также SDK), предназначенный для сборки собственного образа KasperskyOS для определенного набора аппаратных платформ. В комплект поставки входят ядро KasperskyOS, инструментарий разработки решений, ряд библиотек, примеры их использования, а также документация. SDK поставляется в виде deb-пакета для Debian GNU/Linux 10 «Buster» и может быть бесплатно скачан по ссылке. В состав образа не входят средства командного интерфейса (консоль, GUI). После установки SDK разворачивается в директории /opt/KasperskyOS-Community-Edition-<version>.

Для чего предназначен KasperskyOS Community Edition?

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

Можно ли использовать KasperskyOS CE для коммерческой разработки?

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

Условия коммерческой лицензии зависят от многих параметров: количества производимых устройств, бизнес-модели (например, фиксированные платежи или роялти или разделение доходов). Также на стоимость могут влиять, если они нужны для проекта, работы со стороны «Лаборатории Касперского». Сюда могут входить, например, поддержка специфичной аппаратной платформы, сервис технической поддержки и обновлений.

Если у вас уже есть предполагаемые детали/параметры проекта, поделитесь с нами, чтобы коллеги могли предложить вам бизнес-модель и рассчитать стоимость.

Даже если такие параметры у вас пока не готовы, «Лаборатория Касперского» заинтересована в поддержке успешных продуктов на KasperskyOS и не выставляет «заградительных» цен на лицензии.

Для чего KasperskyOS Community Edition не может быть применен?

KasperskyOS Community Edition не предназначен для коммерческого применения (то есть перепродаж, в том числе в составе программно-аппаратных комплексов), для этого требуется отдельная лицензия. Для получения условий обратитесь на os@kaspersky.com.

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

Поддержка аппаратуры
Какие аппаратные платформы поддерживаются?

На данный момент KasperskyOS Community Edition работает с Raspberry Pi 4B, а также с виртуальной машиной на базе AArch64 в QEMU. По запросу могут быть подготовлены SDK для x86 и NXP i.MX. В теории KasperskyOS Community Edition может работать и на других платформах с блоком управления памятью (MMU). По поводу остальных платформ просим прислать запросы на os@kaspersky.com.

Какие компоненты платы Raspberry Pi 4B готовы к использованию в настоящее время?

Сетевой стек для Ethernet, работа с SD-картой, работа с GPIO в режиме обычных входов/выходов.

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

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

Сегодня мы с технологическими партнерами выпускаем решения на определенном железе (на базе x86_64, ARMv6/7/8). Если появится необходимость в других аппаратных платформах, мы будем портировать решения на них.

Поддержка нового оборудования – непростая задача. Мы справляемся своими силами: пишем драйверы и BSP, иногда портируем их из других ОС с открытым исходным кодом. Но иногда такая работа может выполняться и нашими партнерами.

Сторонние библиотеки
Какие библиотеки сейчас доступны в составе пакета?

PCRE (регулярные выражения), Civetweb, Boost, mbedTLS, Mosquitto.

Как поддерживаются эти библиотеки?

В настоящее время поддержка этих библиотек лежит на команде разработки KasperskyOS. Нам бы хотелось, чтобы через некоторое время поддержка этих библиотек была передана оригинальным разработчикам или в open-source сообщество.

Есть ли какие-то библиотеки не в составе SDK?

Готовятся к размещению на github.com портированные nginx, php, Node.JS, Samba.

Каким образом разработчик может использовать библиотеки других разработчиков?

Можно использовать как статические, так и динамические библиотеки. Для использования библиотек при сборке решения соответствующую библиотеку нужно указать в зависимостях соответствующего артефакта. Динамические библиотеки поставляются в составе SDK, а также могут быть созданы разработчиком решения на базе KasperskyOS. Работоспособность сторонних динамических библиотек не гарантируется.

Разработка
Какие языки и компиляторы используются при разработке под KasperskyOS?

На данный момент возможна разработка на языках C и C++ с использованием кросс-компиляторов GCC.

Какие IDE сейчас доступны для подготовки кода приложений?

На данный момент рекомендованной средой разработки является VSCode с подсветкой синтаксиса C/C++.

Что вы думаете о применимости языка Rust для разработки компонентов KasperskyOS?

Rust – перспективный язык системного программирования. Он решает многие проблемы языков C и C++, причем достаточно дешево: как и C++ Rust исповедует путь zero-cost абстракций.

Мы присматриваемся к Rust в первую очередь для разработки кода пространства пользователя. В продуктовой разработке готовятся к поддержке Rust в KasperskyOS, чтобы поддержать свежую версию движка Suricata.

Есть поддержка только нативных приложений или есть возможность запуска JIT/интерпретируемых?

Для KasperskyOS мы портировали интерпретатор Lua и виртуальную машину Java. Для нашей системы есть и веб-браузер на базе WebKit, который поддерживает исполнение JavaScript.

Ведется ли обучение программированию под KasperskyOS?

В ближайшее время будет запущен учебный курс на платформе Stepik.

Чем работа с приложениями внутри системы отличается от уже существующей системы flatpack в Linux?

Сторонние приложения, возможность установки которых есть в некоторых сборках KasperskyOS, исполняются в контейнеризированной среде: приложение получает свое собственное изолированное хранилище и виртуальную файловую систему, доступ к возможностям, предоставляемым базовой ОС, дается через capabilities. Такое приложение не может добраться до данных других приложений и напрямую обратиться к драйверам и другим системным сервисам.

Какая парадигма в отношении работы с окружением заложена в KasperskyOS? Имеются ли оглядки на UNIX с идеей «все есть файл» или Plan 9 в плане взаимодействия с сетевым окружением?

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

Файловая система в KasperskyOS – отчуждаемая сущность, можно представить вариант сборки KasperskyOS вовсе без файловой системы. Также возможен вариант системы без POSIX API. Поэтому подходы «все есть файл» из Plan 9 и более традиционных Unix-подобных систем здесь неприменимы.

Разрабатывается ли специализированная файловая система под KasperskyOS или используется сторонняя реализация?

Для KasperskyOS не разрабатывалось специальной in-house файловой системы. Обычно мы портируем открытые реализации файловых систем из ОС с подходящей лицензией, после чего дорабатываем эти реализации, чтобы они удовлетворяли нашим требованиям.

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

В коллекции компонентов KasperskyOS уже есть портированные популярные библиотеки и программы. Основной вектор продуктовой разработки подразумевает создание собственных решений на базе KasperskyOS. Но есть, например, KasperskyOS Community Edition: разработчики этой сборки системы портируют популярные программы и технологии из GNU/Linux, чтобы привлечь разработчиков, знакомых с этими технологиями.

Планируется ли разработка оригинального Desktop Environment для KasperskyOS (в плане использования для Desktop) и на какой графической базе?

В KasperskyOS функционирует простой графический композитор на основе протокола Wayland. Есть наработки по графическому стеку (на основе DRI). Тем не менее, разработки полноценного десктопного решения пока нет в планах.

Open source, лицензирование и сертификация
Используются ли исходные тексты для разработки кода ядра или пользовательского кода из open-source проектов?

Ядро, базовая библиотека libkos, драйверный фреймворк, input-фреймворк и большинство драйверов, которые мы разрабатываем внутри SPD, не содержат заимствованного кода. Но есть некоторые исключения. Например, система конфигурирования ядра, куски RTL (snprintf, rb tree). В файле legal.lst можно посмотреть полный их список. Также заимствованный код встречается у продуктовых команд и команд, занимающихся системными компонентами: VFS, сетевыми стеками. По большей части это код под BSD- и MIT-подобными лицензиями.

Какое у вас покрытие кода тестами для используемых open-source компонентов? Находили ли вы там ошибки?

Да, мы находили и исправляли ошибки в open-source компонентах. Наша цель по покрытию – 100% по функциям и 75% по бранчам. Пока мы этого не достигли, но движемся в этом направлении.

Как лицензируются портированные из Linux драйверы?

Лицензии наследуются.

Будет ли проводиться сертификация ФСТЭК для KasperskyOS? Применима ли она в КИИ 3, 2 и 1 категории?

Да, будем сертифицировать ОС по требованиям ФСТЭК А4. Даты назвать не готовы, следите за анонсами.

Известные проблемы и их решение
При сборке и запуске примеров возникает ошибка запуска QEMU "Could not initialize SDL(x11 not available)".

Причиной является проблема в доступе локального процесса к оконной системе X Window System. Варианты решения:

Если X11 Server установлен – выполнить «xhost local:» (разрешить доступ всех процессов).

Если же X11 Server не установлен, то надо либо установить его, либо добавить флаг -nographic при запуске QEMU: в файле einit/CMakeLists.txt в цель build_kos_qemu_image перед ${ENTITIES} добавить строку QEMU_FLAGS «${QEMU_FLAGS} -nographic -monitor none»

Попытка загрузки SD-карты на Raspberry Pi 4V заканчивается ошибкой "Failed to load kos-image".

Непосредственно после процедуры «Подготовка загрузочной SD-карты» необходимо выполнить процедуру «Запуск примера на Raspberry Pi 4B».

Можно ли запустить примеры для работы с GPIO в KasperskyOS под QEMU?

Примеры GPIO под QEMU не будут корректно выполняться.

Дополнительно
[IoT-шлюзы] Может ли приложение состоять из нескольких сущностей? В каких сценариях это может быть полезно?

Конечно, может. В частности, в продукте с гарантией дата-диода (KISG-100) все приложение может состоять из двух видов сущностей: конвертер входного и выходного протокола. Они могут поставляться разными или одним и тем же разработчиком. Мы поняли, что для гарантии дата-диода невозможно сконцентрировать всю логику обработки протоколов в одной сущности. Мы пришли к тому, что базовое приложение — конвертер протоколов — состоит из двух процессов.

[Тонкий клиент] Какой алгоритм используется для шифрования трафика в RDP-клиенте?

Обычный TLS-уровень. Те же самые алгоритмы, что используются, например, в HTTPS.

[Тонкий клиент] FreeRDP получает расшифрованный протокол от TLS-терминатора. Ядро не контролирует целостность протокола. В чем кибериммунность?

Соединение у нас происходит только к тем серверам, которым мы доверяем. Атаки со стороны RDP-сервера мы не ожидаем. Но если бы ожидали, мы должны были бы более глубоко и полно проделать фаззинг и пентестирование для FreeRDP.

[Тонкий клиент] Какой смысл создавать TLS Terminator как отдельное приложение, через которое идет траффик, а не как библиотеку по работе c TLS? Это выглядит так, что сначала мы сделали защиту, так чтобы весь траффик шифровался, но потом оказалось, что с такой защитой невозможно существовать, поэтому пришлось кастомизировать целое приложение, что нарушает сам первоначальный смысл создания TLS Terminator?

Исходно TLS Terminator — небольшая сущность с одной функциональностью. Такую сущность проще проверить, у нее маленькая поверхность атаки, мы называем ее доверенной. То, что потребовалось создать отдельный экземпляр TLS Terminator, донастроенный под конкретный протокол, не мешает ему обладать теми же свойствами. С другой стороны, встраивание реализации TLS в виде библиотеки значительно увеличивает поверхность атаки и нарушает принципы построения кибериммунного решения.

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

Есть два варианта.

Более сложный: разработчик должен использовать IPC-вызов к серверному компоненту вызываемой библиотеки.

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

Каким образом следует использовать программу VFS, чтобы другие программы в составе решения могли получить доступ к печати в консоль? Существует ли независимый от VFS способ печати в консоль, в частности: fprintf(stderr, "Hello world!\n")?

По умолчанию вывод сообщений в терминал доступен через stderr. Для вывода в stdout необходимо использовать программу VFS.

Не нашли ответ на свой вопрос?
Задать вопрос

Материалы

KasperskyOS

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

Скачать всё

Не нашли ответ на свой вопрос?

Ответим на вопросы о наших решениях, технологиях, планах и о многом другом

Связаться с командой

Узнать больше о технологическом или коммерческом партнерстве

Подробнее