RFE: better handling of audit events to kmsg when only a multicast subscriber is listening

[rgbriggs]

Currently if no auditd is around, but an audit multicast subscriber is (such as journald), the kernel currently still pushes all log messages into the kernel log buffer. This has the effect that journald sees every message twice unless auditd is running: once via kmsg and once via netlink.

The multicast read-only socket was intended as a non-reliable delivery mechanism, so detecting a multicast listener is insufficient grounds to stop writing to klog. Userspace should determine if the messages are equivalent and toss the duplicates.

Deduplication in userspace is a bad/really hard idea. This patch ("audit: skip klog-fowarding if mcasts were sent") works today, since systemd is the only known multicast listener and you are going to get the data in the same places, but I'm not sure its appropriate for every potential mcast listener...

A 'disable klog' audit command (AUDIT_SET) would work. systemd could handle that when it starts it's mcast listener...

See: RFE: If no audit daemon is running, but an audit multicast subscriber is around, then the kernel shouldn't forward audit data to kmsg
See: Audit events in /var/log/messages

[pcmoore]

I wonder if we could do something by keying off of audit_default and the multicast listener state. For example:

• audit_default == AUDIT_OFF and multicast listeners (likely the default for most)

Do not print to kmsg, but write to the multicast socket. Since the admin/user didn't explicitly enable audit on the kernel command line (as you should if you really care about audit events) I think it is safe to say that they don't care about audit in the absolute sense so multicast-only is likely okay. If the system is running an audit daemon, it will collect events as normal.

• audit_default == AUDIT_OFF and no multicast listeners

Print to kmsg since that is the only way the audit records are going to see the light of day.

• audit_default == AUDIT_ON regardless of the number of multicast listeners

Since the user/admin has explicitly enabled audit on the kernel command line we should assume they really care about audit and we should write to kmsg. Although in this case it is extremely likely that the system will be running an audit daemon to collect the audit events so you should only see audit records in kmsg if something has done terribly wrong with the audit daemon.

[poettering]

any update on this one? this recently came up again in #15324. There are apparently people who want to leave audit on in the kernel, have journald pick it up but not run auditd...

[lucab]

For context on the above: this came up in CoreOS land, where we generally try to keep OS moving parts to a minimum and move logic to containerized software or cluster components. We are happily running with journald collecting audit events, and no auditd on the system.
The serial console is flooded with audit events, though.

@rgbriggs any chance for this to show up on your near-future radar?

[pcmoore]

Patches are always welcome folks :) Want to try your hand at writing kernel audit patches @lucab or @poettering ?

[poettering]

Has already been done:

https://lkml.org/lkml/2014/12/31/99

no reply back then

[pcmoore]

Likely because it wasn't sent to the linux-audit mailing list. I don't see the patch in either the December 2014 or January 2015 archives:

• https://www.redhat.com/archives/linux-audit/2014-December/thread.html
• https://www.redhat.com/archives/linux-audit/2015-January/thread.html

Rebase the patch, if necessary, to current and send it to the appropriate lists and we can discuss it. For reference, here is the current entry in the kernel's MAINTAINERS file:

AUDIT SUBSYSTEM
M:      Paul Moore <paul@paul-moore.com>
M:      Eric Paris <eparis@redhat.com>
L:      linux-audit@redhat.com (moderated for non-subscribers)
W:      https://github.com/linux-audit
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
S:      Supported
F:      include/linux/audit.h
F:      include/uapi/linux/audit.h
F:      kernel/audit*

[rgbriggs]

As was discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1160046 a patch like this could work with a configuration option to make it a very deliberate administrator action, since the multicast socket is not a reliable transport to key this type of decision.

[pcmoore]

I strongly encourage technical discussions to move to the linux-audit mailing list, we use the GH issue tracker primarily as a public "todo list" and an easy way to track the progress of efforts that span longer periods of time.

[rgbriggs]

On 2020-04-08 06:10, Luca Bruno wrote: @rgbriggs assuming you don't want to control this behavior based on the presence of a multicast listener, how would the configuration proposal work?

If you ask this in linux-audit@redhat.com, I'll reply there.

[rgbriggs]

See also a very long discussion on https://bugzilla.redhat.com/show_bug.cgi?id=1227379

[lucab]

For future reference, as requested I moved the followups to the ML: https://www.redhat.com/archives/linux-audit/2020-April/msg00066.html.

[dustymabe]

This need to fix this is increased right now because we are trying to support a workflow where a user can interactively do an install using the Live ISO and use TUI interfaces for configuring networking. The increased user experience provided by a TUI is completely lost if we have audit messages scrolling on the console every 10 seconds or so.

I have opened two change requests that are two options we have for fixing this problem immediately. They are meant to spark discussion and hopefully get us to a point where this problem is fixed for the user trying to run a TUI and not have audit messages scrolling across their TUI canvas.

• live: disable audit on Live ISO
• manifest: include audit rpm

Maybe we can discuss these options (or any other viable short term option) in the meeting today to see if we can make progress.

Edit: Please disregard. This comment was meant to be made somehwere else.

[pcmoore]

Edit: Please disregard. This comment was meant to be made somehwere else.

Thanks, I was just about to come here and ask: "what meeting?" :)