Особенности реализации безопасной ОС

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

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

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

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

Часто для построения безопасной системы на основе распространенной ОС в эту систему внедряются дополнительные механизмы контроля доступа (например, на основе мандатной модели), усиленной аутентификации, шифрования данных, аудита событий безопасности, контроля исполнения приложений. Как правило, это типовые меры защиты – а специфические потребности системы обеспечиваются на уровне приложений. Таким образом, специальные (а часто и общие) меры безопасности полагаются на реализацию множества компонентов, каждый из которых может быть скомпрометирован. Примеры таких ОС: SELinux, RSBAC, AppArmor, TrustedBSD, МСВС, Astra Linux и другие.

Для улучшения безопасности в систему также могут быть внедрены средства, затрудняющие эксплуатацию некоторых уязвимостей, в том числе свойственных системе вследствие ее изначально небезопасного дизайна. Примеры: Grsecurity, AppArmor, Hardened Gentoo, Атликс, ЯНУКС, Astra Linux и др.

Всего несколько лет назад был распространен подход к предоставлению гарантии «безопасности» на основе проверок программного кода на наличие ошибок и уязвимостей, проверки целостности ПО путем сравнения контрольных сумм. Такой подход использовался в Openwall Linux и некоторых российский ОС.

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

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

Если операционная система предназначена для целевого использования на более или менее фиксированном оборудовании, а под ее управлением в рамках описанных сценариев работы выполняется вполне определенное программное обеспечение, то достаточно четко могут быть определены цели безопасности и построена модель угроз. На основании этой модели для достижения целей безопасности формулируется конкретный перечень требований безопасности и требований доверия. Удовлетворения этих требований достаточно для гарантии безопасного поведения системы. Примером таких операционных систем являются специализированные встраиваемые решения от LynuxWorks, Wind River, Green Hills.

Для операционной системы общего назначения труднее достигнуть таких же гарантий в силу более широкого определения целей безопасности (чтобы система могла поддерживать больше сценариев безопасного выполнения). Обычно требуется поддержка целого класса политик для определенного типа контроля доступа (дискреционного, мандатного, ролевого), привычных механизмов аутентификации, других средств защиты, управление которыми не требует специальных знаний. Это требует реализации относительно универсальных механизмов безопасности. Иногда при условии исполнения ОС на фиксированной аппаратной платформе (как правило, того же производителя) с достаточной степенью уверенности может быть гарантировано соблюдение требований определенного стандарта, или профиля защиты, к этим механизмам. Примеры: Oracle Solaris with Trusted Extensions, XTS-400, OpenVMS, AS/400.

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

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

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

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

Нужно отметить, что на основе архитектуры Flask построен ряд улучшений безопасности ОС общего назначения (SELinux, SEBSD), однако эти системы построены на основе монолитного ядра большого объема. Действительно, Flask не требует применения микроядра, но лучше всего работает именно с ним.

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

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

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

Конечно, микроядерная система на Flask-подобной архитектуре не является уникальной идеей разработчиков KasperskyOS. Существует опыт успешных разработок микроядра (seL4, PikeOS, Феникс/Фебос), в том числе с формально верифицированными свойствами безопасности. На основе этих разработок может быть реализована ОС, позволяющая гарантированно осуществить разделение доменов безопасности (обеспечить «безопасность через изоляцию»). Эта архитектура известна как MILS (Multiple Independent Domains of Safety/Security).

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

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

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

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