Безопасность операционных систем — основная тема девятой конференции OS DAY, которая прошла в июне в «Золотых мозгах», как называют в народе здание Президиума РАН. Говорили о средствах защиты информации внутри российских ОС, делились секретами создания надежных программных сред. Это редкий шанс узнать подробности о киберзащите сложного ПО из первых рук. Мы побывали на конференции, выбрали пару интересных на наш взгляд докладов и хотим поделиться тезисами.

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

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

Вы можете найти полную запись выступлений и программу конференции на официальной странице OS Day, а мы пропустим речи и официоз и сразу перейдем к докладу Александра Дубинина из группы компаний «ЯДРО». Он рассказал, как повысить надежность программных сред при помощи виртуализации.

Практика создания надежных программных сред

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

Видеоверсия доклада: Александр Дубинин, ГК Yadro

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

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

Основные понятия в классической теории надежности

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

Детальное описание основных понятий в классической теории надежности

Отдельного внимания здесь заслуживает безотказность и простой принцип проектирования, про который часто забывают начинающие разработчики: KISS (акроним для Keep it simple, stupid — «Делай проще, тупица»).

Безотказность основывается на принципе: «Чем проще, тем надежнее»

Для обеспечения надежности на этапе проектирования Александр советует придерживаться Unix-Way, в частности, не создавать, как он их называет, «всемогутеров».

Обеспечение надежности на этапе проектирования

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

Примеры надежной архитектуры

«Обеспечить надежность при проектировании системы гораздо дешевле, чем потом лепить заплатки на готовое решение», — резонно утверждает Александр. На этапе разработки он рекомендует придерживаться практик Secure by Design и Security Development Lifecycle. Для минимизации кода стоит использовать кросс-платформенные системы и придерживаться режима проектирования «от простого к сложному». А главное — сразу тестировать свежереализованное.

Secure Development lifecycle:

1. Статический анализ кода: модульное тестирование, динамический анализ — как разрабатываемых, так и заимствованных компонентов, автоматизация и инструменты везде, где это возможно.
2. Сборочные кросс-платформенные системы.
3. Движение от простого к сложному.
4. Тестирование по мере реализации алгоритма.

А теперь к практике!

Как выяснилось, в ГК Yadro активно используют различные системы виртуализации.

Схемы гипервизоров: к первому типу относятся XEN и VMware ESX, ко второму: KVM, VirtualBox

По словам Александра, он больше любит работать с гипервизорами 1-го типа, потому что с точки зрения изоляции они обеспечивают большую надежность:

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

Изоляция и разделение доменов

В таких проектах, как Qubes OS и XOAR на базе гипервизора первого типа реализован еще один подход: изоляция и разделения доменов ввода/вывода.

Практика разделения доменов ввода/вывода

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

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

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

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

Виртуализация и FT/HA

Еще одна схема повышения безопасности на основе виртуализации основана на трансляции состояния виртуальной машины на соседний хост.

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

Контроль целостности

Еще один подход, на который обращает внимание Александр, — контроль целостности файлов, которым запрещено изменение. Для этого в Yadro используют IMA/EVM, являющиеся частью ядра, контроль со стороны гипервизора и контроль со стороны внешнего железа. Причем эти подходы компенсируют недостатки друг друга.

Примеры реализации контроля целостности

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

Вариант с использованием сопроцессора построен на механизме работы шины PCI Express и механизме bus mastering. Он подразумевает создание общего пространства между двумя железками и внешний контроль состояния памяти.

Средства защиты информации от уязвимостей в Astra Linux

Видеоверсия доклада: Владимир Тележников, РусБИТех-Астра

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

Режимы работы СЗИ в Astra Linux, называли в честь городов-героев и городов воинской славы

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

Защита от злоупотребления root-привилегиями

Один из самых интересных механизмов защиты Astra Linux — мандатный контроль целостности.

По сути, в архитектуру операционной системы встроен набор правил, по которым она изолирует друг от друга различные процессы и подсистемы. В системе предусмотрено 32 изолированных уровня целостности. С их помощью Astra Linux определяет, какие процессы имеют право на запись и вмешательство в работу других процессов. Эта система дополняет и расширяет обычные ограничения на запись в системные каталоги и обеспечивает защиту от непреднамеренного использования root-привилегий.

Пример использования механизма мандатного контроля целостности для безопасного запуска приложений

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

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

Пример использования механизма мандатного контроля целостности

Еще одна интересная деталь, по словам спикера, появилась в Astra совсем недавно. Теперь новые объекты наследуют метки безопасности у директорий, в которых они создаются.

Наследование уровней целостности при создании объектов в Astra Linux

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

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

Proof of concept

Возможности средств защиты Astra Linux по нейтрализации угроз спикер продемонстрировал на примере недавно нашумевшей уязвимости в Polkit (CVE-2021-4034). С ее помощью обычный пользователь может подменить системные компоненты и получить root-привилегии.

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

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

Мандатный контроль целостности — это не «серебряная пуля» от всех врагов, а лишь элемент комплексной защиты.

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