1:46 p.m.
On 4/16/20 6:06 AM, Lennart Poettering wrote:
> I'm regretting having developped this feature due to the problems it has
> caused the audit developpers and innocent bystanders. Instead, an audit
> daemon plugin should have been used to direct log records to
> journald.
I am sorry, but this doesn't work for us. We do not want to do IPC to
some audit daemon (journald runs during early boot and in the initrd,
it has a very special relationship with early boot stuff and PID1, and
thus being a client to other daemons is highly problematic, if those
other daemons are managed by systemd as well, and run only during later
boot). In fact we don't even want the dependency on the audit
userspace package at all.
In systemd we just think that audit information is pretty interesting
even if you don't want to buy into the whole government regulation
stuff, even if you don't want the auditd to run, and the full audit
package installed. i.e. we want to collect the data as one of our
various data streams, as a secondary consumer of it, and leave it to
the audit package itself to do everything else and be the primary
consumer of it.
Using the multicast group is our way of saying: "we don't want to own
the audit stream, you can keep it; we just want to have a look
too".
I believe that there are plenty of systems where audit logs should be
collected but the whole auditd daemon should not be around, i.e. where
the usefulness of the data is acknowledged without acknowledging that
government regulations matter or the audit package should exist on
every single system.
I do not understand "I believe that there are plenty of systems where
audit logs should be collected but the whole auditd daemon should not be
around..."... and without supportive data, tend to think that is untrue.
Unless of source, the real desire is to provide a "better" audit logging
system.
The "whole audit daemon" sounds like it is huge, which it isn't ... and
regardless, if logs are collected, doesn't this imply _something_ is
managing the logs? We currently call that "auditd".
> Well, Steve, Paul and myself are all fairly firmly on the side of
the
> problem being in systemd and its overreach.
We explicitly don#t want to own the audit stream, that's why we don#t
use the unicast stuff, but only subscribe via the mcast stuff, so that
we don't interfere with auditd's own processing if it is running, and
we don't exlcude auditd from running. we want a mode where audit is
collected, just like that without any auditd package installed, but if
you decide to install auditd things just work too.
>> For Richard and the "explicit configuration" approach in particular,
I'm
>> missing some further details:
>> * Is the current behavior considered buggy, or is that intended to be
>> kept as the default?
> The current systemd behaviour of unilatterally enabling audit logging is
> considered buggy. The current audit kernel behaviour is considered
> intentional.
Well, we try hard to not step on your toes and do not use the unicast
stuff and do not pretend to be auditd, so that auditd can be installed
and run in parallel to journald with us being in the backseat. It's my
understanding that the mcast stuff was added for this kind of thing,
except that it never became useful, since it also means that kmsg is
spammed by audit.
THere's a usecase for collecting audit but not running the whole audit
userspace suite, can't you see that?
I must admit that I cannot see a use case outside the realm of "because
I want to".
i.e. i for one am interested in
selinux audit msgs, but I am not interested in the audit toolchain I
must say, I really am not, and I am pretty sure there are many others
like me. But you basically tell us to go away, or buy into the whole
audit userspace.
Seems like a lot of work to avoid using auditd and the existing
audispd-syslog plugin. It's known to work reasonably well. You could, if
desired, turn off the writing of events to disk and still get everything
interpreted/ordered through the audisp-syslog plugin - or write a simple
similar one? But I assume you know that already.
I am quite sure there are many others like me that cannot envision the
relevance of having kernel auditing without audit userspace tools
involved, at least not in any environment where assurance exists.
The "whole audit userspace" being intimately connected to the kernel
production of events, ensures (as best possible IMHO) that the while
kernel supplies accuracy/validity, the userspace receiver then ensures
event assimilation, log handling, dissemination. IIUC, you really DO
want to pretend to be auditd, rather than get the auditd-disseminated
results. That's fine, but may as well be honest.
I have to think about it, but in fact there may be a good reason why I
would not want the multicast option available. I'd feel inclined, based
on my own prejudice of delivering secure (as possible) systems, to
instead find a way to limit only the auditd from the supplied audit rpm
as being the sole unicast recipient. I do see your point about a kmsg
forwarding disable option for people for whom this behavior isn't desired.
Just for reference, "government regulations matter" is a true statement
and there are communities who depend on a reliable, secure audit system
for adherence. Some of these communities are actually seen as vital. I
understand that you are a distinguished linux contributor, and I am not,
but from my perspective as a person who uses, delivers and maintains
systems where the current audit userspace toolset is used in the manner
for which it is intended, I'm really having a hard time understanding
why you would not simply take the existing output facility and use it
however you choose. The startup timing argument doesn't fly with me, sorry.
Anyway, that's my perspective.
V/R,
LCB
--
LC Bruzenak
MagitekLTD