LINUX.ORG.RU

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

 


0

3

Доброго дня уважаемые форумчане. Пытаюсь тыкать палочкой в apparmor (и на Debian и на Ubuntu), вроде живой. Но мне не нравиться что он в логи сыплет сообщения о событиях со статусом ALLOWED. Или может я чего непонимаю.

Пример:

Apr 23 15:57:56 gate kernel: [255084.417460] audit: type=1400 audit(1492952276.762:1237): apparmor=«ALLOWED» operation=«signal» profile=«/usr/sbin/dovecot» pid=1939 comm=«dovecot» requested_mask=«send» denied_mask=«send» signal=int peer=«/usr/lib/dovecot/config»

Apr 23 16:00:51 gate kernel: [255258.919915] audit: type=1400 audit(1492952451.263:1238): apparmor=«ALLOWED» operation=«truncate» profile=«/usr/sbin/dnsmasq» name=«/var/spool/dnsmasq.leases» pid=1623 comm=«dnsmasq» requested_mask=«w» denied_mask=«w» fsuid=110 ouid=0

Apr 23 13:15:32 dozer kernel: [87424.621112] audit: type=1400 audit(1492942532.122:1285): apparmor=«ALLOWED» operation=«open» profile=«/usr/sbin/nmbd» name=«/var/cache/samba/lck/22002» pid=22002 comm=«nmbd» requested_mask=«wc» denied_mask=«wc» fsuid=0 ouid=0

Apr 23 13:47:30 dozer kernel: [89342.508231] audit: type=1400 audit(1492944449.980:1325): apparmor=«ALLOWED» operation=«file_mmap» profile=«/usr/sbin/smbd» name=«/usr/lib/x86_64-linux-gnu/samba/gensec/krb5.so» pid=22930 comm=«smbd» requested_mask=«m» denied_mask=«m» fsuid=0 ouid=0

Николай Васильевич вопрос не прояснил. В конфигах и манах аппармора я ничего по этой теме не нашёл. Подскажите пожалуйста, как заставить аппармор писать в логи сообщения о событиях только о статусом DENIED и прочих WARNINGах, а во всех остальных случаях молчать в тряпочку. А то уж слишком жирные логи получаются.

Спасибо заранее.

★★

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

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

viewizard ★★
()
Ответ на: комментарий от viewizard

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

Vint ★★
() автор топика
Ответ на: комментарий от Vint

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 должен понимать, какие именно кэши профилей надо повторно сгенерировать, но не всегда корректно обходит все вложения...).
viewizard ★★
()
Ответ на: комментарий от viewizard

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

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

Vint ★★
() автор топика
Ответ на: комментарий от viewizard

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

Vint ★★
() автор топика
Ответ на: комментарий от Vint

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

Советую сразу смотреть в сторону 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 просто обходят грабли парсера. Получается дольше, но надежнее.

viewizard ★★
()
Ответ на: комментарий от viewizard

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

Vint ★★
() автор топика

Не могу победить странную реакцию 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 не доменная, просто файлопомойка.

Vint ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.