On 2020-04-16 14:06, Lennart Poettering wrote: > On Mi, 15.04.20 11:53, Richard Guy Briggs ([email protected]) wrote: > > > On 2020-04-14 09:27, Luca BRUNO wrote: > > > Hi all, > > > I'm trying to re-spin a very old thread related to multicast listeners > > > and audit events to kmsg. > > > > > > One surprising kernel behavior when using only a multicast listener > > > to collect audit events (in this case, systemd-journald) is that > > > audit events end up spamming the console [0]. > > > > > > [0] https://github.com/systemd/systemd/issues/15324 > > > > This is not surprising, since the multicast audit socket is not > > considered a reliable sink for the audit log and thus cannot be relied > > upon to key the decision to forward potentially lost messages to the > > system log. > > kmsg is not reliable either, it aggressively and silently drops > messages if the log buffer runs full, which it does pretty quickly. > > hence there's really no difference here if data is written to the > mcast socket or to kmsg, in both cases messages are dropped when the > buffer limits are hit, hence it should be entirely fine to do only one > of the twoif the unicast client to audit is not running. > > > > Apparently there isn't a clear consensus on how this should be > > > approached. Looking at the github and bugzilla tickets, it seems to me > > > that Eric and Paul initially had in mind some logic based on multicast > > > listener detection, while Richard doesn't deem that reliable and > > > suggests an explicit configuration. > > > > 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. > > > 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.
Where your claim falls flat is that systemd/journald is stepping on auditd's toes by enabling audit. Enabling audit is auditd's job. > THere's a usecase for collecting audit but not running the whole audit > userspace suite, can't you see that? 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. > > > > * Would this be tweaked via a (boolean?) sysctl, and what would be the > > > semantics of flipping it? > > > > It would be controlled via a new audit unicast netlink message similar > > to the one that enabled auditing in the first place by systemd that > > would explicitly disable klog when a multicast client is connected. > > It would be excellent to have an option to turn off the kmsg > forwarding. > > Lennart - RGB -- Richard Guy Briggs <[email protected]> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
