Re: multicast listeners and audit events to kmsg
On 2020-04-14 09:27, Luca BRUNO wrote:
Hi all,
I'm trying to re-spin a very old thread related to multicast listeners
and audit events to kmsg.
One surprising kernel behavior when using only a multicast listener
to collect audit events (in this case, systemd-journald) is that
audit events end up spamming the console [0].
[0] https://github.com/systemd/systemd/issues/15324
This is not surprising, since the multicast audit socket is not
considered a reliable sink for the audit log and thus cannot be relied
upon to key the decision to forward potentially lost messages to the
system log.
After a bunch of digging, it seems like this is due to a
long-standing
RFE on the kernel side [1] (plus further references on BZ and LKML).
[1] https://github.com/linux-audit/audit-kernel/issues/102
Apparently there isn't a clear consensus on how this should be
approached. Looking at the github and bugzilla tickets, it seems to me
that Eric and Paul initially had in mind some logic based on multicast
listener detection, while Richard doesn't deem that reliable and
suggests an explicit configuration.
I'm regretting having developped this feature due to the problems it has
caused the audit developpers and innocent bystanders. Instead, an audit
daemon plugin should have been used to direct log records to journald.
My understanding is Paul does not think multicast listener detection is
reliable enough either.
I'm not personally knowledgeable enough to judge kernel-land
approaches (nor to implement them), but I'd be happy if the audit folks
could converge to a consensus on how to implement this RFE, how it
would be consumed by userland, and what would be the kernel default
behavior once this RFE is implemented.
Well, Steve, Paul and myself are all fairly firmly on the side of the
problem being in systemd and its overreach.
For Richard and the "explicit configuration" approach in
particular, I'm
missing some further details:
* Is the current behavior considered buggy, or is that intended to be
kept as the default?
The current systemd behaviour of unilatterally enabling audit logging is
considered buggy. The current audit kernel behaviour is considered
intentional.
* Would this be tweaked via a (boolean?) sysctl, and what would be
the
semantics of flipping it?
It would be controlled via a new audit unicast netlink message similar
to the one that enabled auditing in the first place by systemd that
would explicitly disable klog when a multicast client is connected.
* How would this play with namespacing, especially netns?
Currently, it is moot since there can be only one audit daemon and it
listens in all network namespaces.
The future needs some thought since there are tickets open to allow
multiple audit daemons and to devise a way to route messages to those
multiple audit daemons.
Ciao, Luca
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635