Русский бронированный Debian. Как устроена новая модель управления доступом в Astra Linux SE

Операционные системы сегодня — это не просто набор служебных функций, который позволяет компьютеру работать. Операционки стали играть огромную роль в мире потребительской электроники: Microsoft приспосабливает Windows для всех возможных устройств, Apple экспериментирует с интерфейсом мобильных и десктопных систем, Google развивает Android и одновременно превращает в операционную систему Chrome.

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

Есть и еще одна область, в которой защита превыше всего, — это ОС для государственных и военных нужд. Это еще один параллельный мир операционных систем — безумно консервативный, но и в нем существует прогресс. Причем не только за рубежом, но и у нас. Показательный пример — это дистрибутив Astra Linux SE.

Пять лет. Полет нормальный

Astra Linux — не единственный российский защищенный дистрибутив. Есть и другие, и все они успешно прошли проверку в органах сертификации и нашли свои рыночные ниши. Детище НПО «РусБИТех» — не исключение. Astra Linux SE с завидной регулярностью получает сертификаты соответствия в системах сертификации ФСТЭК, Министерства обороны и ФСБ. Действующие на настоящий момент версии имеют «срок годности» до 2018 года.

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

Другие статьи в выпуске:

Xakep #200. Тайная жизнь Windows 10

• Содержание выпуска
• Подписка на «Хакер»-60%

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

Первый релиз Astra Linux вышел в конце 2009 года. С тех пор дистрибутив совершенствуется, следуя за основной веткой Debian, но при этом разработчики не забывают о главном — повышенной безопасности. Предприятие «РусБИТех» неплохо оснащено научными кадрами и при этом ведет активное сотрудничество с вузами и исследовательскими институтами, которые специализируются на информационной безопасности.

Черты, которые делают Astra Linux 1.4 уникальным, относятся как раз к этой теме. В фирменной подсистеме безопасности PARSEC используется формальная модель разграничения доступа. Она была разработана в Институте криптографии, связи и информатики Академии ФСБ России, а в оценке качества принял участие Центр верификации ОС Linux Института системного программирования РАН. Реализация этой модели в Astra Linux SE ведется поэтапно, и в версии 1.4 добавлена большая ее часть, но еще не последняя.

MAC в LSM. Далеко не фастфуд в управлении доступом

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

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

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

Задача любой модели разграничения доступа — определить, разрешить (allow) доступ к тем или иным объектам для тех или иных субъектов (субъект-сессий) или отказать (deny) в нем в соответствии с правилами. Если коротко, любая модель разграничения доступа задает некоторые отношения между субъектами и объектами доступа.

Базовая (как говорится, «из коробки») модель безопасности в GNU/Linux — это DAC, дискреционная модель доступа (discretionary access control). Она представляет собой комбинацию произвольного управления доступом (субъект-субъектная модель) и доступа на основе списков (ACL — Access Control Lists).

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

В общем виде модель DAC в GNU/Linux соответствует «виртуальному» стандарту POSIX ACL (настоящая стандартизация POSIX.1e и POSIX.2с была свернута в силу безбрежности стандартизуемой предметной области) и для большинства случаев вполне подходит на роль «диспетчера доступа» субъектов к объектам.

Однако защищенные операционные системы — это не «большинство случаев». Одно из важных требований, предъявляемых к ним органами сертификации, — это реализация принудительного контроля доступа, который устраняет определенный волюнтаризм модели DAC. Как и в некомпьютерном секретном делопроизводстве, модель принудительного управления доступом основана на сопоставлении меток конфиденциальности, присвоенных объектам доступа, с официальным разрешением (допуском, мандатом) субъекта. Именно это «официальное разрешение» (мандат) дало такой модели название MAC (Mandatory access control) — мандатное управление доступом.

В GNU/Linux попытки расширения DAC-модели безопасности MAC-моделью предпринимались с 2001 года. Именно тогда АНБ США показало первую версию SELinux с реализацией мандатного управления доступом на основе формальной модели MLS (Multilevel Security). Было предложено включить MLS в состав ядра версии 2.5. Благо сообщество разработчиков Linux такое решение отвергло. Наряду с SELinux похожие реализации MAC-модели разрабатывались в рамках проекта AppArmor и, позже, — в Smack, TOMOYO и других. С какой стати отдавать предпочтение какому-то одному из них?

Вместо жесткой интеграции MAC-модели в состав ядра было принято соломоново решение: использовать расширение модели безопасности GNU/Linux. Она продолжит базироваться на модели DAC, но с использованием особых модулей ядра. В них можно реализовать какой угодно вариант модели управления доступом. Это решение было претворено в жизнь в виде фреймворка LSM (Linux Security Modules), который официально включили в ядро Linux 2.6.

Идея LSM проста. На ключевые с точки зрения управления доступом функции ядра навешивается совокупность «крючков» — хуков (hooks). Они представляют собой интерфейсы подключения обработчиков из модуля LSM, которые вызываются в том случае, если нужен контроль доступа. То есть фреймворк LSM предоставляет разработчику модуля LSM возможность перехвата управления в ходе выполнения тех участков кода ядра, которые отвечают за реализацию доступа субъектов к объектам.

INFO

В ядро новой версии Astra Linux SE включен известный патч безопасности PaX, который обеспечивает возможность тонкой настройки разрешений для приложений при их работе со страничной памятью.

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

Фреймворк LSM не заменяет модель DAC — она остается «первой линией обороны». Обработка хуков LSM начинается только после успешного прохождения контроля доступа по линии DAC. Такая двухъярусность позволяет не перегружать функциями безопасности те системы, где это не нужно. Там можно попросту не использовать LSM.

Безопасность SELinux базируется как раз на модулях LSM, равно как все остальные рассмотренные выше проекты, которые реализуют мандатное управление доступом. Подсистема безопасности PARSEC, функционирующая в составе Astra Linux SE, — это тоже модуль LSM. И даже не один.

XPARSEC

Подсистема безопасности PARSEC в Astra Linux SE 1.4 содержит модуль XPARSEC, благодаря которому сервер X.Org получает возможность определять привилегии клиента X.Org (программы с графическим интерфейсом) и передавать их с использованием модифицированного X-протокола менеджеру окон Fly-wm. Тот выполняет привилегированные операции во время запуска клиента X.Org с различными мандатными контекстами. При этом на рабочем столе Fly отображается:

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

Контроль доступа, контроль целостности и роли

Поскольку Astra Linux вовсю используется в разных проектах, связанных с обработкой информации различных уровней конфиденциальности, у разработчиков уже есть статистика, по которой можно судить о корректности реализации модели управления доступом. Не менее важны исследовательские работы, в которых формировались модели нарушителей в рамках известных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures).

Проверке подверглись известные «проблемы» модели Белла — Лападулы. К примеру, деклассификация — когда пользователь с высоким уровнем конфиденциальности случайно или намеренно помещает данные из объекта с соответствующей мандатной меткой в объект с меткой более низкого уровня. Или нарушение логики доступа к данным при обработке потока информации в распределенной среде.
Моделировалась и проблема компрометации субъекта доступа, в ходе которой повышается уровень его привилегий (включая получение привилегий PARSEC). В результате можно получить возможность управлять доступом к защищаемой информации.

Очевидное решение таких проблем — это модификация формальной модели управления доступом. В случае Linux это делается добавлением модулей LSM, которые реализуют систему PARSEC. Ее основой стала мандатная сущностно-ролевая ДП-модель. Разработка ведется в рамках научной школы в Институте криптографии, связи и информатики Академии ФСБ России.

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

Кардинальное отличие мандатной сущностно-ролевой ДП-модели от «классики» MAC — это объединение мандатного и ролевого управления доступом. При этом традиционный подход (уровни конфиденциальности, категории безопасности) мандатной модели в ней усиливается применением мандатного же контроля целостности (MIC, Mandatory Integrity Control) — механизма, который нашел широкое применение в семействе операционных систем Windows, начиная с релизов Vista и Server 2008.

Фактически управление целостностью (integrity) правильнее называть управлением уровнем доверия. К традиционной проверке целостности данных (например, на основе подсчета их контрольных сумм) механизм MIC отношения не имеет. Назначаемые объектам и субъектам доступа уровни доверия дополняют традиционную модель управления доступом и гарантируют, что субъекты с низким уровнем целостности (IL — Integrity Level) не могут влиять на объекты с более высоким уровнем целостности.

Реализация мандатной сущностно-ролевой модели в Astra Linux SE 1.4 поддерживает наличие двух уровней целостности: высокий (hi) и низкий (low). Этого достаточно для разделения субъектов и объектов доступа на доверенные и недоверенные. При этом переменная, которая определяет значение IL, может принимать одно из 255 значений. Это означает, что в последующих реализациях модели может появиться более чем один уровень целостности. Подобный подход используется в модели MIC операционных систем Windows, поддерживающей пять (от untrusted до system) значений IL.

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

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

Что дает учет иерархии сущностей? Например, совместно с моделями MAC и MIC он позволяет определять правила размещения обычных объектов-сущностей с разными мандатными метками и уровнями IL в сущности-контейнере с определенными мандатной меткой и уровнем IL. Именно эта возможность и используется в текущей реализации сущностно-ролевой модели путем добавления к DAC-, MAC- и MIC-атрибутам директорий (напомним, что это — сущности-контейнеры) дополнительных атрибутов ccnr и ccnri. Они ограничивают возможность размещения в контейнерах объектов с мандатными метками и уровнями целостности, которые превышают таковые у самой директории.

Чтобы создать дочерний объект в отмеченных подобным образом директориях, даже с мандатными метками и уровнями IL ниже, чем у «родителя», субъект должен иметь соответствующие PARSEC-привилегии. Равно как и для установки ненулевого значения указанных атрибутов. При этом установка этих атрибутов не мешает просмотру объектов внутри директории.

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

Реализовав в LSM-модулях PARSEC мандатную сущностно-ролевую ДП-модель, разработчики не забыли и о средствах ее администрирования. Ведь набор утилит мандатного управления доступом в Astra Linux SE 1.3 был ориентирован на традиционную MAC-модель и не учитывал рассмотренные выше новшества.

В версии 1.4 появилась совокупность утилит pdp-, которые поддерживают просмотр и модификацию как традиционных MAC-атрибутов (уровни и категории), так и MIC-атрибута (уровни целостности) и дополнительных атрибутов (ccnr, ccnri, ehole). Впрочем, утилиты из предыдущей версии никуда пока не делись и применяются, чтобы облегчить администраторам уже функционирующих информационных систем миграцию субъектов и объектов доступа на новую модель.

Распространение абстракции «сущность» не только на объекты доступа, но и на роли, реализуемые субъектами, позволяет применить подобный подход и к иерархии «роль-контейнер» — «дочерняя роль». Правда, в реализации модели для Astra Linux SE 1.4 gjkysq переход к ролевому управлению не выполнен (сущности-контейнеры «административная роль» и «индивидуальная роль» еще пусты).

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

Следует еще задать вот какой вопрос: корректна ли новая, достаточно сложная и для понимания, и для реализации модель управления доступом? Не несет ли она на логическом уровне возможностей для несанкционированного доступа? Достоинство Astra Linux SE здесь в том, что корректность его решений проверяет научное сообщество. В частности, в процессе занят Центр верификации ОС Linux Института системного программирования РАН — там разрабатываются тесты и технологии тестирования как модулей ядра Linux, так и в целом инфраструктуры LSB (Linux System Base).

Так, Центром в рамках проекта Linux Deductive Verification на основе методологии дедуктивной верификации последовательных программ был разработан набор свободно распространяемых инструментов верификации — Astraver Toolset 1.0. Они помогают убедиться в корректности реализации LSM-модулей подсистемы PARSEC, которые поддерживают новую мандатную сущностно-ролевую модель. Они же помогут тестировать и будущие версии Astra Linux SE.

Выводы

К отечественным системным программным разработкам, особенно если они ведутся на основе опенсорсных проектов, зачастую относятся с изрядной долей снисхождения. Мол, сложно ли? Любой сможет взять отовсюду понемногу и сделать нечто, выдаваемое за свое. Возможно, иногда так и есть. Но только не в области операционных систем специального назначения. Их разработка скрупулезна, а сертификация проходит не для галочки. Именно такой подход продемонстрирован в Astra Linux SE 1.4, и именно его можно ожидать в последующих версиях этой операционной системы специального назначения.

WWW

• Полный перечень изменений, внесенных в дистрибутив версии 1.4 Astra Linux SE
• Патент на способ реализации мандатной сущностно-ролевой ДП-модели
• Презентация адаптации мандатной сущностно-ролевой ДП-модели к условиям функционирования ОС Linux на конференции «РусКрипто’2013»
• Сайт Центра верификации ОС Linux Института системного программирования РАН