AppArmor

Q: «Permission denied», а права (rwx) верные

Блокирует AppArmor. Смотри отказы: sudo journalctl -k | grep -i 'apparmor.*denied' sudo dmesg | grep -i 'apparmor.*DENIED' Строка DENIED ... operation="open" ... name="/path" укажет, к чему профиль не пустил.

Q: Служба работает, но не может в новый каталог

Профиль не разрешает путь. На время отладки — aa-complain, погонять, затем aa-logprof дополнит профиль, и aa-enforce.

Q: Профиль не перечитывается после правки

sudo apparmor_parser -r <профиль> (или reload apparmor). Синтаксическая ошибка — parser её покажет.

Q: Хочу временно отключить для одной службы

sudo aa-complain <профиль> (мягко) или aa-disable. Полностью глушить AppArmor в проде не стоит — это потеря защиты.

7 мин Ubuntu 24.04 · AppArmor

Мандатный контроль доступа в Ubuntu — профили служб, режимы enforce/complain.

Шпаргалка

6 команд Версия для печати

sudo aa-status профили и режимы
journalctl -k | grep -i 'apparmor.*denied' что блокируется
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx только лог
sudo aa-logprof дополнить профиль по логам
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx обратно блокировать
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx перечитать

Обзор

AppArmor — система мандатного контроля доступа (MAC) в Ubuntu. Поверх обычных прав (permissions) она ограничивает, к каким файлам/возможностям может обращаться конкретная программа, по профилю. Если служба ведёт себя странно с «Permission denied», хотя права верные — подозревай AppArmor.

bash

sudo aa-status                    # профили и их режимы
sudo aa-status --json | jq .      # машиночитаемо (см. jq)

На учебной машине AppArmor включён в ядре (/sys/module/apparmor/parameters/enabled — Y), загружено 116 профилей, 22 из них — в режиме enforce.

Профиль и local-файл

Профиль — файл в /etc/apparmor.d/: какой программе он назначен и что ей можно. Учебный профиль для копии ls:

text

abi <abi/4.0>,
include <tunables/global>

profile demols /usr/local/bin/demols {
  include <abstractions/base>
  /srv/data/public/** r,
  include if exists <local/demols>
}

abstractions/base — общий набор, без которого программа не запустится: библиотеки, локали, /dev/null. Строка include if exists <local/…> подключает файл /etc/apparmor.d/local/<имя>, если он есть. Профили из пакетов подключают такой файл — свои правила пишут туда, файл пакета не трогают, и обновление их не сотрёт.

После правки профиль загружают в ядро заново, и он сразу действует на уже запущенные процессы:

bash

echo '/srv/data/public/ r,' | sudo tee /etc/apparmor.d/local/demols
sudo apparmor_parser -r /etc/apparmor.d/demols

Правила путей: /dir/ и /dir/**

Правило	Что разрешает
`/srv/data/public/ r,`	читать сам каталог — список файлов
`/srv/data/public/* r,`	файлы прямо в каталоге
`/srv/data/public/** r,`	всё внутри каталога на любой глубине, но не сам каталог

С одним правилом ** файл читается, а список каталога — нет:

text

student@ubuntu:~$ demols /srv/data/public/a.txt
/srv/data/public/a.txt
student@ubuntu:~$ demols /srv/data/public
demols: cannot open directory '/srv/data/public': Permission denied

После строки /srv/data/public/ r, в local-файле demols /srv/data/public печатает a.txt. Права файлов при этом a+rX — сам ls читает каталог без ошибок.

Строка DENIED

text

audit: type=1400 audit(1792561704.657:122): apparmor="DENIED"
  operation="open" class="file" profile="democat"
  name="/srv/data/secret/b.txt" pid=1337 comm="democat"
  requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Поле	Что значит
`profile`	чей профиль запретил
`operation`	действие: `open`, `exec`, `mknod`, `connect`
`name`	путь, к которому программа обратилась
`requested_mask`, `denied_mask`	что просили и что не дали: `r`, `w`, `x`, `a`
`comm`, `pid`	процесс
`fsuid`, `ouid`	пользователь процесса и владелец файла

name с / на конце — это каталог: не хватает правила /dir/ r,.

Кто под профилем

text

student@ubuntu:~$ ps -eZ | grep demosleep
demosleep (enforce)                1358 ?        00:00:00 demosleep
student@ubuntu:~$ sudo aa-status | grep -A2 'processes are in enforce'
2 processes are in enforce mode.
   /usr/local/bin/demosleep (1358) demosleep
   /usr/sbin/rsyslogd (661) rsyslogd

В столбце LABEL у ps -eZ — профиль и режим; unconfined — профиля нет. В режиме complain (aa-complain) запрет не действует, а в журнал вместо DENIED пишется apparmor="ALLOWED".

Где искать отказы

Пока служба auditd выключена (так на учебной машине), отказы пишет журнал ядра: sudo journalctl -k | grep DENIED. Запущенный auditd забирает сообщения аудита себе — новые отказы идут в /var/log/audit/audit.log, а в journalctl -k их нет:

bash

sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log | tail -3
sudo ausearch -m AVC -i | tail -3

ausearch -i добавляет к отказу запись SYSCALL с uid и exe и PROCTITLE с командой целиком (см. auditd).

Рецепты

Режимы и команды

Профили — в /etc/apparmor.d/. Два режима:

enforce — нарушения блокируются;
complain — только логируются (для отладки/обкатки).

bash

sudo aa-status                                    # обзор
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx   # → complain
sudo aa-enforce  /etc/apparmor.d/usr.sbin.nginx   # обратно в enforce
sudo aa-disable  /etc/apparmor.d/usr.sbin.nginx   # отключить профиль
sudo apparmor_parser -r /etc/apparmor.d/profile   # перечитать
sudo apparmor_parser -R /etc/apparmor.d/profile   # выгрузить профиль
sudo systemctl reload apparmor

Пакеты apparmor-utils дают aa-* хелперы; без них — только apparmor_parser.

Профили и обкатка

Структура профиля (упрощённо): путь к бинарю + правила доступа (capabilities, пути с r/w/ix), плюс #include <abstractions/...> и #include <tunables/...>.

Полуавтоматическая доводка профиля под реальное поведение:

bash

sudo aa-genprof /usr/bin/myapp    # создать профиль, гоняя приложение
sudo aa-logprof                   # правила по логам отказов

Типичный цикл: aa-complain → погонять нагрузку → aa-logprof (принять сгенерированные разрешения) → aa-enforce.

Неполадки

«Permission denied», а права (rwx) верные

Блокирует AppArmor. Смотри отказы:

bash

sudo journalctl -k | grep -i 'apparmor.*denied'
sudo dmesg | grep -i 'apparmor.*DENIED'

Строка DENIED ... operation="open" ... name="/path" укажет, к чему профиль не пустил.

Служба работает, но не может в новый каталог

Профиль не разрешает путь. На время отладки — aa-complain, погонять, затем aa-logprof дополнит профиль, и aa-enforce.

Профиль не перечитывается после правки

sudo apparmor_parser -r <профиль> (или reload apparmor). Синтаксическая ошибка — parser её покажет.

Хочу временно отключить для одной службы

sudo aa-complain <профиль> (мягко) или aa-disable. Полностью глушить AppArmor в проде не стоит — это потеря защиты.

snap-приложение и AppArmor

Snap использует свои профили (confinement); отказы тоже видны в journalctl -k (см. snap snap connections).

Термины

профиль AppArmor AppArmor profile: Файл в /etc/apparmor.d со списком того, что программе можно: пути с правами r, w, x и capabilities. В режиме enforce ядро запрещает остальное и пишет apparmor="DENIED", в complain — только пишет.

См. также

permissions — Модель прав Unix — чтение/запись/исполнение, владелец/группа/другие, спецбиты.
journalctl — Чтение журнала systemd (journald) — фильтры по службе, времени, приоритету.
nginx — Веб-сервер и обратный прокси. Конфиг проверяется nginx -t; reload без даунтайма.

Есть неточность? Сообщить об ошибке в статье