Re: multicast listeners and audit events to kmsg

[Casey Schaufler <casey@schaufler-ca.com>]

On 4/23/2020 6:57 AM, Lennart Poettering wrote:
> On Do, 23.04.20 09:50, Paul Moore (paul@paul-moore.com) wrote:
>
>>>> 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.
> Well, that's the "audit is my private kingdom" response, right?

I think it's more the "hey, watch out, here be dragons" response.

> People are interested in collecting the audit stream without having
> the full audit daemon installed. There's useful data in the audit
> stream, already generated during really early boot, long before auditd
> runs, i.e. in the initrd. And for smaller systems auditd is not really
> something people want around.

Audit systems are tricky because they have to be high data rate,
reliable and low impact. A user space component that doesn't meet
all of these requirements 100% of the time will fail. If auditd
could be made faster, more reliable or have lower impact and still
meet the other criteria you can bet it would be.

> 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.


>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>


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