On Thu, Apr 23, 2020 at 9:57 AM Lennart Poettering
<[email protected]> 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?

When you can respond without making inflammatory comments such as
those above, let me know.

> 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.
>
> 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
>
> Lennart
>
> --
> Lennart Poettering, Berlin

-- 
paul moore
www.paul-moore.com


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

Reply via email to