Мандатное управление доступом

Изначально MAC был тесно связан с многоуровневой безопасностью (MLS) как средство защиты секретной информации США. Trusted Computer System Evaluation Criteria (TCSEC, также известная как Оранжевая книга) дала первоначальное определение MAC как «средство ограничения доступа к объектам на основе чувствительности (обозначаемой ярлыком) информации, содержащейся в объектах, и формального допуска (clearance) субъектов к доступу к такой информации»^[2]. Первые реализации MAC, такие как SCOMP компании Honeywell, SACDIN ВВС США, Blacker АНБ США и MLS LAN компании Boeing, были ориентированы на MLS для защиты секретных военных данных с жёстким обеспечением исполнения.

Термин «мандатный» приобрёл особое значение в связи с применением в военных системах. Здесь MAC означает чрезвычайно высокий уровень надёжности, при котором контрольные механизмы способны противостоять любым попыткам обхода и выполнять доступ, предписанный, например, правительственным указом (Executive Order 12958). Такая строгость необязательна для коммерческих решений. Позволительны только такие механизмы, что гарантируют почти абсолютное соблюдение политики безопасности. Подобные требования часто считаются неисполнимыми теми, кто не знаком с высоко гарантированными системами, и действительно реализуемы лишь с большими трудностями.

В некоторых системах пользователи могут самостоятельно назначать доступ другим пользователям — при таком подходе все пользователи имеют допуск ко всем данным. Это не обязательно для MLS-систем: если есть субъекты, которым доступ к некоторым данным должен быть запрещён, система обязана надёжно обеспечивать исполнение MAC. При наличии разных уровней классификации данных и допуска пользователей необходим количественно различимый уровень прочности механизма. Например, для среды с классификацией «Совершенно секретно» (Top Secret) и неквалифицированными пользователями требуется больший уровень прочности, чем для среды с уровнем «Секретно» и пользователями с хотя бы «Конфиденциальным» (Confidential) уровнем допуска. Для обеспечения единообразия и устранения субъективности был проведён научный анализ и оценка рисков, приведшие к стандарту CSC-STD-004-85^[3]. Были выделены два относительно независимых компонента надёжности: уровень гарантии и функциональность, каждому из которых присваивалась количественная оценка, обеспечивая доверие к наделённым ею сертификациям.

Стандарт Common Criteria^[4] основан на этих положениях, сохраняя уровни гарантии как EAL и спецификации функциональности как Профиль защиты. Однако из двух компонентов надёжности в полной мере были сохранены лишь уровни EAL. Так, уровень TCSEC C2^[5] (не относящийся к MAC) был в Common Criteria реализован как CAPP^[6]. Профили защиты для MLS (например, MLSOSPP, аналогичные B2)^[7] менее конкретны по сравнению с B2; они следуют целям MLS, но концентрируются на задачах, а не механизмах. Это увеличивает гибкость сертификации, но может снижать унифицированность реализации и ослаблять требования к безопасности продуктов. Поэтому технические детали профиля защиты принципиально важны для корректного выбора средств.

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

Некоторые реализации MAC, такие как проект Blacker компании Unisys, были сертифицированы в конце XX века для разделения данных уровня Top Secret и неклассифицированных. Со временем эти технологии устарели и не обновлялись; сегодня нет реализованных продуктов с уровнем надёжности, полностью соответствующим TCSEC. Однако существуют менее строгие решения.

Начиная с Windows Vista и Server 2008, компания Microsoft внедрила Обязательный контроль целостности (Mandatory Integrity Control, MIC) в Windows, добавив «уровни целостности» (Integrity Level, IL) для процессов. Их цель — ограничить доступ ненадёжных процессов к чувствительной информации. MIC определяет пять уровней целостности: низкий, средний, высокий, системный и Trusted Installer^[8]. По умолчанию процессы запускаются с средним уровнем. Повышенные процессы получают высокий уровень^[9]. Дочерние процессы наследуют уровень родителя, однако он может установить им более низкий IL. Например, Internet Explorer 7 запускает свои подпроцессы с низким уровнем целостности. Windows регулирует доступ к объектам на основе IL. Именованные объекты, включая файлы, ключи реестра Windows, процессы и потоки, содержат в ACL запись минимального IL процесса для использования объекта. MIC обеспечивает право на запись или удаление объекта только тогда, когда IL процесса не ниже IL объекта. Также для защиты чувствительной информации в памяти процесс не может открывать для чтения процессы с более высоким уровнем IL^[10].

Компания Apple Inc. внедрила реализацию фреймворка TrustedBSD в своих операционных системах iOS и macOS^[11]. (Слово «mac» в «macOS» является сокращением от «Macintosh» и не связано со словом «mandatоry» в «mandatory access control».). Функция командной строки sandbox_init предоставляет высокоуровневый интерфейс для ограниченного контейнирования^[12].

Начиная с версии 5.0 операционная система Android корпорации Google использует SELinux для реализации мандатной модели безопасности поверх своей традиционной модели DAC на базе UID^[13].

Linux и многие другие Unix-совместимые системы реализуют MAC на процессорном (многоуровневые кольца), дисковом и оперативном уровнях. Несмотря на то, что традиционное управление привилегиями не всегда эффективно, Linux с 1990-х годов получил репутацию более безопасной и стабильной системы по сравнению с альтернативами вне Unix-среды. Основные модули безопасности Linux, реализующие MAC: SELinux, AppArmor и TOMOYO Linux^[14].

SELinux — одна из первых и наиболее популярных реализаций MAC в Linux — была разработана АНБ США и выпущена в открытое сообщество в 2000 году^[15]. Этот модуль включён по умолчанию в ядро Linux с версии 2.4, а также в Android 5.0+ и дистрибутивы Red Hat/Fedora^[16]. SELinux обеспечивает мощный, детализированный контроль, что делает его пригодным для высокозащищённых сред, однако высокая сложность факторов управления традиционно затрудняет его освоение^[14].

TOMOYO Linux — облегчённая реализация MAC для Linux и Embedded Linux, разработанная компанией NTT Data Corporation. Включена в основную ветку ядра Linux с версии 2.6.30 (июнь 2009)^[17]. В отличие от подходов с метками (label-based), как в SELinux, TOMOYO Linux реализует pathname-based MAC, определяя домены безопасности по истории вызова (цепочке процессов); политика формулируется в терминах путей к файлам. TOMOYO Linux ввела режим «обучения», когда все обращения фиксируются для автоматической генерации политики MAC: это облегчает последующую настройку правил.

AppArmor реализует MAC с использованием интерфейса Linux Security Modules с ядра 2.6; включён в SUSE Linux и Ubuntu 7.10. LSM предоставляет ядровой API, позволяющий использовать различные модули (DAC ACL, access-control lists). AppArmor применим не ко всем программам и включён в ядро Linux начиная с версии 2.6.36^[18].

RSBAC (Rule Set Based Access Control) Амона Отта — фреймворк для ядер Linux с несколькими модулями политики, включая мандатную модель доступа. Одна из целей RSBAC — достижение (устаревшего) уровня Orange Book B1; используемая модель примерно соответствует Unix System V/MLS 1.2.1 (разработана в 1989 году Национальным центром компьютерной безопасности США, классификация B1/TCSEC). RSBAC требует ряд патчей к ядру, поддерживаемых владельцем проекта.

Smack (Simplified Mandatory Access Control Kernel) — модуль безопасности ядер Linux, реализующий набор простых правил MAC для защиты данных и процессов от недоверенных воздействий^[19]. Включён в основное ядро Linux с версии 2.6.25^[20].

grsecurity — патч для ядра Linux, реализующий MAC (точнее — модель RBAC). Реализация grsecurity не использует LSM^[21].

ОС Astra Linux, разрабатываемая для Вооружённых сил России, содержит собственную реализацию мандатного управления доступом^[22].

FreeBSD поддерживает мандатное управление доступом в рамках проекта TrustedBSD (с версии FreeBSD 5.0, по умолчанию включено с версии 7.2). Архитектура расширяема — различные модули реализуют политики, такие как модель Biba или многоуровневая безопасность.

Trusted Solaris (Sun) реализует механизм мандатного, обеспечиваемого на уровне системы управления доступом, при котором Clearance и label используются для реализации политики безопасности. Однако наличие механизма работы с ярлыками не гарантирует надёжную работу в режиме MLS: возможности доступа к ярлыкам и контролирующим механизмам недостаточно защищены от нарушений в системной области, поддерживаемой ядром. Запуск программ пользователя происходит в сочетании с ярлыком безопасности сессии. Доступ к информации, программам и устройствам фактически контролируется слабо.