Re: multicast listeners and audit events to kmsg
On 4/23/2020 6:57 AM, Lennart Poettering wrote:
On Do, 23.04.20 09:50, Paul Moore (paul(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit