Как проверить AppArmor на Ubuntu Server?

Проверьте AppArmor командой aa-status с правами администратора. В штатной конфигурации команда показывает загруженные профили и число профилей в режимах enforce и complain. Если команды нет или профили не загружены, проверьте установленные пакеты, состояние службы и параметры загрузки ОС по документации для конкретного выпуска Ubuntu.

Можно ли включить SELinux и AppArmor одновременно?

Нет, не следует включать оба механизма самостоятельно. Возможность совместной работы LSM зависит от ядра, сборки и дистрибутива, включая порядок и совместимость модулей. Использовать SELinux и AppArmor параллельно можно только при документированной поддержке конкретного выпуска ОС и полного набора политик.

Что делать, если сервис работает без MAC, но получает отказ с ним?

Сначала подтвердите, что обычные права Linux позволяют операцию: проверьте владельца, группу, rwx и при необходимости ACL. Затем разберите отказ MAC. Для SELinux ищите AVC-события и определяйте домен процесса, тип объекта и требуемое действие. Для AppArmor ищите события DENIED в журнале ядра или системном журнале и сопоставляйте профиль, операцию и путь. Не считайте сам факт отказа ошибкой механизма защиты. Сервис может иметь доступ к каталогу по обычным правам, но не иметь разрешения на конкретный тип файла, сокет, порт, путь или запуск дочернего процесса. Исправляйте причину минимально: восстановите ожидаемую метку, используйте разрешённый путь или штатную конфигурацию приложения, добавьте узкое правило после анализа события. Если нужна диагностика нового сервиса, временно применяйте Permissive или complain, собирайте события при воспроизводимом сценарии и возвращайте блокирующий режим после проверки.

Можно ли оставить SELinux в Permissive или AppArmor в complain?

Нет, постоянным решением это не считается. Permissive и complain подходят только для ограниченной диагностики при внедрении, проверке нового сервиса или локализации отказа. Соберите события, исправьте метки, конфигурацию или правила и повторно проверьте сервис в Enforcing или enforce.

SELinux или AppArmor: какую систему MAC выбрать

На работающем Linux-сервере выбирать SELinux или AppArmor чаще всего не нужно: штатный механизм уже определён дистрибутивом, его пакетами и готовыми политиками. SELinux обычно является естественным выбором для RHEL-совместимых систем, а AppArmor — для Ubuntu Server и многих установок Debian. Менять этот слой стоит только при подтверждённой потребности, наличии поддерживаемой политики для сервиса и плане отката.

MAC дополняет обычные права Linux

Обычные права файлов — владелец, группа, rwx и ACL — относятся к дискреционному контролю доступа: владелец или привилегированный администратор может изменить разрешения. Мандатный контроль доступа, или MAC, добавляет обязательную системную политику для процессов и ресурсов. Владелец файла не может сам отменить это ограничение обычным chmod.

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

MAC не заменяет базовую защиту

SELinux и AppArmor не заменяют обновления, безопасную настройку учётных записей, sudo, firewall и аудит. Связанные меры собраны в статье Hardening Linux-сервера: чек-лист для Ubuntu, Debian и RHEL.

SELinux и AppArmor: сравнение моделей

Практические различия механизмов

Критерий	SELinux	AppArmor
Модель политики	Type Enforcement: правила связывают тип процесса с типами объектов и разрешёнными действиями.	Профили программ задают допустимые действия, пути, capabilities и другие ресурсы.
К чему привязано ограничение	К контекстам SELinux, в частности к типу процесса и метке объекта.	К профилю AppArmor, обычно выбранному по пути исполняемого файла; файловые правила также сопоставляются с путями.
Типичный штатный выбор	RHEL и его совместимые дистрибутивы обычно поставляют SELinux как штатный MAC-механизм.	Ubuntu Server обычно поставляется с AppArmor; Debian поддерживает AppArmor и в типичных современных установках он включён по умолчанию.
Режимы внедрения	Enforcing блокирует нарушения; Permissive регистрирует потенциальные отказы, но не блокирует их; Disabled отключает SELinux.	enforce блокирует нарушения профиля; complain в основном регистрирует их без блокировки.
Диагностика отказов	Ищут AVC-события в журналах аудита и сопоставляют домен, тип объекта и требуемое действие.	Ищут события `DENIED` AppArmor в журнале ядра или системном журнале и сопоставляют профиль, операцию и путь.
Нестандартное ПО	Трудозатраты зависят от наличия политики, меток файлов и портов, переходов доменов и требований приложения.	Трудозатраты зависят от полноты профиля, фактических путей, запускателей, дочерних процессов и изменений приложения.

SELinux принимает решение преимущественно по меткам: процесс работает в домене SELinux, а файлы, сокеты и другие объекты имеют контексты. Если файл скопирован в каталог с другим ожидаемым контекстом, получил иную метку или процесс запущен в другом домене, итоговое решение может измениться при неизменных uid, gid и chmod. Правила задаёт политика SELinux.

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

Какой механизм штатный у дистрибутива

Поддерживаемые выпуски RHEL используют SELinux; этот механизм также является штатным выбором в совместимых с RHEL системах, например Rocky Linux и AlmaLinux. Ubuntu включает и поддерживает AppArmor, поэтому вопрос «AppArmor Ubuntu Server» обычно означает настройку уже имеющегося слоя, а не поиск альтернативы. Debian также поддерживает AppArmor; его фактическое наличие и состояние зависят от выпуска, образа установки и выбранных пакетов.

Не включайте два механизма параллельно без поддержки ОС

Linux Security Modules допускает stacking модулей только в конфигурациях, предусмотренных ядром и сборкой ОС; состав, порядок и совместимость LSM зависят от ядра и дистрибутива. Это не является основанием самостоятельно включать SELinux и AppArmor одновременно. Используйте такую схему только при документированной поддержке конкретного выпуска ОС и всего набора политик.

Проверьте штатный механизм перед изменениями

Команды показывают активный механизм в типичной установке. Наличие пакета само по себе не доказывает, что политика загружена и применяется.

1
Проверьте SELinux
На RHEL-совместимой системе выполните getenforce, а при наличии утилиты — sestatus. Ожидаемый результат для защищённой штатной конфигурации — Enforcing. Permissive означает неблокирующую диагностику, Disabled — что SELinux не действует; сначала выясните причину и план возврата к Enforcing, а не устанавливайте AppArmor как замену.
2
Проверьте AppArmor
На Ubuntu или Debian выполните aa-status с правами администратора. Ожидаемый результат — сведения о загруженных профилях и числе профилей в режимах enforce и complain. Если команда отсутствует или загруженных профилей нет, проверьте установленные пакеты, состояние службы и параметры загрузки ОС по документации именно вашего выпуска.
3
Сопоставьте механизм с сервисом
Определите пакет сервиса, его исполняемый файл, рабочие каталоги, нестандартные порты и способ запуска. Затем проверьте, есть ли готовая политика или профиль в пакетах дистрибутива либо в документации поставщика приложения. Если готовой политики нет, оцените создание и регрессионную проверку собственной до ввода сервиса в эксплуатацию.

Версии и интерфейсы

Состав пакетов, состояние по умолчанию, названия команд, расположение политик и доступные диагностические интерфейсы зависят от дистрибутива, его выпуска, образа ОС, ядра и версии пакетов. Для SELinux в RHEL-экосистеме обычно используются утилиты из пакетов политики и средства аудита; для AppArmor — aa-status и утилиты управления профилями. Перед изменением сверяйтесь с официальным руководством вашего вендора или проекта.

Почему приложение работает без MAC, но получает отказ с ним

Права Linux отвечают на вопрос, может ли данный пользователь или группа обратиться к объекту. MAC задаёт дополнительный вопрос: разрешено ли именно этому ограниченному процессу выполнять эту операцию над этим объектом. Например, сервис может запускаться от пользователя www-data и иметь права на чтение каталога, но профиль AppArmor не разрешает указанный путь; либо процесс веб-сервера в SELinux-домене не имеет разрешения для типа файла или сокета.

Корректное исправление — установить предусмотренную политикой метку, разрешённый путь, штатную настройку приложения или узкое правило после разбора события. Не следует считать любой отказ доказательством ошибки SELinux или AppArmor и не следует исправлять его постоянным отключением MAC. Разбор AVC и работа с контекстами описаны в статье SELinux на сервере: Enforcing, контексты и устранение отказов; для профилей — в статье AppArmor на сервере: профили, enforce и диагностика отказов.

Как оценить сопровождение стандартного и нестандартного сервиса

Стандартный пакет дистрибутива. Сначала проверьте, поставляет ли ОС готовую политику или профиль и работает ли сервис в штатных путях и с обычной схемой запуска. Это обычно требует меньше сопровождения, чем замена MAC-механизма.
Сервис с изменёнными каталогами или портами. Оцените каждое отклонение: отдельные пути данных и логов, PID-файлы, сокеты, TLS-ключи, временные каталоги, сетевые порты, плагины и задания по расписанию. Чем больше отклонений, тем больше проверок после обновлений.
Стороннее или собственное приложение. Зафиксируйте исполняемые файлы, процессы-потомки, читаемые и записываемые пути, сетевые обращения и необходимый доступ к системным ресурсам. Если готовой политики нет, проверяйте собственную политику отдельно от рабочей среды.
Обновление приложения. В план проверки включите новые пути, бинарные файлы, плагины и изменения способа запуска. Политика, достаточная для одной версии приложения, не обязательно подходит другой.

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

Когда допустимы Permissive и complain

SELinux Enforcing блокирует действия, запрещённые активной политикой; Permissive не блокирует потенциальные нарушения, но записывает AVC-события, если их не подавляют правила dontaudit; Disabled выключает SELinux. У AppArmor режим enforce блокирует нарушения профиля, а complain обычно записывает нарушения без блокировки; явные правила deny остаются исключением.

Используйте Permissive или complain только на ограниченный период: при первичном внедрении, проверке нового сервиса или локализации отказа.
Соберите события при воспроизводимом сценарии работы приложения: запуск, обработка запросов, ротация журналов, резервное копирование и плановые задачи.
Скорректируйте точечно конфигурацию, метки или профиль и повторите проверку в блокирующем режиме.
Зафиксируйте владельца изменения, срок диагностического режима и критерий возврата в Enforcing или enforce.

Неблокирующий режим не является постоянным исправлением

Permissive и complain помогают собирать диагностические события, не блокируя большинство действий, которые политика иначе запретила бы. При этом правила dontaudit могут подавлять AVC-события SELinux, а явные правила deny AppArmor продолжают действовать в complain. Постоянное отключение SELinux, перевод всех профилей в complain или удаление профилей убирает слой защиты вместо устранения причины. Переход между SELinux и AppArmor — отдельное изменение ОС: оцените совместимость, зависимости загрузки, политики сервисов, окно работ и проверенный откат.

Термины в статье

AppArmor: AppArmor — система мандатного контроля доступа Linux, ограничивающая программы профилями; профиль обычно выбирается по пути исполняемого файла, а файловые правила сопоставляются с путями.
Linux Security Modules: Linux Security Modules — каркас ядра Linux для подключения модулей контроля доступа, перехватывающих операции с объектами системы по заданным политикам.
SELinux: SELinux — подсистема мандатного контроля доступа Linux, применяющая политики и метки безопасности для ограничения действий процессов сверх обычных прав Unix.
Type Enforcement: Type Enforcement — модель мандатного контроля доступа, в которой правила разрешают действия процессов определённых типов над объектами заданных типов.
Дискреционный контроль доступа: Дискреционный контроль доступа — модель авторизации, в которой владелец объекта назначает права пользователям и группам через разрешения или списки ACL.
Домен SELinux: Домен SELinux — тип безопасности процесса в политике SELinux, определяющий набор разрешённых действий процесса над объектами с заданными метками.
Контекст SELinux: Контекст SELinux — метка безопасности объекта или процесса, содержащая пользователя SELinux, роль, тип и уровень MLS/MCS; политика учитывает её при контроле доступа.
Мандатный контроль доступа: Мандатный контроль доступа — модель разграничения доступа, в которой операции разрешаются обязательной системной политикой, не изменяемой владельцем ресурса.
Политика SELinux: Политика SELinux — набор правил мандатного контроля доступа, задающий допустимые действия доменов над объектами с метками безопасности.
Профиль AppArmor: Профиль AppArmor — набор правил мандатного контроля доступа, определяющий допустимые для конкретной программы операции с файлами, Linux capabilities и другими ресурсами.
Путевой контроль доступа: Путевой контроль доступа — способ задания правил авторизации, при котором защищаемый ресурс выбирается по пути, например по пути URI или имени в файловой системе.
Режим Permissive: Режим Permissive — режим SELinux, в котором потенциальные отказы не блокируют операции и фиксируются как AVC, если не подавлены правилами dontaudit; права Linux продолжают действовать.
Режим complain: Режим complain — режим профиля AppArmor, в котором потенциальные нарушения регистрируются, но обычно не блокируются; исключение составляют явные правила deny.
Режим enforce AppArmor: Режим enforce AppArmor — режим принудительного применения профиля контроля доступа, в котором действия процесса, запрещённые профилем, блокируются и фиксируются в журнале.