Профили AppArmor для Podman и Docker на Linux
Контейнеры обеспечивают нам изоляцию, но по умолчанию они используют ядро хоста напрямую. А это значит, что общая поверхность атаки остается куда шире, чем многие думают. AppArmor (и его родственник SELinux, о котором мы поговорим как-нибудь позже) позволяет применять мандатный контроль доступа (MAC) на уровне приложений. Используя его связке с Podman или Docker, вы можете кардинально урезать возможности скомпрометированного процесса внутри контейнера по отношению к хост-системе.
В этом посте разберем процесс генерации рабочего профиля, его принудительного применения, отладки нарушений и чистой интеграции с вашей средой выполнения контейнеров - и всё это на базе типичной системы Debian/Ubuntu.
Зачем нужен AppArmor для контейнеров?
Казалось бы, ну ведь стандартные среды выполнения контейнеров уже дропают возможности (capabilities) и используют seccomp, нафига AppArmor? Но AppArmor добавляет к этому правила на основе путей и отслеживания возможностей, которые легко аудировать. Профиль может:
Запретить запись в чувствительные пути хоста, даже если внутри контейнера процесс запущен от root.
Ограничить разрешенные системные вызовы и операции с файлами сверх того, что предоставляет рантайм.
Выдавать вам понятные человеку логи, когда что-то пытается выбраться из своей «песочницы».
В Ubuntu AppArmor включен по умолчанию, а в Debian и Arch его активация - дело пары пустяков.
Генерируем первый профиль
Для начала установим инструменты (пример для Debian/Ubuntu):
sudo apt update && sudo apt install apparmor apparmor-utils apparmor-profiles
Переведем целевое приложение в режим обучения (complain mode), чтобы понаблюдать за его реальным поведением:
sudo aa-genprof podman # или docker, или имя вашего бинарника
Утилита aa-genprof запускает программу в режиме обучения и следит за логами. Теперь запустите ваш контейнер в обычном рабочем режиме:
podman run --rm -it nginx:alpine sh
Погоняйте контейнер в хвост и в гриву (поустанавливайте пакеты, позаписывайте файлы и т.д.). Затем выйдете из него и позвольте утилите aa-logprof провести вас по процессу создания правил.
Минимальный готовый профиль (/etc/apparmor.d/podman-nginx) может выглядеть примерно так:
#include <tunables/global>
profile podman-nginx flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/base>
#include <abstractions/nameservice>
capability net_bind_service,
capability setuid,
capability setgid,
network inet stream,
network inet6 stream,
/var/log/nginx/** rw,
/var/cache/nginx/** rw,
/etc/nginx/** r,
/usr/share/nginx/** r,
# Запрещаем доступ на запись к большей части /proc и /sys по умолчанию
deny /proc/** w,
deny /sys/** w,
# Разрешаем только конкретное чтение при необходимости
/proc/cpuinfo r,
/proc/meminfo r,
# Бинарник вашего приложения и библиотеки
/usr/sbin/nginx mr,
/usr/lib/nginx/** mr,
# Обработка сигналов
signal (receive) set=term,
# Запрещаем всё остальное по умолчанию
deny /** wl,
}
Инструмент aa-logprof шаг за шагом проведет вас по каждому залогированному событию и позволит выбрать: разрешить его, запретить или проигнорировать.
Принудительное применение профиля в Podman
У Podman отличная интеграция с AppArmor. Запустите контейнер следующим образом:
podman run --security-opt apparmor=podman-nginx -p 8080:80 nginx:alpine
Убедитесь, что профиль действительно загружен:
sudo aa-status | grep podman-nginx
Вы должны увидеть его в режиме enforce (принудительное исполнение).
Для Docker (если вы всё еще его используете):
docker run --security-opt apparmor=podman-nginx nginx:alpine
Отладка и итерация
Если что-то ломается, проверьте логи ядра:
sudo dmesg | grep apparmor
# или
sudo journalctl -xe | grep apparmor
Затем снова воспользуйтесь интерактивным профилировщиком:
sudo aa-logprof
Он покажет, какого именно правила не хватало. Типичный сценарий: нужно добавить конкретный путь вида /run/… или /tmp/…, который легитимно требуется вашему приложению.
В продакшене вы можете временно переключить профиль в режим обучения (complain):
sudo aa-complain /etc/apparmor.d/podman-nginx
После настройки верните всё обратно в режим принудительного исполнения:
sudo aa-enforce /etc/apparmor.d/podman-nginx
С чего начать изучение
Запускайте каждый новый образ контейнера с автоматически сгенерированным профилем в режиме обучения (complain) на протяжении недели.
Храните профили в Git рядом с вашими манифестами развертывания.
Сочетайте это с флагом --cap-drop=ALL и строгим профилем seccomp для эшелонированной защиты.
Периодически используйте утилиту aa-unconfined, чтобы находить процессы, которые работают без ограничений.
Что почитать по теме
Документация Ubuntu по AppArmor: https://ubuntu.com/server/docs/how-to/security/apparmor/
Страница AppArmor на Arch Wiki (отличные примеры): https://wiki.archlinux.org/title/AppArmor
Параметры безопасности Podman: man podman-run (ищите по ключевому слову apparmor)
Man-страницы для aa-genprof(8), aa-logprof(8) и apparmor(7)
Профили AppArmor относятся к той категории инструментов, которые настраиваются один раз и довольно долго не меняются (если конечно хорошо к этому подойти в первый раз). Первоначальные вложения времени в изучение aa-logprof окупятся в первый же раз, когда вы поймаете контейнер на попытке сделать то, чего он делать не должен.
Если вы уже гоняете Podman или Docker в продакшене без кастомных профилей AppArmor, то это одно из самых высокодоходных (с точки зрения ROI) улучшений безопасности, которые вы можете сделать на этой неделе. Начните с одного критически важного сервиса и двигайтесь дальше.
