Re: multicast listeners and audit events to kmsg
On Thu, Apr 16, 2020 at 8:45 AM Lennart Poettering
<lennart(a)poettering.net> wrote:
On Mi, 15.04.20 11:53, Richard Guy Briggs (rgb(a)redhat.com) wrote:
> 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.
kmsg is not reliable either, it aggressively and silently drops
messages if the log buffer runs full, which it does pretty quickly.
hence there's really no difference here if data is written to the
mcast socket or to kmsg, in both cases messages are dropped when the
buffer limits are hit, hence it should be entirely fine to do only one
of the twoif the unicast client to audit is not running.
I'm a little late to this discussion due to some other audit and
kernel issues, but I wanted to both add a little content and
additional voice to what Richard and Lenny have already said.
As far as reliability is concerned, the "reliable" communication
channel is the unicast netlink channel between the audit daemon and
the kernel. Sure, it isn't perfect but it is better than both the
multicast netlink channel and the kernel's message buffer. If you
look at the kernel's audit code, you'll see that printk/kmsg is really
only used as a last resort when the main unicast netlink channel is
down. We are not claiming it is a reliable mechanism, it is just all
the kernel has at that point*.
* A quick comment on the multicast netlink channel: it was always seen
as a separate out-of-band, unreliable mechanism to communicate audit
records to systemd (and presumably others, but I'm not aware of any).
There has never been any serious thought amongst the audit developers
to support the multicast netlink channel beyond this, and I don't see
anything changing that in the immediate future. FWIW, I agree with
Richard's comment that the netlink multicast channel was a mistake; it
wasn't my call to make at the time, but I don't think we would merge
that code if it came up today. However, it was merged and we will
continue to support it within the scope of its original functionality.
> > 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.
I am sorry, but this doesn't work for us. We do not want to do IPC to
some audit daemon (journald runs during early boot and in the initrd,
it has a very special relationship with early boot stuff and PID1, and
thus being a client to other daemons is highly problematic, if those
other daemons are managed by systemd as well, and run only during later
boot). In fact we don't even want the dependency on the audit
userspace package at all.
In systemd we just think that audit information is pretty interesting
even if you don't want to buy into the whole government regulation
stuff, even if you don't want the auditd to run, and the full audit
package installed. i.e. we want to collect the data as one of our
various data streams, as a secondary consumer of it, and leave it to
the audit package itself to do everything else and be the primary
consumer of it.
Using the multicast group is our way of saying: "we don't want to own
the audit stream, you can keep it; we just want to have a look
too".
The problem is that on systems without a running audit daemon there is
no one to "own" the audit stream so it floods the kmsg, spills onto
the console, and everyone's feet get wet. Are we going to blame the
source of the stream, or the person who turned on the tap in the first
place and caused the mess?
If systemd enables the audit stream, and doesn't want the stream to
flood kmsg, it needs to make sure that the stream is directed to a
suitable sink, be it auditd or some other daemon.
--
paul moore
www.paul-moore.com