Ядро KasperskyOS является собственной разработкой «Лаборатории Касперского» и не основывается на каком-либо существующем проекте (Linux или каком-то еще).
KasperskyOS — микроядерная операционная система, созданная с нуля в «Лаборатории Касперского». Благодаря принципам, заложенным в ее архитектуру, на основе нашей ОС можно создавать решения, обладающие кибериммунитетом — встроенной защищенностью от подавляющего большинства видов кибератак. Это очень важно для цифровых инфраструктур, где необходим высокий уровень гарантий безопасности.
KasperskyOS — первая операционная система, с помощью которой можно наделять IT-продукты кибериммунитетом. Такие продукты практически невозможно взломать, а подавляющее большинство типов атак на кибериммунную систему не может повлиять на выполнение ею критических функций. Решениям, построенным на KasperskyOS, не нужны дополнительные средства защиты — все необходимое уже есть внутри системы.
KasperskyOS позволяет гибко задавать политики безопасности — правила, которым будет следовать система весь свой жизненный цикл и которые не дадут ей выполнять потенциально опасные операции.
Компоненты нашей ОС разделены на изолированные домены безопасности и не могут влиять друг на друга. Все их взаимодействия проходят через микроядро, а Kaspersky Security System выносит вердикты безопасности каждому из них. Если что-то не соответствует заданным политикам, действие блокируется еще до его выполнения.
Благодаря этому при разработке на KasperskyOS можно использовать и недоверенные компоненты, не обладающие кибериммунитетом. Если в каком-то из них окажутся уязвимости и злоумышленники ими воспользуются, ОС просто не даст компоненту выполнять операции, не предусмотренные политикой безопасности, и влиять на работу решения.
Исходная безопасность KasperskyOS заложена в ее архитектуре и философии.
Так, запускаться и работать может только то, что напрямую разрешено администраторами системы и разработчиками приложений. Уже на этапе проектирования IT-решения на KasperskyOS задаются политики безопасности, которые описывают каждое разрешенное действие.
В микроядре KasperskyOS всего около сотни тысяч строк кода — поверхность атаки минимальна. А за работоспособность в любых ситуациях отвечает строгая изоляция системных компонентов: даже если в каком-то из них произойдет сбой, ОС продолжит выполнять свои критические функции.
KasperskyOS разработана в соответствии с архитектурами MILS и FLASK с добавлением собственных технологий безопасности «Лаборатории Касперского».
Кибериммунный подход в основе KasperskyOS не позволяет злоумышленнику влиять на работу системы, даже если ему удается взломать какой-то из ее компонентов, не обладающих кибериммунитетом. Технологии нашего микроядра и гибкой системы безопасности делают выполнение неавторизованных функций невозможным.
Чтобы наделить продукт на основе KasperskyOS кибериммунитетом, необходимо строго следовать специальной методологии «Лаборатории Касперского».
Кибериммунными могут считаться только исходно безопасные (Secure by Design) IT-системы. Если вкратце, то, чтобы их создать, с самого начала разработки нужно обеспечить следующее:
KasperskyOS не собирает и не передает данные. Все драйверы, системные сервисы, приложения и т.д. вынесены за пределы ядра и изолированы, а их поведение жестко ограничено политиками безопасности.
Ни один компонент системы не может сохранять и отправлять данные, если такая возможность не прописана для него в политиках.
У них разное позиционирование. Linux — это универсальная система для серверов, десктопов, мобильных устройств и т.д. Она хорошо адаптируется под разные применения. Тем не менее системных вызовов в ней так много, а модули внутри ядра имеют такую сложную цепочку связей, что мы не можем быть уверены в надежности проверки всех взаимодействий встроенными в ядро средствами безопасности, такими как SELinux. Каждый год находятся уязвимости или места, где те или иные политики не проверяются или не применяются к какому-либо системному вызову. А самое главное, если кто-то взломает монолитное ядро, он получит максимальные привилегии. В KasperskyOS же многие системные сервисы вынесены в пространство пользователя. Их взлом не даст злоумышеннику привилегий уровня ядра ОС.
Не совсем корректно сравнивать 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, — тонкий клиент, ключевая часть решения Kaspersky Secure Remote Workspace, и шлюзы для интернета вещей, которые помогают создавать защищенные IoT-сети и проводить цифровую трансформацию промышленности. А в 2020 году решение Kaspersky Automotive Adaptive Platform было интегрировано в автомобильный ЭБУ.
Наша ОС активно развивается, и круг устройств, на которых она работает, растет. Например, сейчас «Лаборатория Касперского» исследует возможность ее адаптации для мобильных платформ.
KasperskyOS — специализированная операционная система. Пока что на ее основе можно создавать только решения для встроенных IT-систем с необходимым для конкретных заказчиков функционалом.
При этом мы уверены, что кибериммунитет — это важное направление, которое в перспективе будет активно развиваться и среди персональных цифровых устройств. Благодаря кибериммунности пользователи смогут не переживать за безопасность своих устройств — они будут защищены от большинства кибератак по умолчанию. К такому будущему стоит стремиться.
На текущий момент мы с партнерами выпускаем решения на определенном железе. Если появится необходимость в других аппаратных платформах, мы будем портировать решения на них.
Шлюзы Kaspersky IoT Secure Gateway 100 и 1000 уже доступны к приобретению в России и Беларуси. В Европе их продажи ведутся через испанского дистрибьютора V-Valley. В этом году планируется выход на рынки регионов МЕТА и АРАС. А еще прорабатываются пилотные проекты в Латинской Америке.
Конечно, на рынке есть операционные системы, помогающие создавать функциональные продукты с очень высоким уровнем защищенности. Но возможности наделять продукты кибериммунитетом — «врожденной» защитой от кибератак — не дает ни одна из современных ОС. Конечно, для этого необходимо следовать специальной методологии «Лаборатории Касперского».
KasperskyOS предназначена для устройств, на которых установить антивирус не получится. Это, например, защищенные шлюзы, электронные блоки управления в автомобилях, тонкие клиенты.
Именно поэтому мы спроектировали нашу ОС так, чтобы ее не нужно было дополнять наложенными средствами защиты. Ее архитектура не позволяет злоумышленникам влиять на работу системы даже в случае компрометации какого-либо компонента.
Кибериммунный подход к разработке — это методология разработки конструктивно-безопасных систем (англ. Secure by Design). Его суть заключается в проектировании киберсистем, в которых меры безопасности интегрированы в архитектуру и программный код и являются его частью. В этом случае аспекты безопасности принимаются во внимание начиная с самых ранних стадий разработки — требования безопасности приравниваются к функциональным требованиям и влияют на выбор архитектуры решения и аппаратной базы.
Под высоким уровнем безопасности понимается способность противостоять большинству угроз, включая неизвестные.
Под высоким уровнем доверия понимается доказательность суждений о качестве мер защиты и качестве критических компонентов.
В основе кибериммунного подхода лежит три основных правила:
1. Изоляция компонентов
2. Контроль взаимодействий
3. Минимизация доверенной кодовой базы
Короткий ответ — нет, не требует.
В качестве платформы для создания кибериммунных решений может выступать любая ОС или системы виртуализации/контейнеризации, если они позволяют выполнить три правила кибериммунности.
Кибериммунный подход к разработке — это модульный подход, требующий высокий уровень изоляции подсистем на уровне ядра разделения и наличие монитора безопасности с формализованными политиками, сформулированными в контексте защищаемых модулей.
В реальной практике могут подойти микроядерные ОС или системы виртуализации или контейнеризации. Первое предпочтительно с точки зрения производительности и написания и применения политик безопасности.
KasperskyOS изначально создавалась как специализированная платформа для создания кибериммунных решений, поэтому является на настоящий момент, пожалуй, самым подходящим инструментом для кибериммунного подхода к разработке
Кибериммунный подход является расширением SDL в части постановки требований и проектирования архитектуры.
Классический SDL уделяет недостаточно внимания тому, как необходимо формализовывать требования, и какие критерии позволяют считать архитектуру безопасной.
Главная цель, которую помогает достигать кибериммунный подход к разработке — создание систем, устойчивых к атакам, поэтому наибольшую пользу от изучения получат архитекторы систем и те, кто собираются ими стать.
Помимо архитекторов пользу могут извлечь для себя:
Короткий ответ — нет.
Абсолютная защита невозможна, как бы нам этого ни хотелось. Ресурсы на тестирование и разработку всегда ограничены, люди делают ошибки, появляются новые виды атак и новые угрозы, растет квалификация злоумышленнииков, совершенствуется инструментарий и техники атак.
Кибериммунный подход позволяет выделить, максимально (в объеме имеющихся ресурсов) тщательно разработать и защитить именно те части системы, которые критичны для бизнеса. Это позволит снизить издержки на поддержку системы, т.к. не потребуется для исправления каждой уязвимости срочно выпускать и внедрять новую версию ПО и противостоять угрозам, которые были неизвестны на момент разработки.
Кибериммунный подход — это набор методов, архитектурных шаблонов и артефактов для привнесения в систему кибериммунитета — способности быть устойчивой к внешним и внутренним атакам, где под устойчивостью понимается способность достигать поставленные цели безопасности.
Кибериммунный подход способен принести пользу любым киберсистемам, бизнес-ценности которых заказчик хотел бы защитить. Вопрос безопасности стоит всегда и перед всеми киберсистемами, вопрос только в размере рисков.
Короткий ответ — нет.
Это учебная инфраструктура, для использования которой не требуется изучение KasperskyOS, но можно «пощупать» код, реализующий ключевые шаблоны безопасности на примерах.
А KasperskyOS — микроядерная операционная система, которая не базируется на ядре Linux. Для реализации межпроцессного взаимодействия используются механизмы передачи сообщений собственной разработки.
В качестве пользовательского ПО возможно использование клиентов для сторонних брокеров сообщений, но они не являются частью KasperskyOS, контроль такого взаимодействия со стороны встроенного монитора безопасности возможен через специально разработанные политики безопасности.
Тесты безопасности предназначены для проверки политик безопасности — правил, разрешающих отдельные взаимодействия между частями системы. С помощью таких тестов можно автоматизировать контроль защиты доверенной кодовой базы (кода, критического для целей безопасности) от атак со стороны недоверенных компонент.
Политика архитектуры (ПА) — термин, заимствованный из теории систем с разделением на домены. ПА является единственной общесистемной политикой безопасности, реализуемой на уровне ядра разделения системы, которое отвечает за изоляцию доменов безопасности. ПА использует высокоуровневое описание архитектуры в качестве отправной точки. На диаграмме политики архитектуры цветами выделяется доверенный и недоверенный код, уровень целостности данных, разрешенные взаимодействия компонентов (с учетом их направления).
Политика архитектуры является одним из важнейших артефактов кибериммунного подхода. Вместе с логическим объяснением принятых решений об уровне доверия к доменам безопасности системы она позволяет архитектору обосновать заказчику системы каким образом будут достигаться цели безопасности.
Кибериммунный подход предлагает сосредоточиться не столько на инструментах и технических средствах защиты, сколько на архитектуре системы и объектах защиты.
Проще говоря, используя кибериммунный подход к разработке, вы будете лучше понимать, какие данные, зачем и как вы защищаете, а канал передачи в этом случае — это не вся история, а только ее часть. Кибериммунный подход к разработке позволит лучше защитить ценные данные, а не канал, который является лишь одним из инструментов защиты, а не панацеей.
С другой стороны, кибериммунный подход к разработке предъявляет высокие требования к верификации критических компонентов системы. В этом смысле вы будете лучше знать, чего стоит защита в вашем канале, если он окажется критическим компонентом в вашей системе.
Мы предлагаем открытое онлайн обучение в виде мини-курсов, новые группы набираются 1-2 раза в месяц. Подробности в нашем канале Telegram.
По вопросам корпоративного обучения напишите нам на электронный адрес cyberimmunity-edu@kaspersky.com.
На этот же адрес можно написать, если вы хотите преподавать кибериммунный подход к разработке в вашем ВУЗе.
В кибериммунном подходе доверенный код (доверенная кодовая база, trusted computing base — TCB) — это код, который критически важен для достижения целей безопасности системы. То есть доверенный код — это код, которому мы вынуждены доверять (и потому вынуждены его тщательно проверять), а не тот, который является «хорошим» с нашей точки зрения.
TCB может включать в себя сторонние билиотеки или целые фреймворки. Задачей архитектора является минимизация TCB, потому что его верификация —сложная и дорогостоящая задача. Задачей команды разработки является проверка всеми доступными средствами этой кодовой базы на предмет уязвимостей и закладок. Тогда этот доверенный код можно будет считать «благонадежным», т.е. таким, который делает то, что от него ожидается.
Отсюда очевидно, что чем меньше такого доверенного кода в системе, тем дешевле будет разработка и обслуживание.
Важно уменьшить общий объем доверенной кодовой базы. Желательно, чтобы отдельные доверенные компоненты были простыми по логике, маленькими по объему, имели минимальное количество интерфейсов с жестко типизированными параметрами, а сколько таких компонентов будет в итоге не столь важно.
Важно иметь в виду — чем мельче дробление, тем лучше можно контролировать взаимодействие на уровне политик. С другой стороны, тем большее негативное влияние на производительность системы этот контроль оказывает.
В конечном итоге архитектор должен определить оптимальное соотношение для системы, основываясь в том числе на требованиях производительности и обслуживаемости системы, а не только защищенности.
Собственный код KasperskyOS постоянно проходит различное тестирование, включая фаззинг. Для ряда наиболее критичных компонентов выполняется формальная верификация и проверка моделей безопасности. Код подвергается статическому и динамическому анализу. Регулярно проводятся пентесты. Запланировано проведение Bug Bounty.
Кибериммунитет — это, прежде всего, подход, целью которого является создание системы, безопасной в силу дизайна (Secure by Design). Подобные системы разительно отличаются от обычных систем в защищенном исполнении тем, что они обладают минимальной поверхностью атаки не за счет использования наложенных средств защиты, а за счет правильно спроектированной архитектуры. Кибериммунные системы более устойчивы к взлому (компрометации), а в случае успешной атаки значительно усложняют ее распространение.
В кибериммунном подходе мы, в первую очередь, фокусируемся на сохранении целостности системы. Ведь если компоненты, осуществляющие разграничение доступа, будут взломаны, безопасность всей системы окажется под угрозой. А кода без багов, как мы знаем, пока не существует в природе.
Для каждого конкретного продукта на базе KasperskyOS мы формулируем цели и предположения безопасности: какие функции безопасности системы должны выполняться всегда, что бы ни произошло, при соблюдении ряда предположений.
Архитектор решения определяет ilities, которые необходимо поддержать на уровне решения, например, конфиденциальность (confidentiality), доступность (availability) и другие. Для каждого подобного свойства должен быть системный компонент, который его обеспечивает, — уже реализованный в KasperskyOS (security pattern) или требующий реализации.
На основе целей безопасности и понимания необходимых ilities, проектируется архитектура решения: производится декомпозиция системы на изолированные аппаратными средствами компоненты, устанавливается набор типизированных связей между ними. На этом этапе упор делается на целостности: какой сорт данных может передаваться между теми или иными компонентами, насколько эти данные целостны, как может повлиять их злонамеренное изменение на возможность эксплуатации того или иного компонента, какие компоненты оказывают прямое влияние на функции безопасности системы.
В результате мы получаем архитектуру, которая значительно затрудняет распространение атаки в системе и минимизирует вероятность взлома доверенных компонентов (тех, от которых зависит безопасность, реализация ilities).
Архитектура системы отражается в политике безопасности для монитора безопасности, исполняющегося в ядре. Он следит, чтобы инварианты архитектуры не нарушались: сообщения шли только по четко заданным каналам связи, структура сообщений не нарушалась, а в полях сообщений лежали верные с точки зрения архитектора системы данные.
Таким образом, кибериммунитет подразумевает определенную культуру и подход к разработке и построению архитектуры, а также технологическую базу — операционную систему KasperskyOS.
По умолчанию мы считаем, что монитор безопасности — доверенный компонент. Т.е. компонент, которому мы вынуждены доверять. Если он скомпрометирован, то механизм изоляции нарушается, и мы не можем говорить, что система остается безопасной. Поэтому мы применяем максимум средств для того, чтобы доказать, что монитор безопасности является корректным.
Первое — код монитора написан на декларативном языке и монитор генерируется, а не пишется руками. Какое-то количество ошибок отпадает из-за этого.
Второе — сгенерированный монитор безопасности мы можем хорошо протестировать, особенно учитывая, что в процессе генерации из промежуточного представления можно создавать не только код монитора, но и некоторые модели. Они позволяют генерировать стопроцентное тестовое покрытие там, где это возможно, а там, где это невозможно, проверять некоторые части с помощью model checking.
В конечном итоге мы планируем доказать корректность всех применяемых моделей безопасности с использованием методов формальной верификации. Также есть фаззинг. Так что монитор достаточно надежная вещь и будет еще надежнее.
Никто не расскажет лучше про проблемы fork, чем сотрудники компании Microsoft. Если кратко – fork небезопасный вызов, приводящий к неконтролируемому наследованию ресурсов родительского процесса. Также, архитектура и низкоуровневый API нашей ОС не позволяют эффективно реализовать этот системный вызов без серьезных изменений на уровне микроядра.
У нас есть много средств для контроля исполнения кода. Ситуация, в которой злоумышленник может перезаписать код самой ОС или firmware нелегальна даже в обычных операционных системах, а уж у нас тем более. Защита от этого у нас на хорошем уровне в силу архитектурных подходов, о которых мы не раз рассказывали.
OCap может контролировать и системные ресурсы, и ресурсы пространства пользователя. Системные ресурсы – это регионы памяти, прерывания, порты ввода-вывода. Даже задачи и потоки у нас представлены объектами системных ресурсов, а значит ими можно безопасно управлять.
Объекты пользователя тоже могут быть представлены OCap. У нас есть специальный системный вызов (KnHandleCreateUserObject), которому нужно предоставить пользовательский контекст – какой-то указатель в адресном пространстве сервиса (провайдера ресурса), этот контекст сохраняется в специальный объект ядра.
Затем мы можем получить родительский хэндл на этот объект и дальше его передавать. Когда происходит обратная передача провайдеру ресурса хэндла на его объект, он узнает соответствующий указатель и маску прав доступа, с которой к нему обращаются. Он может сам проверить эту маску прав и разрешить или запретить доступ к этому пользовательскому объекту. Также мы можем написать политику KSS, которая способна залезть внутрь сообщения, посмотреть, что за SID находится за этим хэндлом, какая маска прав и тоже разрешить или запретить доступ. Так что да, все объекты в системе можно сделать OСap-совместимыми.
У нас используется набор известных моделей безопасности и по некоторым из них приходилось доказывать, что в рамках нашей системы их работа корректна. На эту тему была публикация Владимира Буренкова. Может быть 100% гарантию мы можем дать не везде, но мы работаем над этим. В частности, привносим в разработку формальные методы. Например, в разработке монитора безопасности частично применяется такой инструмент, как K framework. Он позволяет описать не только синтаксическую, но и семантическую часть языка промежуточного представления. Зная семантику, можно проводить символьное исполнение, доказывать некоторые утверждения о политике.
Возможны два варианта ответа – все зависит от доступного оборудования.
Если железо поддерживает IOMMU, то вопрос изоляции отпадает автоматически: наша ОС изолирует адресные пространства процессов не только со стороны CPU, но и со стороны устройств.
Если железо не поддерживает IOMMU, решение нужно строить специальным образом. Мы выделяем часть драйвера, управляющую DMA-контроллером устройства, в изолированную сущность, проверяем ее на отсутствие уязвимостей и называем доверенным компонентом. Далее мы пишем политики взаимодействия так, чтобы к доверенному компоненту обращались только авторизованные компоненты и делали это лишь установленным образом. В этом случае ни один процесс в системе не может напрямую запрограммировать контроллер DMA некорректным образом, это может сделать только доверенный драйвер. А этот драйвер хорошо проверен и у нас есть определенная степень уверенности, что его трудно взломать.
Проектируя продукты на KasperskyOS, мы рассматриваем аппаратуру доверенной. При этом в случае нашей системы потенциальный вред, который могут нанести Meltdown, Spectre и им подобные, минимален.
Meltdown позволяет непривилегированному коду читать данные из привилегированного пространства ядра. KasperskyOS – микроядерная ОС и в ядре содержится не так много данных, которые мог бы использовать злоумышленник. Большинство системных служб, в том числе связанных с криптографией, реализуются в пространстве пользователя.
Spectre для успешной эксплуатации полагается на существование разделяемых областей памяти между процессами. Именно благодаря этому удается создать паразитный канал связи, основанный на измерении таймингов доступа к кэш-линиям при косвенном обращении к памяти. В KasperskyOS по умолчанию не предполагается использование разделяемой памяти. Такие случаи исключительны, а, следовательно, низка вероятность вредоносной эксплуатации этой аппаратной уязвимости.
Появление новых объектов ядра не требует изменения политик безопасности. Большинство политик безопасности оперируют понятиями субъектов и объектов. По запросу какого-либо процесса, если политика не запрещает процессу этого класса подобное действие, может быть создан объект ядра, например для выделяемого региона памяти, порта ввода-вывода или DMA-региона.
Каждому такому объекту будет назначен уникальный идентификатор и монитор безопасности узнает о каждом новом объекте. Передача прав на работу с любым подобным объектом видна монитору безопасности и политика может ограничивать передачу части прав между определенными субъектами.
Обычно политике не нужно знать о конкретных объектах, только о интерфейсах и классе объектов, которые передаются в конкретных сообщениях. Когда требуется знание о характеристиках конкретных объектов, поведение политики может параметризоваться при помощи security-интерфейсов.
Политики безопасности позволяют разрешить сущностям только определенные методы. В случае именно с USB надо смотреть на конкретные сценарии использования. C RDP-клиентом мы поддерживаем только класс токенов. Есть работа с USB-накопителями, но на уровне нашего продукта (тонкого клиента) не происходит выполнения какого-либо кода, все связанное с USB мы отдаем дальше, виртуальным рабочим столам.
KasperskyOS не является системой жесткого реального времени. Мы двигаемся в направлении поддержки soft-realtime: уже адаптировали планировщик, в нем появился соответствующий класс планирования. Впереди нас ждет много работы по доработке примитивов синхронизации, борьбе с инверсией приоритетов, изменении некоторых алгоритмов и структур данных, чтобы добиться константности времени исполнения.
Вопрос неоднозначный. Производительность микроядерных систем традиционно оценивают по производительности механизма IPC.
В нашей системе мы в первую очередь ставили на безопасность, возможность инспекции сообщений, невозможность атак типа TOCTOU. Отсюда необходимость держать в ядре безопасную копию передаваемого сообщения для монитора безопасности. Конечно, это накладывает свои ограничения на возможность оптимизации IPC.
Пока мы не соревнуемся в производительности с Linux и другими массовыми ОС, здесь они точно выигрывают. Но за счет разумных компромиссов KasperskyOS обеспечивает приемлемую производительность, позволяющую делать реальные безопасные продукты.
Идея прокачивать сообщения пакетом, а не по одному логичная. Но все сильно зависит от конкретного кейса. Через наши типизированные взаимодействия можно передавать и отдельные слова, и неструктурированные массивы байтов. Как будет выглядеть интерфейс и сколько в нем будет упаковано сообщений – вопрос к архитектору. Всегда есть компромисс между редкими, но большими сообщениями и множеством коротких.
Если сообщения носят неструктурированный характер, а архитектура решения позволяет использовать разделяемую память, то возможно установление быстрого канала связи за счет передачи права использования MDL-объекта (MDL — Memory Descriptor List). В таком случае мы приобретаем возможность быстро передавать данные между процессами, но теряем возможность инспектирования сообщений, переданных по этому каналу.
Доступ именно к сервисам ядра не приводит к сериализации: 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.
Хороший вопрос. Он очень специфичен для конкретного устройства и драйвера, но архитектура позволяет его решить. Еще раз напомним, что в KasperskyOS драйверы — это отдельные процессы. В других ОС, если у вас есть плохой драйвер в контексте ядра, и он вошел в это состояние, преодолеть такой сбой вы можете только перезагрузив всю систему. В KasperskyOS вы можете такой драйвер остановить и перезапустить, что может предотвратить сбой. Мы планируем добавить функцию отслеживания потребления сущностями ресурсов. При превышении какого-то порога, они будут перезапускаться.
Драйвер всегда взаимодействует с реальным железом. Без железа можно отладить только некоторые его части, например, транспортные библиотеки, которые реализуют клиентские или серверные сущности. Вы можете написать эмулятор, который позволит отладить часть, не относящуюся к железу. Но для того, чтобы верифицировать работу драйвера на практике, вам придется строить стенды. У нас такая активность идет. Имеется лаборатория, в которой есть контрольно-измерительное оборудование.
Руководств по портированию драйверов и приложений из Linux на KasperskyOS нет. Портирование драйверов происходит на основе готовых драйверов и принятой драйверной модели.
Микроядерность предполагает, что драйверы устройств и подсистемы низкого уровня выносятся в изолированные процессы пространства пользователя. Драйверы периферии и сетевых карт реализуются полностью в пространстве пользователя: ошибка (уязвимость) в каком-либо драйвере не может нанести вред ядру операционной системы и другим компонентам. Это же касается сетевого стека, USB. Драйверы для большинства необходимых устройств мы разрабатываем сами, некоторые портируем из ОС с подходящими лицензиями.
KasperskyOS Community Edition — это комплект для разработки программного обеспечения (далее также SDK), предназначенный для сборки собственного образа KasperskyOS для определенного набора аппаратных платформ. В комплект поставки входят ядро KasperskyOS, инструментарий разработки решений, ряд библиотек, примеры их использования, а также документация. SDK поставляется в виде deb-пакета для Debian GNU/Linux 10 «Buster» и может быть бесплатно скачан по ссылке. В состав образа не входят средства командного интерфейса (консоль, GUI). После установки SDK разворачивается в директории /opt/KasperskyOS-Community-Edition-<version>.
KasperskyOS Community Edition предназначен для бесплатного ознакомления с принципами построения решения на базе KasperskyOS, особенностями реализации политик безопасности, написания и отладки собственных пилотных проектов. Лицензия также позволяет модификацию компонентов, поставляемых в виде исходных кодов. В настоящее время KasperskyOS Community Edition позволяет разрабатывать ПО для встраиваемых систем, управляемых по сети ethernet (как через веб-интерфейс, так и по другим протоколам).
Версия KasperskyOS Community Edition (CE) не предназначена для коммерческого использования. Этот дистрибутив позволяет разработать полнофункциональный продукт и демонстрировать его потенциальным клиентам. Для непосредственно тиражирования коммерческих продуктов на основе KasperskyOS необходимо приобретать коммерческую лицензию.
Условия коммерческой лицензии зависят от многих параметров: количества производимых устройств, бизнес-модели (например, фиксированные платежи или роялти или разделение доходов). Также на стоимость могут влиять, если они нужны для проекта, работы со стороны «Лаборатории Касперского». Сюда могут входить, например, поддержка специфичной аппаратной платформы, сервис технической поддержки и обновлений.
Если у вас уже есть предполагаемые детали/параметры проекта, поделитесь с нами, чтобы коллеги могли предложить вам бизнес-модель и рассчитать стоимость.
Даже если такие параметры у вас пока не готовы, «Лаборатория Касперского» заинтересована в поддержке успешных продуктов на KasperskyOS и не выставляет «заградительных» цен на лицензии.
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.
Сетевой стек для Ethernet, работа с SD-картой, работа с GPIO в режиме обычных входов/выходов.
Никаких специальных требований к железу по сравнению, например, с Linux нет. MMU обязателен, также мы предпочитаем платформы с IOMMU, так как эта технология позволяет распространить изоляцию и на DMA операции.
Сегодня мы с технологическими партнерами выпускаем решения на определенном железе (на базе x86_64, ARMv6/7/8). Если появится необходимость в других аппаратных платформах, мы будем портировать решения на них.
Поддержка нового оборудования – непростая задача. Мы справляемся своими силами: пишем драйверы и BSP, иногда портируем их из других ОС с открытым исходным кодом. Но иногда такая работа может выполняться и нашими партнерами.
PCRE (регулярные выражения), Civetweb, Boost, mbedTLS, Mosquitto.
В настоящее время поддержка этих библиотек лежит на команде разработки KasperskyOS. Нам бы хотелось, чтобы через некоторое время поддержка этих библиотек была передана оригинальным разработчикам или в open-source сообщество.
Совместимые с KasperskyOS Community Edition форк nginx, форк PHP, форк Samba, форк NodeJS, форк Nmap уже доступны на сайтах. Портирование других библиотек можно найти на https://github.com/KasperskyLab.
Можно использовать как статические, так и динамические библиотеки. Для использования библиотек при сборке решения соответствующую библиотеку нужно указать в зависимостях соответствующего артефакта. Динамические библиотеки поставляются в составе SDK, а также могут быть созданы разработчиком решения на базе KasperskyOS. Работоспособность сторонних динамических библиотек не гарантируется.
На данный момент возможна разработка на языках C и C++ с использованием кросс-компиляторов GCC.
На данный момент рекомендованной средой разработки является VSCode с подсветкой синтаксиса C/C++.
Rust – перспективный язык системного программирования. Он решает многие проблемы языков C и C++, причем достаточно дешево: как и C++ Rust исповедует путь zero-cost абстракций.
Мы присматриваемся к Rust в первую очередь для разработки кода пространства пользователя. В продуктовой разработке готовятся к поддержке Rust в KasperskyOS, чтобы поддержать свежую версию движка Suricata.
Для KasperskyOS мы портировали интерпретатор Lua и виртуальную машину Java. Для нашей системы есть и веб-браузер на базе WebKit, который поддерживает исполнение JavaScript.
Да, сейчас вы можете пройти курс на образовательной платформе Stepik. Курс посвящен общим понятиям кибербезопасности и кибериммунной разработки, а также дает практические навыки разработки под KasperskyOS.
Сторонние приложения, возможность установки которых есть в некоторых сборках KasperskyOS, исполняются в контейнеризированной среде: приложение получает свое собственное изолированное хранилище и виртуальную файловую систему, доступ к возможностям, предоставляемым базовой ОС, дается через capabilities. Такое приложение не может добраться до данных других приложений и напрямую обратиться к драйверам и другим системным сервисам.
KasperskyOS опирается на мультисерверную архитектуру: в пространстве пользователя исполняются компоненты, отвечающие за конкретные функции системы, взаимодействие с этими компонентами происходит через типизированные интерфейсы. Компоненты могут порождать объекты и предоставлять к ним доступ через удаленные вызовы. Все ресурсы в системе представлены такими объектами, как ресурсы ядра (потоки, регионы памяти, порты, прерывания, каналы), так и пользовательские (устройства, файлы). То есть парадигма ближе к объектно-ориентированной – систему можно условно представить как множество объектов, обменивающихся сообщениями.
Файловая система в KasperskyOS – отчуждаемая сущность, можно представить вариант сборки KasperskyOS вовсе без файловой системы. Также возможен вариант системы без POSIX API. Поэтому подходы «все есть файл» из Plan 9 и более традиционных Unix-подобных систем здесь неприменимы.
Для KasperskyOS не разрабатывалось специальной in-house файловой системы. Обычно мы портируем открытые реализации файловых систем из ОС с подходящей лицензией, после чего дорабатываем эти реализации, чтобы они удовлетворяли нашим требованиям.
В коллекции компонентов KasperskyOS уже есть портированные популярные библиотеки и программы. Основной вектор продуктовой разработки подразумевает создание собственных решений на базе KasperskyOS. Но есть, например, KasperskyOS Community Edition: разработчики этой сборки системы портируют популярные программы и технологии из GNU/Linux, чтобы привлечь разработчиков, знакомых с этими технологиями.
В KasperskyOS функционирует простой графический композитор на основе протокола Wayland. Есть наработки по графическому стеку (на основе DRI). Тем не менее, разработки полноценного десктопного решения пока нет в планах.
Ядро, базовая библиотека libkos, драйверный фреймворк, input-фреймворк и большинство драйверов, которые разрабатывает команда KasperskyOS, не содержат заимствованного кода. Но есть некоторые исключения. Например, система конфигурирования ядра, куски RTL (snprintf, rb tree). В файле legal.lst можно посмотреть полный их список. Также заимствованный код встречается у продуктовых команд и команд, занимающихся системными компонентами: VFS, сетевыми стеками. По большей части это код под BSD- и MIT-подобными лицензиями.
Да, мы находили и исправляли ошибки в open-source компонентах. Наша цель по покрытию – 100% по функциям и 75% по бранчам. Пока мы этого не достигли, но движемся в этом направлении.
Лицензии наследуются.
Да, будем сертифицировать ОС по требованиям ФСТЭК А4. Даты назвать не готовы, следите за анонсами.
Причиной является проблема в доступе локального процесса к оконной системе 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 4B».
Примеры GPIO под QEMU не будут корректно выполняться.
Конечно, может. В частности, в продукте с гарантией дата-диода (KISG-100) все приложение может состоять из двух видов сущностей: конвертер входного и выходного протокола. Они могут поставляться разными или одним и тем же разработчиком. Мы поняли, что для гарантии дата-диода невозможно сконцентрировать всю логику обработки протоколов в одной сущности. Мы пришли к тому, что базовое приложение — конвертер протоколов — состоит из двух процессов.
Обычный TLS-уровень. Те же самые алгоритмы, что используются, например, в HTTPS.
Соединение у нас происходит только к тем серверам, которым мы доверяем. Атаки со стороны RDP-сервера мы не ожидаем. Но если бы ожидали, мы должны были бы более глубоко и полно проделать фаззинг и пентестирование для FreeRDP.
Исходно TLS Terminator — небольшая сущность с одной функциональностью. Такую сущность проще проверить, у нее маленькая поверхность атаки, мы называем ее доверенной. То, что потребовалось создать отдельный экземпляр TLS Terminator, донастроенный под конкретный протокол, не мешает ему обладать теми же свойствами. С другой стороны, встраивание реализации TLS в виде библиотеки значительно увеличивает поверхность атаки и нарушает принципы построения кибериммунного решения.
Есть два варианта.
Более сложный: разработчик должен использовать IPC-вызов к серверному компоненту вызываемой библиотеки.
Более простой: вместе с библиотекой должен поставляться клиентский компонент, который статически компонуется с решением разработчика и скрывает IPC от разработчика.
По умолчанию вывод сообщений в терминал доступен через stderr. Для вывода в stdout необходимо использовать программу VFS.
Операционная система для подключенных к интернету встраиваемых систем с особыми требованиями к кибербезопасности
