Re: multicast listeners and audit events to kmsg

From: Paul Moore <paul@paul-moore.com>
To: Lennart Poettering <lennart@poettering.net>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
Subject: Re: multicast listeners and audit events to kmsg
Date: Thu, 23 Apr 2020 09:50:12 -0400	[thread overview]
Message-ID: <CAHC9VhSu=cbr_f3fyX_wdBdt_+xHwBBjOJojrk-iNgwhhBCg7w@mail.gmail.com> (raw)
In-Reply-To: <20200423073021.GA62700@gardel-login>

On Thu, Apr 23, 2020 at 3:30 AM Lennart Poettering
<lennart@poettering.net> wrote:
> On Mi, 22.04.20 17:59, Paul Moore (paul@paul-moore.com) wrote:
> > > 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?
>
> It's not a question of blaming anyone. We are just looking for a nice
> way so that we can get the mcast stuff without the kmsg stuff. it can
> totally be something we toggle explicitly, i have no problem with
> that.
>
> > 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.
>
> This sounds as if journald should start using the unicast stream. This
> basically means auditd is out of the game, and cannot be added in
> anymore, because the unicast stream is then owned by journald. It
> wouldn't be sufficient to just install the audit package to get
> classic audit working anymore. You'd have to reconfigure everything.
>
> I mean, we try to be non-intrusive, not step into your territory too
> much, not replace auditd, not kick auditd out of the game. But you are
> basically telling us to do just that?

My recommendation is that if you are going to enable audit you should
also ensure that auditd is running; that is what I'm telling you.

-- 
paul moore
www.paul-moore.com

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