multicast listeners and audit events to kmsg
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
After a bunch of digging, it seems like this is due to a long-standing RFE on the kernel side [1] (plus further references on BZ and LKML).
[1] https://github.com/linux-audit/audit-kernel/issues/102
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 not personally knowledgeable enough to judge kernel-land approaches (nor to implement them), but I'd be happy if the audit folks could converge to a consensus on how to implement this RFE, how it would be consumed by userland, and what would be the kernel default behavior once this RFE is implemented.
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?
* Would this be tweaked via a (boolean?) sysctl, and what would be the semantics of flipping it?
* How would this play with namespacing, especially netns?
Ciao, Luca
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 9 lines · Luca BRUNO
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].
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.
Quoted 10 lines
After a bunch of digging, it seems like this is due to a long-standing RFE on the kernel side [1] (plus further references on BZ and LKML).
[1] https://github.com/linux-audit/audit-kernel/issues/102
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.
My understanding is Paul does not think multicast listener detection is reliable enough either.
Quoted 5 lines
I'm not personally knowledgeable enough to judge kernel-land approaches (nor to implement them), but I'd be happy if the audit folks could converge to a consensus on how to implement this RFE, how it would be consumed by userland, and what would be the kernel default behavior once this RFE is implemented.
Well, Steve, Paul and myself are all fairly firmly on the side of the problem being in systemd and its overreach.
Quoted 4 lines
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.
Quoted 2 lines
* 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.
Quoted 1 line
* How would this play with namespacing, especially netns?
Currently, it is moot since there can be only one audit daemon and it listens in all network namespaces.
The future needs some thought since there are tickets open to allow multiple audit daemons and to devise a way to route messages to those multiple audit daemons.
Quoted 1 line
Ciao, Luca
- 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
Quoted 9 lines · Richard Guy Briggs
Quoted 8 lines · Luca BRUNO
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].
Quoted 6 lines
Quoted 1 line
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.
Quoted 10 lines
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 4 lines
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.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.
Quoted 6 lines
Quoted 2 lines
* 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
--
Lennart Poettering, Berlin
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 25 lines · Lennart Poettering
Quoted 5 lines
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".
Quoted 5 lines
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".
Quoted 23 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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".
Quoted 5 lines
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
Signature · 7 lines
LC Bruzenak MagitekLTD -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 82 lines · Lennart Poettering
Quoted 9 lines · Richard Guy Briggs
Quoted 8 lines · Luca BRUNO
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].
Quoted 6 lines
Quoted 1 line
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.
Quoted 10 lines
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 10 lines
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.
Quoted 3 lines
Quoted 2 lines
* Would this be tweaked via a (boolean?) sysctl, and what would be the semantics of flipping it?
Quoted 8 lines
Quoted 3 lines
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
Quoted 9 lines · Lennart Poettering
Quoted 7 lines · Richard Guy Briggs
Quoted 6 lines
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.
Quoted 6 lines
Quoted 2 lines
Where your claim falls flat is that systemd/journald is stepping on auditd's toes by enabling audit. Enabling audit is auditd's job.
Again, we are interested in the audit information, because we think it's useful. If we wouldn't enable audit in the kernel we wouldn't get it. Hence we enable audit.
But you are getting it via klog. This is what is causing the problem.
Quoted 8 lines
(But see: https://github.com/systemd/systemd/pull/15444 — with that it's now configurable, but it still defaults to on, because we actually think the data is useful, and we think it's useful event without auditd around, regardless if that's because we run in the earliest initrd where there never is auditd around or because we run during normal operation and auditd is simply not installed.)
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
Quoted 9 lines · Richard Guy Briggs
Quoted 6 lines
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.
Again, we are interested in the audit information, because we think it's useful. If we wouldn't enable audit in the kernel we wouldn't get it. Hence we enable audit.
(But see: https://github.com/systemd/systemd/pull/15444 — with that it's now configurable, but it still defaults to on, because we actually think the data is useful, and we think it's useful event without auditd around, regardless if that's because we run in the earliest initrd where there never is auditd around or because we run during normal operation and auditd is simply not installed.)
Lennart
--
Lennart Poettering, Berlin
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 17 lines · Lennart Poettering
Quoted 9 lines · Richard Guy Briggs
Quoted 8 lines · Luca BRUNO
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].
Quoted 6 lines
Quoted 1 line
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.
Quoted 7 lines
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.
I'm a little late to this discussion due to some other audit and kernel issues, but I wanted to both add a little content and additional voice to what Richard and Lenny have already said.
As far as reliability is concerned, the "reliable" communication channel is the unicast netlink channel between the audit daemon and the kernel. Sure, it isn't perfect but it is better than both the multicast netlink channel and the kernel's message buffer. If you look at the kernel's audit code, you'll see that printk/kmsg is really only used as a last resort when the main unicast netlink channel is down. We are not claiming it is a reliable mechanism, it is just all the kernel has at that point*.
* A quick comment on the multicast netlink channel: it was always seen as a separate out-of-band, unreliable mechanism to communicate audit records to systemd (and presumably others, but I'm not aware of any). There has never been any serious thought amongst the audit developers to support the multicast netlink channel beyond this, and I don't see anything changing that in the immediate future. FWIW, I agree with Richard's comment that the netlink multicast channel was a mistake; it wasn't my call to make at the time, but I don't think we would merge that code if it came up today. However, it was merged and we will continue to support it within the scope of its original functionality.
Quoted 27 lines
Quoted 10 lines
Quoted 5 lines
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.
Quoted 3 lines
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".
The problem is that on systems without a running audit daemon there is no one to "own" the audit stream so it floods the kmsg, spills onto the console, and everyone's feet get wet. Are we going to blame the source of the stream, or the person who turned on the tap in the first place and caused the mess?
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.
Signature · 8 lines
paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 12 lines · Paul Moore
Quoted 11 lines
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".
Quoted 5 lines
The problem is that on systems without a running audit daemon there is no one to "own" the audit stream so it floods the kmsg, spills onto the console, and everyone's feet get wet. Are we going to blame the source of the stream, or the person who turned on the tap in the first place and caused the mess?
It's not a question of blaming anyone. We are just looking for a nice way so that we can get the mcast stuff without the kmsg stuff. it can totally be something we toggle explicitly, i have no problem with that.
Quoted 3 lines
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?
Lennart
--
Lennart Poettering, Berlin
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 34 lines · Lennart Poettering
Quoted 12 lines · Paul Moore
Quoted 11 lines
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".
Quoted 5 lines
The problem is that on systems without a running audit daemon there is no one to "own" the audit stream so it floods the kmsg, spills onto the console, and everyone's feet get wet. Are we going to blame the source of the stream, or the person who turned on the tap in the first place and caused the mess?
It's not a question of blaming anyone. We are just looking for a nice way so that we can get the mcast stuff without the kmsg stuff. it can totally be something we toggle explicitly, i have no problem with that.
Quoted 3 lines
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.
Quoted 3 lines
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.
Signature · 8 lines
paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 11 lines · Lennart Poettering
Quoted 10 lines · Paul Moore
Quoted 10 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 16 lines
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
Signature · 8 lines
paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 10 lines · Paul Moore
Quoted 10 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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?
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
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 11 lines · Lennart Poettering
Quoted 9 lines · Paul Moore
Quoted 9 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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?
I think it's more the "hey, watch out, here be dragons" response.
Quoted 5 lines
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.
Audit systems are tricky because they have to be high data rate, reliable and low impact. A user space component that doesn't meet all of these requirements 100% of the time will fail. If auditd could be made faster, more reliable or have lower impact and still meet the other criteria you can bet it would be.
Quoted 5 lines
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:
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.
Quoted 12 lines
Lennart
--
Lennart Poettering, Berlin--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 10 lines · Casey Schaufler
Quoted 5 lines
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:
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...
I mean, can't you understand that there's a theme here of people wanting to pick up basic audit messages without installing the whole auditd package and running a daemon all the time? CoreOS wants this, and journald implements this for a reason...
I am not sure what the big problem would be with just providing us with a control to turn off the kmsg forwarding with a sysctl or netlink command or so, when userspace requests that. if we had that, auditd could do its own thing owning audit, journald could do its own thing with a stream at the side, and we wouldn't step on each others toes.
Anyway, I accept this discussion is not leading anywhere, let's end it here. I do sense the condescension, and I don't need more of that.
Lennart
--
Lennart Poettering, Berlin
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 20 lines · EDT Lennart Poettering
Quoted 10 lines · Casey Schaufler
Quoted 5 lines
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:
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)
Quoted 8 lines
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