On Thursday, April 23, 2020 12:44:01 PM EDT Lennart Poettering wrote:
> On Do, 23.04.20 09:19, Casey Schaufler ([email protected]) 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...

It won't. Audit events are held until the audit daemon arrives. Also, selinux 
sends AVC's to syslog without any audit daemon intervention. So, you already 
have access to what you say you need.

Try it. Uninstall the audit daemon, set journald to not enable the audit 
system. Look in dmesg or syslog. You should see any AVC's that were created.

-Steve


--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Reply via email to