Bug#1017595: please make apparmor less noisy

[Harald Dunkel]

Package: apparmor
Version: 2.13.6-10
Severity: wishlist

apparmor writes a bazillion of log entries to dmesg and /var/log/\
kern.log, hiding other important messages. Do you think it would be
reasonable to add auditd to the Recommends list?


Regards

Harri

[Seth Arnold]

On Thu, Aug 18, 2022 at 09:46:39AM +0200, Harald Dunkel wrote:
> apparmor writes a bazillion of log entries to dmesg and /var/log/\
> kern.log, hiding other important messages. Do you think it would be
> reasonable to add auditd to the Recommends list?

I'm slightly in favour of this, yes. One downside is that dbus apparmor
enforcement doesn't go through the audit system, they'll still show up in
the syslog pile, so log entries are split. But I think it's still a net
win to move most of the logging to something less prone to dropping log
entries.

I realize 'noisy' is in the ears of the listener :) but I suspect your
policy could use some tuning for your use. From a few of my own systems:

$ grep -c -i apparmor /var/log/syslog
18

$ grep -c -i apparmor /var/log/audit/audit.log
110

$ grep -c -i apparmor /var/log/audit/audit.log
36

$ grep -c -i apparmor /var/log/audit/audit.log
354

(This last one covers 76 days of audit logs.)

Anyway, if you ask in #apparmor on irc.oftc.net someone may be able to
suggest policy changes to reduce the noise.

Thanks

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Harald Dunkel (2022-08-18):

> apparmor writes a bazillion of log entries to dmesg and /var/log/\
> kern.log

I don't see this here so I'd like to understand where this comes from.

Could you please share the output of "sudo aa-status" or of "ls
/etc/apparmor.d/" (whichever you prefer)?

Just a guess: maybe you have the apparmor-profiles package installed?
If you do, FYI the only reason these profiles are still shipped in
this optional package (in complain mode) is so that users can test
them, choose which are desired, and help improve them upstream
if needed.

> Do you think it would be reasonable to add auditd to the
> Recommends list?

I'm happy to consider this (and thanks Seth for your input!)
but I'd like to first assess the chances this problem happens
to Debian users.

Cheers!

[Harald Dunkel]

Here is an example:

root@dpcl018:~# aa-status
apparmor module is loaded.
30 profiles are loaded.
27 profiles are in enforce mode.
/usr/bin/evince
/usr/bin/evince-previewer
/usr/bin/evince-previewer//sanitized_helper
/usr/bin/evince-thumbnailer
/usr/bin/evince//sanitized_helper
/usr/bin/man
/usr/lib/cups/backend/cups-pdf
/usr/lib/telepathy/mission-control-5
/usr/lib/telepathy/telepathy-*
/usr/lib/telepathy/telepathy-*//pxgsettings
/usr/lib/telepathy/telepathy-*//sanitized_helper
/usr/lib/telepathy/telepathy-ofono
/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
/usr/sbin/cups-browsed
/usr/sbin/cupsd
/usr/sbin/cupsd//third_party
/usr/sbin/haveged
/usr/sbin/ntpd
docker-default
libreoffice-senddoc
libreoffice-soffice//gpg
libreoffice-xpdfimport
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
3 profiles are in complain mode.
/usr/sbin/sssd
libreoffice-oopslash
libreoffice-soffice
12 processes have profiles defined.
5 processes are in enforce mode.
/usr/sbin/cups-browsed (1335514)
/usr/sbin/cupsd (1335513)
/usr/lib/cups/notifier/dbus (1335541) /usr/sbin/cupsd
/usr/sbin/haveged (776)
/usr/sbin/ntpd (1102)
7 processes are in complain mode.
/usr/sbin/sssd (806)
/usr/lib/x86_64-linux-gnu/sssd/sssd_be (866) /usr/sbin/sssd
/usr/lib/x86_64-linux-gnu/sssd/sssd_nss (915) /usr/sbin/sssd
/usr/lib/x86_64-linux-gnu/sssd/sssd_sudo (916) /usr/sbin/sssd
/usr/lib/x86_64-linux-gnu/sssd/sssd_pam (917) /usr/sbin/sssd
/usr/lib/x86_64-linux-gnu/sssd/sssd_ssh (919) /usr/sbin/sssd
/usr/lib/x86_64-linux-gnu/sssd/sssd_pac (920) /usr/sbin/sssd
0 processes are unconfined but have a profile defined.

root@dpcl018:~# dpkg -l apparmor\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=======================-============-============-======================================
ii apparmor 2.13.2-10 amd64 user-space parser utility for AppArmor
un apparmor-profiles-extra <none> <none> (no description available)
un apparmor-utils <none> <none> (no description available)


This is not about fine-tuning apparmor profiles or avoiding certain
packages. Its about adding auditd to Recommends to make apparmor less
noisy.


Regards

Harri

[intrigeri]

Control: retitle -1 Consider recommending auditd

Harald Dunkel (2022-09-07):

> This is not about fine-tuning apparmor profiles or avoiding certain
> packages. Its about adding auditd to Recommends to make apparmor less
> noisy.

OK, retitling accordingly then.

I'll now summarize my understanding of the problem space.

Recommending auditd would workaround at least 2 problems:

- On some systems, the configured AppArmor policy sends many log
messages to syslog, which makes it more difficult to see other,
potentially more relevant, log messages in dmesg, syslog, and
kern.log. That is, what this bug report was originally about.

Impact: with the data I have in hand, I doubt this practically
affects many Debian users.

- The AppArmor userspace tools currently don't support systems that
run systemd-journald, but neither syslogd nor auditd (#866340,
https://gitlab.com/apparmor/apparmor/-/issues/213).

Impact: if (or as long as) we install a syslogd implementation by
default, this impacts very few Debian users. Do we?

Currently known drawbacks of recommending auditd:

- It makes the systemd Journal more noisy: 237 on a basic sid test
system, just booting and logging into GNOME (excluding the 75
AppArmor ones).

Impact: this introduces a regression that's of the same nature as
the problem this bug report was originally about, but it'll impact
everyone querying the systemd Journal, even with common
system configurations.

- Users used to monitor AppArmor logs in dmesg, syslog, or kern.log,
won't find them there anymore.

Impact: I'm worried this may impact production monitoring systems
and confuse a number of users.

Mitigation: a NEWS.Debian entry seems necessary and sufficient
to me.

Open questions:

- This would run auditd by default on most Debian systems. It would
be good to check with the auditd maintainers if they're fine with
that (e.g. additional workload) and whether they're aware of other
potential drawbacks.

My current conclusion (that can of course change as I become aware of
more data): I'm not convinced that installing auditd by default on
Debian would solve more AppArmor usability problems than it would
create. But a "Suggests" seems well deserved: at least for some use
cases, auditd *is* the best solution.

Cheers,
--
intrigeri