SELinux vs AppArmor: как выбрать политику безопасности для Linux-сервера

Представьте ситуацию: вы настроили все права доступа в Linux, убрали лишние сервисы и закрыли порты. Но однажды ночью веб-сервер падает с ошибкой «Permission denied», хотя файлы на месте и владелец правильный. Знакомо? Скорее всего, виновник не права POSIX, а механизм принудительного контроля доступа (MAC). В мире серверного администрирования два главных игрока здесь - SELinux и AppArmor. Они работают по разным принципам, имеют разную сложность настройки и подходят под разные задачи. Разберемся, чем они отличаются и что выбрать именно вам.

Ключевые выводы

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

Как устроена модель безопасности в Linux

В классической модели Unix безопасность строится на трех компонентах: владелец файла, группа и другие пользователи. Это называется DAC (Discretionary Access Control) - дискреционный контроль доступа. Проблема в том, что если приложение получает права root, оно может делать практически всё, что угодно. Именно поэтому появились механизмы MAC (Mandatory Access Control), которые ограничивают действия процессов независимо от их владельца.

SELinux был разработан Национальной лабораторией Лос-Аламоса и интегрирован в ядро Linux начиная с версии 2.6. Он присваивает каждому объекту системы (файлу, процессу, сокету) метки безопасности. Эти метки определяют, какие действия разрешены. Например, процесс nginx может читать только файлы с меткой httpd_sys_content_t, даже если он запущен от имени пользователя root.

AppArmor появился позже и изначально развивался компанией Novell (позже SUSE). Его подход проще: политика описывает, какие пути может читать, писать или выполнять конкретная программа. Если программа пытается открыть файл вне разрешенного списка, ядро блокирует действие. Здесь нет сложных уровней доверия, есть четкие правила «разрешено/запрещено» для конкретных путей.

Сравнение архитектурных подходов

Практический пример: защита веб-сервера

Допустим, у вас работает Nginx с PHP-FPM. Вы хотите убедиться, что веб-сервер не сможет случайно прочитать файл /etc/shadow. В случае с SELinux вы проверяете метки: файл должен иметь тип etc_t, а процесс nginx - тип httpd_t. Если между ними нет правила allow read, доступ будет заблокирован. Для разрешения нужно либо добавить правило через semanage, либо изменить метку файла (что не рекомендуется).

В AppArmor подход другой. Вы создаете профиль для /usr/sbin/nginx и указываете, какие директории он может читать. Например, /var/www/html r,. Все остальные пути по умолчанию запрещены. Если nginx попытается открыть /etc/shadow, событие попадет в журнал auditd, и вы увидите сообщение об отказе. Настройка занимает минуты, а не часы.

Когда выбирать SELinux

Если ваша инфраструктура построена на RHEL/CentOS/Fedora, SELinux уже включен по умолчанию. Отключать его ради простоты - плохая идея, так как вы теряете слой защиты, который многие приложения ожидают. Особенно важно это в финансовых организациях, государственных структурах и компаниях, работающих с персональными данными, где требуется соответствие стандартам вроде FIPS 140-2 или CIS Benchmark.

Также SELinux лучше подходит, когда нужно реализовать строгие уровни секретности. Например, в военной или исследовательской среде, где данные делятся на уровни «секретно», «совершенно секретно» и т.д. Модель MLS (Multi-Level Security) в SELinux позволяет управлять этим напрямую.

Когда выбирать AppArmor

Если вы работаете с Ubuntu или Debian, AppArmor - естественный выбор. Он легче в освоении, особенно для администраторов, которые впервые сталкиваются с MAC. Инструменты вроде aa-logprof позволяют интерактивно добавлять разрешения прямо из журнала событий. Это ускоряет процесс устранения ошибок «permission denied».

Кроме того, AppArmor хорошо работает в контейнеризированных средах. Хотя Docker и Kubernetes имеют собственные механизмы изоляции, использование AppArmor внутри контейнеров добавляет еще один уровень контроля. Например, можно запретить контейнеру запускать новые процессы или менять сетевые настройки.

Типичные ошибки при настройке

• Использование режима permissive вместо enforcing без плана перехода. В permissive режиме нарушения логируются, но не блокируются. Если забыть переключиться обратно, защита фактически отсутствует.
• Размывание политик добавлением слишком широких правил. Вместо точечного разрешения лучше создавать отдельные типы или профили.
• Игнорирование журналов аудита. Без анализа сообщений auditd невозможно понять, почему именно произошло нарушение.
• Смешение двух систем MAC одновременно. Конфликты между SELinux и AppArmor могут привести к непредсказуемому поведению.

Инструменты и автоматизация

Для работы с SELinux незаменим пакет selinux-policy-devel, который содержит базовые политики. Команда getenforce показывает текущий режим, а setenforce 0 или 1 позволяет временно переключаться между enforcing и permissive. Для анализа логов используйте ausearch и audit2allow, который предлагает готовые правила для разрешения найденных нарушений.

В случае с AppArmor основным инструментом является apparmor_parser. Команда apparmor_status показывает список активных профилей и их статус. Для создания новых профилей удобно использовать aa-genprof, который запускает программу в интерактивном режиме и автоматически добавляет необходимые разрешения по мере использования.

Частые вопросы