How to get rid of audit logs only from the systemd journal?

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Di, 10.04.18 12:02, Mikhail Morfikov (mmorfikov at gmail.com) wrote:

> I'm using AppArmor and it sometimes returns many audit logs. By default there
> was something like this in the journal:
> 
> ... audit[1397]: AVC apparmor= ...
> ... kernel: audit: type=1400 audit(1523275695.613:76): apparmor= ...
> 
> So there are two entries and they carry the same message. So the message is
> doubled. The first message disappears when systemd-journald-audit.socket is
> masked, but what about the second message?
> 
> Basically I want to remove the AppArmor logs only from the journal and not from
> the whole system. They could be logged by rsyslog and placed in some file/FIFO
> device.
> 
> Is there a way to get rid of the second message from the journal only somehow?

The kernel has three ways to pass audit messages to userspace:

1. with an audit daemon. This is what auditd implements. It's an
   exclusive interface: there can only be one userspace service be
   listening to this, and there is one, nobody else can use the same
   interface.

2. If there's no userspace process implementing the above, then the
   messages are instead written directly to kmsg.

3. There can be any number of additional "multicast" audit
   clients. The journal is one of them, and this is what you can turn off
   by masking the socket unit you found. Note that this interface is
   fully orthogonal to #1 and #2.

The duplicate messages are you seeing come from #2 and #3 most
likely. You were able to disable #3, which leaves you with #2. From
the journal's perspective these messages are superficially
undistinguishable from other kernel log messages, which means you can
turn this off by turnining off all kernel log messages (ReadKmsg= in
journald.conf), but of course, in that case you actually turn them
*all* off, which is unlikely what you want...

A dirty way out is to make sure #1 exists, i.e. by installing
auditd. If you do, then #2 won't be in effect anymore, but of course,
that has other issues again...

There were plans to change the kernel internal logic to only do #2 if
there are zero #1 and zero #3 clients around. (Right now #2 is done
whenever there are zero #1 clients, and #3 clients don't matter.) That
work appears to have stalled though...

If you don't care at all about audit messages, consider passing
audit=0 on the kernel cmdline, that makes them go away altogether.

Lennart

-- 
Lennart Poettering, Red Hat