Apparmor мусорит в логах

https://bugs.launchpad.net/ubuntu/ source/apparmor/ bug/937723

Подскажите пожалуйста, как заставить аппармор писать в логи сообщения о событиях только о статусом DENIED и прочих WARNINGах, а во всех остальных случаях молчать в тряпочку.

ALLOWED может попасть в лог только если у вас профиль программы в режиме обучения (complain mode) или используется общесистемный force-complain режим для всех профилей. В enforce mode, в лог будут попадать только DENIED. Судя по логам, вам стоит доработать базовые профили и включить enforce mode (чтобы получать только DENIED).

Спасибо за наводку. Буду ковырять профили. Ну и с оказией вдогонку вопрос задам, а где общий force-complain отключается, чего то тоже не увидел, может между глаз попало :-)

force-complain на профиль — это фактически просто ссылка на профиль в директории «/etc/apparmor.d/force-complain/». Если сделать ссылки на все профили — будет общесистемный force-complain на все профили apparmor. Парсер сам смотрит в эту директорию и выполняет нужные действия. Как вариант, ненужный профиль можно совсем отключить, поместив ссылку на профиль в «/etc/apparmor.d/disable/» (тем самым увеличив скорость включения/загрузки профилей apparmor).

Советую так же сразу создавать бинарные кэши профилей (например, «find /etc/apparmor.d/ -maxdepth 1 -type f -exec apparmor_parser -rWQ {} \;» ... должны создаваться в /etc/apparmor.d/cache/), что значительно увеличивает загрузку профилей (парсер сам проверяет наличие актуальных кэшей). Но, следует помнить:

• бинарные кэши не работают с профилями в режиме force-complain, парсер будет игнорировать бинарный кэш такого профиля;
• после изменения профиля, надо повторно сгенерировать его кэш, а не просто перезагрузить профиль («apparmor_parser -rWQ ...»);
• после обновления ядра (изменения функционала) потребуется сгенерировать повторно все кэши профилей. Парсер генерирует бинарные кэши опираясь на функционал ядра, перенести кэши на другое ядро с другим функционалом apparmor нельзя (парсер не станет их грузить, а будет грузить с профилей);
• Также, стоит учитывать глючность apparmor_parser, которые не всегда корректно понимает изменения/обновления abstractions/tunables/local, и если там что-то менялось, лучше сгенерировать новые кэши (теоретически, apparmor_parser должен понимать, какие именно кэши профилей надо повторно сгенерировать, но не всегда корректно обходит все вложения...).

Большое спасибо за развёрнутый ответ, теперь всё предельно ясно.

OFFTOP: Приятно подметить как выросло сообщество ЛОРа с начала 2000ых. Тогда за такие вопросы можно было огрести от красноглазых анонимусов по полной. Теперь же всё больше развёрнутых ответов и по теме. Растём господа линуксоиды, и это не может не радовать.

поправил профили, сообщений в логах почти нет. Пока оставил в режиме обучения, хочу до конца «заполировать» профили.
Кстати по поводу регенерации двоичного кеша, и в Ubuntu и в Debian (последних stable) кеш регенерируется автоматом при выполнении команды systemctl reload apparmor. Так что в ручную этого делать не нужно.
Заметил единственную разницу в поведении systemd в Debian и Ubuntu, в первом кеш регенерируется на все профили, а в Ubuntu только на те что изменились. Так что в Ubuntu перезагрузка профилей происходит чуть быстрее, практически не заметно на глаз.

поправил профили, сообщений в логах почти нет. Пока оставил в режиме обучения, хочу до конца «заполировать» профили.

Советую сразу смотреть в сторону RBAC (http://wiki.apparmor.net/index.php/RBAC_2_3), задействовать pam модуль и ограничивать пользователя, не останавливаться на вылизывании правил в режиме MAC. C RBAC, в случае эскалации привилегий, пользователь останется в своем ограниченном пространстве, даже с UID 0, т. к. переключений ветки профилей apparmor происходит только в процессе аутентификации через pam.

На самом деле, apparmor можно неплохо «прокачать», но все это за рамками «работает из коробки».

Кстати по поводу регенерации двоичного кеша, и в Ubuntu и в Debian (последних stable) кеш регенерируется автоматом при выполнении команды systemctl reload apparmor. Так что в ручную этого делать не нужно.

Значит в Ubuntu и Debian сделали запуск с параметрами парсера «WQ», или аналогичными. Но, как я уже писал, парсер глючный — иногда не делает регенерацию кэша профиля, если были изменения вложенных частей. По крайней мере на состояние текущей 2.11.0 - ситуация остается прежней, иногда сталкиваюсь. Если ничего не корректируется в abstractions/tunables/local, можно не заморачиваться.

Заметил единственную разницу в поведении systemd в Debian и Ubuntu, в первом кеш регенерируется на все профили, а в Ubuntu только на те что изменились. Так что в Ubuntu перезагрузка профилей происходит чуть быстрее, практически не заметно на глаз.

Имхо, в Debian просто обходят грабли парсера. Получается дольше, но надежнее.

http://wiki.apparmor.net/index.php/RBAC_2_3

Ничоси! Не знал, спасибо.

Как всегда, весьма признателен за развёрнутый ответ. Разбираюсь с RBAC

Не могу победить странную реакцию apparmor на samba. В логах от apparmor есть сообщения типа:

Apr 30 10:09:29 dozer kernel: [681061.731444] audit: type=1400 audit(1493536169.230:7384): apparmor=«ALLOWED» operation=«file_mmap» profile=«/usr/sbin/smbd» name=«/usr/lib/x86_64-linux-gnu/samba/gensec/krb5.so» pid=31881 comm=«smbd» requested_mask=«m» denied_mask=«m» fsuid=0 ouid=0

причём в профиль smbd добавлено разрешение на церберовскую либу:

/usr/lib/x86_64-linux-gnu/samba/gensec/krb5.so rm,

но это не меняет ситуации, сообщения продолжают появляться регулярно. Кто сталкивался, подскажите в какую сторону копать?

P.S. Samba не доменная, просто файлопомойка.