Re: multicast listeners and audit events to kmsg

[Lenny Bruzenak <lenny@magitekltd.com>]

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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit