Как AppArmor и SELinux по-разному решают задачу обязательного контроля доступа в Linux

Каждый системный администратор рано или поздно сталкивается с неудобной истиной: стандартные права доступа DAC держат дверь закрытой ровно до тех пор, пока у атакующего нет привилегированного процесса. А когда есть, дверь больше не существует. Именно эту пробоину в классической модели безопасности Linux закрывают AppArmor и SELinux, реализуя обязательный контроль доступа (MAC, Mandatory Access Control). Оба встроены в ядро через фреймворк Linux Security Modules, оба ограничивают процессы независимо от традиционных разрешений. Но за внешним сходством скрываются принципиально разные философии, и понять эту разницу важно раньше, чем выбирать инструмент.

Как история каждой системы определила её характер

SELinux вырос из исследований Агентства национальной безопасности США, которое с начала 1990-х разрабатывало операционные системы для работы с секретными данными. Многолетние проекты DTMach и DTOS завершились в декабре 2000 года публичным выпуском SELinux под лицензией GPL, а в 2003-м код вошёл в ядро Linux 2.6. Когда представители АНБ предложили включить SELinux напрямую в ядро версии 2.5, Линус Торвальдс отказал, не желая отдавать предпочтение одному решению перед другими. Так появился фреймворк LSM, который дал жизнь конкуренции между несколькими модулями безопасности.

AppArmor шёл принципиально другим путём. Компания Immunix разработала его в конце 1990-х под именем SubDomain с одной центральной идеей: защита не должна мешать работе. В 2005 году Novell купила Immunix, переименовала SubDomain в AppArmor и открыла исходный код под GPL. В 2007-м Novell уволила почти всю команду разработчиков, включая основателя проекта Криспина Коуэна, и проект оказался на краю. Его подхватила Canonical, встроив AppArmor в Ubuntu 7.10, и с тех пор эта компания остаётся главной движущей силой его развития.

Это различие в происхождении многое объясняет на практике. SELinux создавался для правительственных и военных систем, где безопасность важнее удобства. AppArmor рождался как прагматичная альтернатива для тех, кто хочет реальную защиту без трёхнедельного курса обучения.

Метки и пути как две разные картины мира

Ключевое техническое различие лежит в том, как системы вообще смотрят на объекты в операционной системе.

SELinux работает с метками. Каждый файл, процесс, сокет и порт в системе получает контекст безопасности в формате user:role:type:level. Когда процесс запрашивает доступ к файлу, ядро сверяет метки через кэш векторов доступа (AVC). Если политика не разрешает это взаимодействие явно, следует отказ без исключений. SELinux сначала запрещает всем и лишь потом открывает доступ тем, у кого правильный контекст.

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

Из этого различия вытекают важные практические следствия. SELinux требует поддержки расширенных атрибутов (xattr) в файловой системе, именно через них хранятся метки. Файлы на NFS-разделах без поддержки xattr останутся без контекста и почти всегда получат отказ в доступе. AppArmor никаких требований к файловой системе не предъявляет, что делает его единственным разумным выбором в гетерогенных окружениях с tmpfs, FUSE-томами и сетевыми хранилищами.

В AppArmor допускаются символы подстановки в правилах путей. Одна строка вида /home/*/documents/** покрывает документы всех пользователей сразу. SELinux в аналогичной ситуации требует явного перечисления типов или создания нового типа с соответствующей политикой. Это наглядная разница между сотней понятных правил и тысячами правил, дающих точный контроль над каждым системным вызовом.

Зато у путевого подхода есть принципиальная уязвимость. Если атакующий переименовал файл или переместил его в другой каталог, профиль AppArmor перестаёт его ограничивать. SELinux в таком сценарии невозмутим: метка прикреплена к inode, и куда бы файл ни переехал, его контекст безопасности остаётся с ним.

SELinux умеет то, чего AppArmor принципиально не может

SELinux поддерживает три концептуальных слоя контроля: Type Enforcement, RBAC и MLS/MCS.

Type Enforcement определяет, какой тип процесса с каким типом файла может взаимодействовать, и порождает тысячи точных правил. Политика targeted, используемая по умолчанию в RHEL и Fedora, применяет TE к определённому набору процессов. Политика strict охватывает всё без исключений.

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

AppArmor поддерживает только Type Enforcement. Ни полноценного RBAC, ни MLS, ни MCS. Это принципиальное ограничение делает его непригодным для сред, где требуется строгое разделение данных по уровням классификации или гарантированная межконтейнерная изоляция.

Зато у AppArmor есть режим обучения, который называется complain mode. В нём нарушения профиля фиксируются в логах, но не блокируются. Запускаешь приложение в реальных условиях, смотришь его поведение, скармливаешь лог утилите, и профиль почти готов. SELinux предлагает аналогичный инструмент, который читает отказы из лога аудита и генерирует модули политики, однако порог входа там существенно выше.

Базовый цикл диагностики в каждой системе выглядит примерно так:

SELinux:

# Проверить статус системы
sestatus

# Найти отказы в логе аудита
ausearch -m avc -ts recent

# Получить человекочитаемое объяснение отказа
sealert -a /var/log/audit/audit.log

# Сгенерировать модуль политики из отказов
audit2allow -M my_policy -i /var/log/audit/audit.log

# Восстановить контекст безопасности файла
restorecon -v /путь/к/файлу

AppArmor:

# Проверить статус профилей
aa-status

# Перевести профиль в режим обучения
aa-complain /usr/sbin/nginx

# Создать новый профиль в интерактивном режиме
aa-genprof /usr/sbin/my_app

# Обновить профиль по логам нарушений
aa-logprof

Контейнерная изоляция и облачные платформы

SELinux здесь обладает структурным преимуществом. MCS-метки позволяют разделить контейнеры на уровне ядра: каждый получает уникальную комбинацию категорий, и политика гарантирует, что процесс одного контейнера не прочитает файл другого, даже если оба работают от имени одного пользователя. OpenShift и Kubernetes-дистрибутивы на базе Fedora и RHEL поставляются с готовыми SELinux-политиками для контейнерной изоляции именно по этой причине.

AppArmor в Docker применяется через профили, привязанные к конкретным образам: они ограничивают то, что контейнер может делать с хостовой системой. Это работает и обеспечивает реальную защиту хоста. Но гарантированной межконтейнерной изоляции через MCS AppArmor дать принципиально не может. Если нужно просто ограничить привилегии контейнера, AppArmor справится. Если нужна уверенность в том, что два контейнера не увидят данные друг друга даже при компрометации общих ресурсов, нужен SELinux.

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

Производительность, диагностика и человеческий фактор

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

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

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

Именно поэтому многие администраторы, столкнувшись с SELinux впервые, делают то, что делать категорически нельзя: отключают принудительный режим и забывают о нём. Отключённый SELinux это не безопасность, а иллюзия безопасности, что куда хуже её отсутствия.

Какой инструмент выбирать и почему этот вопрос не имеет единственного ответа

Дистрибутивы давно проголосовали практикой. RHEL, Fedora, Rocky Linux, AlmaLinux используют SELinux без альтернатив. Ubuntu держится за AppArmor по умолчанию. OpenSUSE Tumbleweed в феврале 2025 года перешла с AppArmor на SELinux, признав, что для серверных сред гранулярность важнее простоты настройки. Это не случайные решения, а осознанный выбор под конкретную аудиторию.

Для рабочих станций, небольших серверов и сред разработки, где администратор один и время дорого, AppArmor остаётся разумным и честным выбором. Для корпоративных инфраструктур, систем с требованиями PCI DSS или HIPAA, мультитенантных облачных платформ и сред с требованием гарантированной изоляции SELinux оправдывает каждый час, потраченный на его освоение.

Вопрос "что лучше" здесь некорректен по существу. SELinux при правильной настройке обеспечивает уровень защиты, который AppArmor структурно не может повторить. AppArmor реально работает и реально используется, а не отключается в первые же сутки. Включённый AppArmor надёжнее отключённого SELinux: всегда, в любой инфраструктуре, без единого исключения. Безопасность, которую никто не поддерживает, существует только на бумаге.