Современные ОС для встраиваемых систем

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

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

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

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

• монолитные системы,
• ОС с монолитным ядром,
• микроядерные ОС,
• гибридные системы.

Монолитные системы

Это наиболее распространенный тип архитектуры ОС для встраиваемых (embedded) устройств. Большинство проанализированных нами операционных систем — это монолитные среды, предназначенные для работы в микроконтроллерах, где все процессы (как пользовательские, так и системные) выполняются в одном адресном пространстве без ограничений.

С точки зрения ИБ данная архитектура приемлема лишь для очень простых задач: по мере усложнения функционала риск появления уязвимостей становится слишком большим. При этом в таких системах уязвимости, где бы они ни появились – в реализации системных сервисов или в каком-либо вспомогательном приложении – приводят к полной компрометации всего решения.

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

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

При этом, даже если в подобном решении формально применялась микроядерная архитектура, в отсутствие изоляции пользовательских процессов от системных обеспечить приемлемый уровень защищенности невозможно, поскольку любой пользовательский процесс может влиять на работу микроядра. Примерами «микроядерных» ОС, где должным образом не обеспечивается изоляция процессов, являются получившие достаточно большое распространение RIOT OS, Zephyr, Unison RTOS и даже коммерческое ядро для микроконтроллеров µ-velOSity от Green Hills, а также базовая ОС для automotive-решений от компании Vector – Microsar OS.

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

Системы с монолитным ядром

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

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

При этом в контексте ядра работает большое количество сервисов – например, реализация протоколов, файловые системы, драйверы устройств и т.д. Примерами операционных систем с монолитным ядром являются ОС на базе ядра Linux и его производных (включая Android), а также Windows, FreeBSD, RTEMS и другие.

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

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

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

Различные дистрибутивы Linux

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

Замечание: Linux служит лишь ядром операционной системы. Полноценными операционными системами являются дистрибутивы на базе ядра Linux.

Стоит также отметить, что Linux изначально разрабатывался как ядро для многопользовательской ОС и содержит определенный набор встроенных механизмов безопасности. Тем не менее, с современной точки зрения у Linux достаточно много проблем с ИБ – как архитектурных, так и в плане реализации.

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

Разработано большое количество ответвлений и дистрибутивов на базе Linux, направленных на повышение безопасности, а также расширений, предназначенных для решения проблем ИБ, в том числе AppArmour, GRSecurity, PAX, SELinux и др. Такие расширения позволяют улучшить ситуацию, но они не могут гарантировать достаточную безопасность, поскольку объем кодовой базы ядра Linux очень большой, и нет возможности сделать вычислительную базу ядра доверенной. И эта проблема, судя по всему, является непреодолимой. Например, по данным сайта www.cvedetails.com за 2017 год в ядрах Linux было обнаружено 453 уязвимости, причем 169 из них дают возможность выполнять в контексте ядра произвольный код. Эксплуатация уязвимости в ядре Linux позволяет преодолеть любые механизмы защиты, даже самые совершенные и тщательно сконфигурированные.

Android

Android 8.0 Oreo является последней версией операционной системы Android для мобильных устройств и, по заявлению разработчиков, содержит множество новых механизмов ИБ. Ключевые функции обеспечения безопасности в этой ОС направлены на уменьшение последствий эксплуатации уязвимостей (Exploit mitigation) и сокращение поверхности атаки, а также на использование принципа наименьших привилегий. Также изменения коснулись дизайна API и архитектуры. Среди нововведений отметим следующие:

• Интеллектуальная защита определения прав для приложений.
• Расширенные проверки при обновлении приложений и операционной системы с целью избежать распространенных видов атак, в том числе Roll Back.
• Встроенная поддержка HSM (Hardware Security Module).
• Sandboxing приложений с поддержкой seccomp фильтров (secure computing ограничивает возможности приложений по осуществлению системных вызовов) и изоляции компонента WebView.
• Поддержка набора профилей для шифрования (различные профили используют различные наборы ключей).
• Встроенная поддержка двухфакторной аутентификации с использованием физических ключей.
• Запутывание путей к приложениям. Приложение более невозможно найти по его фиксированному расположению: каждый раз оно устанавливается в новое место, и для того, чтобы получить к нему доступ, требуется делать специальный запрос к системе.
• Удалена поддержка устаревших и уязвимых протоколов и алгоритмов, в частности SSL v3.0.

Все это нужные и полезные меры, которые существенно усложняют процесс пост-эксплуатации уязвимостей и получение прав root.

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

Микроядерные ОС

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

Микроядро предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью специальных пользовательских процессов, не работающих в адресном пространстве ядра. Это позволяет существенно сократить поверхность атаки на сервисы ядра, а само ядро ОС может быть тщательно верифицировано (в силу малого объема кодовой базы), в том числе с использованием формальных методов верификации. Для тех, кто хочет узнать больше о процессе верификации и о том, чем она отличается от валидации, рекомендуем статью «Валидация и верификация» нашей коллеги Екатерины Рудиной.

Наилучшие практически значимые результаты с точки зрения информационной безопасности получены именно для микроядерных архитектур. Например, подход Separation Kernel и использование MILS архитектуры.

Различные микроядра и микроядерные ОС довольно широко представлены на рынке. К этой категории относятся, например, QNX, INTEGRITY RTOS, Genode, ядро L4 и его производные.

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

Семейство микроядер L4

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

Среди поддерживаемых в настоящее время реализаций можно выделить следующие:

• seL4 – первое формально верифицированное микроядро, разработка которого активно продолжается.
• Codezero – коммерческая версия ядра L4. Исходные коды ядра доступны по лицензии GPLv3, а код дополнительных модулей и библиотек закрыт и распространяется по коммерческим лицензиям.
• OC – версия, разработанная Дрезденским технологическим университетом. Распространяется на условиях лицензии GPLv2 с возможностью коммерческой поддержки.

Для перечисленных операционных систем доступны различные решения для виртуализации. Среди других решений на базе микроядра L4 для виртуализации — OKL4, NOVA и операционная система PikeOS.

Микроядра семейства L4 используют также следующие операционные системы:

• Genode
• TUD:OS – операционная система, разработанная Дрезденским технологическим университетом на базе L4Re – фреймворк для построения решений на базе L4.
• CAamkES – фреймворк на базе микроядра L4, разработанный Trustworthy Systems Research Group @Data61.
• L4Linux – портирование ОС Linux на ядра семейства L4. В данной реализации L4 Linux выполняет роль user-mode службы, работающей совместно с другими приложениями L4 (включая real-time компоненты). Поддерживаются версии ядра Linux до 4.14 включительно и аппаратные платформы x86 и ARM.

С точки зрения безопасности наиболее важным представителем семейства L4 является ядро seL4.

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

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

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

Гибридные ОС

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

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

Требование «исходной безопасности» (secure by design)

Большинство операционных систем с долгой историей изначально разрабатывались без учета соображений ИБ. При добавлении свойств безопасности приходится сталкиваться с тем, что функциональные механизмы перестают работать так, как раньше, и возникают проблемы совместимости. В силу этой и многих других причин полная переработка архитектуры таких систем невозможна, и нельзя говорить о гарантиях обеспечения безопасности – только об усилении некоторых связанных с нею свойств. В качестве примеров таких решений можно привести QNX, Linux, FreeBSD и многие другие.

Только те операционные системы, в процессе разработки которых принимались в расчет требования ИБ, способны обеспечить качественную реализацию механизмов обеспечения безопасности без ущерба для своих функциональных возможностей. К тому же, использование подхода «исходной безопасности» является одним из ключевых требований для сертификации конечного решения по стандарту Common Criteria, начиная с уровня EAL4. В число ОС с «исходной безопасностью» входят seL4, INTEGRITY RTOS, MUEN RTOS, KasperskyOS и ряд других.

KasperskyOS

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

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

Все взаимодействия являются типизированными – интерфейс сущностей описан на языке IDL (Interface Definition Language), и только этот интерфейс может быть использован для IPC. В этом заключается существенное отличие KasperskyOS от большинства других операционных систем.

Микроядро KasperskyOS работает совместно с Kaspersky Security System (KSS) – подсистемой, вычисляющей вердикты безопасности. Для каждого IPC микроядро KasperskyOS запрашивает у KSS вердикт, на основании которого разрешает или запрещает данное взаимодействие. При вычислении вердикта в расчет принимаются не только факт и тип взаимодействия, но и топология системы, контекст, в котором происходит взаимодействие, а также заданная политика, описанная в рамках набора формальных моделей безопасности.

KSS поддерживает большое количество формальных моделей безопасности, например Domain Type Enforcement, Object Capability, Role Based Access, различные варианты (диалекты) темпоральных логик. При необходимости в набор можно добавлять новые модели.

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

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

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

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

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

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

Кодовая база KSS, отвечающая за реализацию политик безопасности решения, является генерируемой, формально верифицируемой[2] и в этом смысле доверенной. Таким образом, решается проблема с неконтролируемым разрастанием кодовой базы, к которой предъявляются требования доверенности.

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

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

1. Анализ угроз и построение модели угроз.
2. Разработку набора формальных политик безопасности для противодействия угрозам, описанным на шаге 1.
3. Декомпозицию решения на домены безопасности и определение интерфейсов IPC в соответствии с данными, полученными на шаге 2.
4. Имплементацию решения с учетом данных, полученных на шаге 3, и конфигурирование политик безопасности, соответствующих результатам, полученным на шаге 2.

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

KasperskyOS обеспечивает поддержку виртуализации с помощью приложения Kaspersky Secure Hypervisor (KSH). Его особенностью является поддержка совместной работы с KSS для реализации политик безопасности в отношении контроля доступа виртуальных машин ко внутренним ресурсам гипервизора. KSH является легковесным решением, что позволяет верифицировать его кодовую базу и рассматривать Kaspersky Secure Hypervisor как часть доверенной вычислительной платформы. Используя вердикты KSS, гипервизор может применять их к своим внутренним процессам даже в тех ситуациях, когда междоменное взаимодействие не происходит.

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

Заключение

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

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

 
^[1] В настоящее время формальная верификация KSS не проводилась, однако примененный подход позволяет это сделать.
^[2] В настоящее время требование формальной верифицируемости не выполняется, но в этом направлении ведутся активные работы