On 4/23/2020 6:57 AM, Lennart Poettering wrote: > On Do, 23.04.20 09:50, Paul Moore ([email protected]) 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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit > -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
