4:27 a.m.
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
10:53 a.m.
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.
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.
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.
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.
* 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.
* 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.
Ciao, Luca
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
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
7:06 a.m.
On Mi, 15.04.20 11:53, Richard Guy Briggs (rgb(a)redhat.com) 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.
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
--
Lennart Poettering, Berlin
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
1:57 p.m.
On 2020-04-16 14:06, Lennart Poettering wrote:
On Mi, 15.04.20 11:53, Richard Guy Briggs (rgb(a)redhat.com) 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 <rgb(a)redhat.com>
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
2:21 p.m.
On Fr, 17.04.20 14:57, Richard Guy Briggs (rgb(a)redhat.com) wrote:
> 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
3:08 p.m.
On 2020-04-17 21:21, Lennart Poettering wrote:
On Fr, 17.04.20 14:57, Richard Guy Briggs (rgb(a)redhat.com) wrote:
> > 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 you are getting it via klog. This is what is causing the problem.
(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 <rgb(a)redhat.com>
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
4:59 p.m.
On Thu, Apr 16, 2020 at 8:45 AM Lennart Poettering
<lennart(a)poettering.net> wrote:
On Mi, 15.04.20 11:53, Richard Guy Briggs (rgb(a)redhat.com) 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.
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.
> > 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".
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.
--
paul moore
www.paul-moore.com
2:30 a.m.
On Mi, 22.04.20 17:59, Paul Moore (paul(a)paul-moore.com) wrote:
> 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".
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.
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
8:50 a.m.
On Thu, Apr 23, 2020 at 3:30 AM Lennart Poettering
<lennart(a)poettering.net> wrote:
On Mi, 22.04.20 17:59, Paul Moore (paul(a)paul-moore.com) wrote:
> > 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".
>
> 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.
> 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.
--
paul moore
www.paul-moore.com
8:57 a.m.
On Do, 23.04.20 09:50, Paul Moore (paul(a)paul-moore.com) 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?
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
9:04 a.m.
On Thu, Apr 23, 2020 at 9:57 AM Lennart Poettering
<lennart(a)poettering.net> wrote:
On Do, 23.04.20 09:50, Paul Moore (paul(a)paul-moore.com) 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
11:19 a.m.
On 4/23/2020 6:57 AM, Lennart Poettering wrote:
On Do, 23.04.20 09:50, Paul Moore (paul(a)paul-moore.com) 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?
I think it's more the "hey, watch out, here be dragons" response.
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.
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
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.
Lennart
--
Lennart Poettering, Berlin
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
11:44 a.m.
On Do, 23.04.20 09:19, Casey Schaufler (casey(a)schaufler-ca.com) wrote:
> 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
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
12:17 p.m.
On Thursday, April 23, 2020 12:44:01 PM EDT Lennart Poettering wrote:
On Do, 23.04.20 09:19, Casey Schaufler (casey(a)schaufler-ca.com)
wrote:
> > 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
>
> 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...
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
1703
days inactive
1712
days old
linux-audit@lists.linux-audit.osci.io
14 comments
7 participants
participants (7)
-
Casey Schaufler -
Lennart Poettering -
Lenny Bruzenak -
Luca BRUNO -
Paul Moore -
Richard Guy Briggs -
Steve Grubb