Re: multicast listeners and audit events to kmsg

[Paul Moore <paul@paul-moore.com>]

On Thu, Apr 16, 2020 at 8:45 AM Lennart Poettering
<lennart@poettering.net> wrote:
> On Mi, 15.04.20 11:53, Richard Guy Briggs (rgb@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


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit