SELinux и AppArmor ограничивают программы даже в том случае, если процесс запущен от root. Это мандатное управление доступом: ядро проверяет, разрешено ли конкретному домену или профилю обращаться к файлу, сокету или операции. Оба механизма решают одну задачу, но устроены по-разному, и путаница между ними приводит к советам «просто отключить». Разберём модели, диагностику и практические примеры.
Две модели ограничения
SELinux использует метки. Каждому файлу, процессу, порту и сокету присваивается контекст вида system_u:object_r:httpd_sys_content_t:s0. Политика описывает, какие типы могут взаимодействовать между собой. Метка следует за объектом: если файл переместить, контекст обычно сохранится, а доступ определяется типом, а не путём.
AppArmor использует пути. Профиль привязан к программе и перечисляет, к каким путям и с какими правами она может обращаться. Правило /srv/site/** r разрешает чтение всего дерева, а /var/log/nginx/** rw — запись в логи. Если файл перенести в другой каталог, доступ может измениться, потому что проверяется путь.
cat /sys/kernel/security/lsmВ выводе lsm перечислены активные модули безопасности. На Fedora и RHEL обычно виден selinux, на Ubuntu — apparmor. Теоретически модули могут работать одновременно, но на практике выбирают одну основную политику, чтобы не усложнять отладку.
SELinux: режимы и диагностика
SELinux работает в режимах enforcing, permissive и disabled. В enforcing нарушения блокируются и записываются в аудит, в permissive только записываются. Отключать SELinux ради запуска сервиса не нужно: почти всегда достаточно поправить метку или включить boolean.
getenforce
sestatus
ls -Z /var/www/html
ps -eZ | grep nginx
sudo ausearch -m AVC,USER_AVC -ts recentОтказы AVC — основной источник информации. Если в журнале есть denied, сначала выясните, какой процесс и какой тип файла участвуют. Для веб-сервера с каталогом /srv/site типичная ошибка — неверная метка: nginx не может прочитать файлы, хотя права Unix выставлены правильно. На Fedora и RHEL semanage и audit2allow входят в пакет policycoreutils-python-utils, а ausearch — в пакет audit; в минимальной установке их может не быть.
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?"
sudo restorecon -Rv /srv/site
ls -Z /srv/siteКоманда semanage задаёт правило, а restorecon применяет его к существующим файлам. chcon меняет метку разово и сбрасывается при восстановлении контекстов, поэтому для постоянной настройки он не подходит. Если сервису нужно ходить в сеть, проверьте boolean, а не ослабляйте политику целиком.
getsebool -a | grep httpd
sudo setsebool -P httpd_can_network_connect on
sudo semanage port -l | grep httpИногда готового boolean нет. Тогда анализируют аудит и собирают локальный модуль. Это нормальный путь для нестандартного приложения, но сначала убедитесь, что проблема не в обычных правах доступа и не в SELinux-метке.
sudo ausearch -m AVC -ts recent | audit2allow -M local_nginx
sudo semodule -i local_nginx.pp
sudo semodule -l | grep local_nginxAppArmor: профили и жалобы
Профили AppArmor лежат в /etc/apparmor.d. Режим complain фиксирует нарушения, но не блокирует их, а enforce блокирует. Для отладки удобно временно перевести конкретный профиль в complain, посмотреть журнал и вернуть enforce.
sudo aa-status
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginxСообщения ядра содержат имя профиля и путь, к которому было обращение. Не путайте их с ошибками приложения: если в логе есть apparmor=»DENIED», это прямой указатель на политику.
sudo journalctl -k | grep -i apparmor | tail -20
sudo dmesg | grep -i "apparmor.*denied" | tail -20
sudo aa-logprofaa-logprof помогает обновить профиль по свежим событиям, но автоматически сгенерированные правила нужно проверять. Утилита входит в пакет apparmor-utils. Разрешение на запись во весь домашний каталог или на запуск произвольных программ обесценивает профиль. Добавляйте минимально необходимые пути.
/srv/site/** r,
/var/log/nginx/** rw,
/etc/nginx/** r,
Сравнение на практике
| Критерий | SELinux | AppArmor |
|---|---|---|
| Модель | Метки и типы | Пути и профили |
| Дистрибутивы | Fedora, RHEL, AlmaLinux, Rocky | Ubuntu, Debian, openSUSE |
| Гранулярность | Высокая, включая роли и MLS | Средняя, удобная для приложений |
| Диагностика | audit, ausearch, sealert | dmesg, journalctl, aa-logprof |
| Порог входа | Выше | Ниже |
| Контейнеры | container-selinux | docker-default |
В контейнерах разница проявляется особенно заметно. На RHEL-подобных системах Docker и Podman получают SELinux-метки для томов, а на Ubuntu действует профиль AppArmor. Монтирование каталога без нужной метки — классическая причина ошибки permission denied внутри контейнера при корректных правах снаружи.
Ещё одно отличие — переносимость. Политику AppArmor проще написать для конкретного приложения, потому что она опирается на пути. Политика SELinux лучше масштабируется в большой инфраструктуре, но требует понимания типов и контекстов. Для домашнего сервера на Ubuntu обычно достаточно AppArmor, для парка RHEL — SELinux.
Как выбрать
Если инфраструктура уже построена на Ubuntu или Debian, менять механизм ради принципа не стоит: AppArmor включён, профили для типовых сервисов готовы, а администрирование остаётся предсказуемым. Для нового парка на RHEL, AlmaLinux или Rocky разумнее сразу освоить SELinux: там он является частью поддерживаемой конфигурации, и отключение лишает смысла многие рекомендации вендора.
В смешанной среде придерживайтесь правила «один сервер — одна основная политика». Если приложение требует нестандартных разрешений, сначала проверьте, нет ли готового профиля или boolean, затем опишите минимальные правила и зафиксируйте их в конфигурации управления. Проверка политики должна входить в приёмку сервиса, иначе после обновления приложения доступ неожиданно сломается. Для небольшого проекта важнее не название механизма, а понятный процесс обновления профилей и регулярный просмотр журналов. Если серверов несколько, храните профили и локальные модули в системе управления конфигурацией, чтобы не повторять правки вручную.
Чек-лист
- Проверьте, какой модуль активен: cat /sys/kernel/security/lsm.
- Не отключайте защиту навсегда ради одного сервиса.
- Для SELinux сначала смотрите AVC, затем метки и boolean.
- Для AppArmor используйте complain, журнал и точечные правила.
- После изменения политики перезапустите сервис и проверьте журнал.
- Проверьте, не мешают ли обычные права Unix и владелец файлов.
Итог
SELinux и AppArmor — не взаимозаменяемые «галочки безопасности», а разные подходы к мандатному доступу. SELinux даёт более точную модель и сильнее меняет привычки администрирования, AppArmor быстрее осваивается и хорошо подходит для типовых серверов. Выбор чаще определяется дистрибутивом, а не личными предпочтениями. Главное — не отключать механизм, а научиться читать его отказы и описывать минимальные разрешения.