Re: multicast listeners and audit events to kmsg

From: Lennart Poettering <lennart@poettering.net>
To: Casey Schaufler <casey@schaufler-ca.com>
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 18:44:01 +0200	[thread overview]
Message-ID: <20200423164401.GA63285@gardel-login> (raw)
In-Reply-To: <f88f306c-9274-e2a6-fbc8-9e750e1289ef@schaufler-ca.com>

On Do, 23.04.20 09:19, Casey Schaufler (casey@schaufler-ca.com) wrote:

> > For example, Fedora CoreOS wants to enable selinux, thus is interested
> > in audit messages, but have no intention to install auditd, in the
> > typical, minimal images they generate. See:
> >
> > https://github.com/systemd/systemd/issues/15324
>
> If you can do a better job of consuming audit data than auditd I for one
> would be impressed. I've written multiple audit systems over the years
> (not this one, but the issues are all familiar and the solutions similar)
> and the kernel -> user interface is much, much harder than it looks.

The audit support in journald is really not about doing "a better
job", or being "faster". Totally not. It's about making a common case
easy, that's all.

There are at least two very different usecases for the audit data:

1. auditing for the purpose of auditing (i.e. government style)

2. people who just want to debug their frickin selinux issues

auditd is great for #1. for #2 people don't want to bother, journald
is fine, speed or reliability or any such don't matter, the mcast
stuff is definitely good enough, and the benefit of collecting the
AVCs via audit from earliest boot on is a lot more interesting and
important for such uses than to wonder what happens if the queue runs
over...

I mean, can't you understand that there's a theme here of people
wanting to pick up basic audit messages without installing the whole
auditd package and running a daemon all the time? CoreOS wants this,
and journald implements this for a reason...

I am not sure what the big problem would be with just providing us
with a control to turn off the kmsg forwarding with a sysctl or
netlink command or so, when userspace requests that. if we had that,
auditd could do its own thing owning audit, journald could do its own
thing with a stream at the side, and we wouldn't step on each others
toes.

Anyway, I accept this discussion is not leading anywhere, let's end it
here. I do sense the condescension, and I don't need more of that.

Lennart

--
Lennart Poettering, Berlin

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