1:19 p.m.
Neal Gompa wrote:
> On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto
<sergio(a)serjux.com> wrote:
> ...
>
> a big BTW when /etc/init.d/network will be removed or migrate to
> systemd scripts ?
>
> rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> %{name}\n"
>
> packge = initscripts-10.09-1.fc34.src.rpm
> sub-package = network-scripts
It's deprecated and expected to be retired eventually. I doubt a
"port" would ever happen.
initscripts is needed by audit: https://bugzilla.redhat.com/2029105
1:37 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
Neal Gompa wrote:
> > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto <sergio(a)serjux.com>
wrote:
> > ...
> >
> > a big BTW when /etc/init.d/network will be removed or migrate to
> > systemd scripts ?
> >
> > rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
> > %{name}\n"
> >
> > packge = initscripts-10.09-1.fc34.src.rpm
> > sub-package = network-scripts
> It's deprecated and expected to be retired eventually. I doubt a
> "port" would ever happen.
initscripts is needed by audit: https://bugzilla.redhat.com/2029105
network-scripts was split out as a subpackage specifically so it can be
excluded from images/installs or deprecated without doing the same to
the whole of initscripts, IIRC.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2:17 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 05, 2022 at 11:37:48AM -0800, Adam Williamson wrote:
On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
> Neal Gompa wrote:
>
> > > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto
<sergio(a)serjux.com> wrote:
> > > ...
> > >
> > > a big BTW when /etc/init.d/network will be removed or migrate to
> > > systemd scripts ?
> > >
> > > rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package
=
> > > %{name}\n"
> > >
> > > packge = initscripts-10.09-1.fc34.src.rpm
> > > sub-package = network-scripts
>
> > It's deprecated and expected to be retired eventually. I doubt a
> > "port" would ever happen.
>
> initscripts is needed by audit: https://bugzilla.redhat.com/2029105
This is really sad. Somebody who understands audit should just propose a solution.
We shouldn't have an archaic technology kept in Fedora for 10 years
because of one package.
network-scripts was split out as a subpackage specifically so it can
be
excluded from images/installs or deprecated without doing the same to
the whole of initscripts, IIRC.
I'd say we want to get rid of both ;)
Zbyszek
2:31 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wednesday, January 5, 2022 3:17:43 PM EST Zbigniew Jędrzejewski-Szmek
wrote:
On Wed, Jan 05, 2022 at 11:37:48AM -0800, Adam Williamson wrote:
> On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
> > Neal Gompa wrote:
> > > > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto
> > > > <sergio(a)serjux.com> wrote: ...
> > > >
> > > > a big BTW when /etc/init.d/network will be removed or migrate to
> > > > systemd scripts ?
> > > >
> > > > rpm -qf /etc/init.d/network --qf "packge =
> > > > %{sourcerpm}\nsub-package =
> > > > %{name}\n"
> > > >
> > > > packge = initscripts-10.09-1.fc34.src.rpm
> > > > sub-package = network-scripts
> > >
> > > It's deprecated and expected to be retired eventually. I doubt a
> > > "port" would ever happen.
> >
> > initscripts is needed by audit: https://bugzilla.redhat.com/2029105
This is really sad. Somebody who understands audit should just propose a
solution. We shouldn't have an archaic technology kept in Fedora for 10
years because of one package.
I think audit can be moved to initscripts-service in Fedora. Would that help?
-Steve
10:16 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 05, 2022 at 03:31:43PM -0500, Steve Grubb wrote:
On Wednesday, January 5, 2022 3:17:43 PM EST Zbigniew
Jędrzejewski-Szmek
wrote:
> On Wed, Jan 05, 2022 at 11:37:48AM -0800, Adam Williamson wrote:
> > On Wed, 2022-01-05 at 20:19 +0100, Xose Vazquez Perez wrote:
> > > Neal Gompa wrote:
> > > > > On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto
> > > > > <sergio(a)serjux.com> wrote: ...
> > > > >
> > > > > a big BTW when /etc/init.d/network will be removed or migrate
to
> > > > > systemd scripts ?
> > > > >
> > > > > rpm -qf /etc/init.d/network --qf "packge =
> > > > > %{sourcerpm}\nsub-package =
> > > > > %{name}\n"
> > > > >
> > > > > packge = initscripts-10.09-1.fc34.src.rpm
> > > > > sub-package = network-scripts
> > > >
> > > > It's deprecated and expected to be retired eventually. I doubt a
> > > > "port" would ever happen.
> > >
> > > initscripts is needed by audit: https://bugzilla.redhat.com/2029105
>
> This is really sad. Somebody who understands audit should just propose a
> solution. We shouldn't have an archaic technology kept in Fedora for 10
> years because of one package.
I think audit can be moved to initscripts-service in Fedora. Would that help?
No, just moving things around is not the point. We want auditd to be managed
as a first-class systemd service, without pulling in all the shell baggage.
I know that you said that the scripts are needed because of "magic stuff™"
that the scripts do, but sorry, that's not a justification: *everything* that
can be done using a shell script can also be reimplemented independently.
Right now audit pulls in the whole initscripts stack, this should all be replaced
by some small helper. (Maybe a separate binary, or a small shell script, or
maybe something in auditctl…. I don't know because I don't know audit.)
Zbyszek
10:48 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
I know that you said that the scripts are needed because of "magic stuff™"
that the scripts do, but sorry, that's not a justification: *everything* that
can be done using a shell script can also be reimplemented independently.
Right now audit pulls in the whole initscripts stack, this should all be replaced
by some small helper. (Maybe a separate binary, or a small shell script, or
maybe something in auditctl…. I don't know because I don't know audit.)
As I understand the bug, it's not a question of whether the thing can
be done, but whether it can be known *who did it*.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
12:02 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek
wrote:
>
> I know that you said that the scripts are needed because of "magic
stuff™"
> that the scripts do, but sorry, that's not a justification: *everything* that
> can be done using a shell script can also be reimplemented independently.
> Right now audit pulls in the whole initscripts stack, this should all be replaced
> by some small helper. (Maybe a separate binary, or a small shell script, or
> maybe something in auditctl…. I don't know because I don't know audit.)
As I understand the bug, it's not a question of whether the thing can
be done, but whether it can be known *who did it*.
There is no magic functionality in the kernel that specifically records that
something was executed by some specific script. If that scripts sends a signal
somewhere, you can send the same signal with the same sender info and the same privileges
using bash/python/C/Rust or even assembly. So the "who did it" information
can be provided in a different way without pulling in the initscripts stack,
or it is bogus, or maybe even both.
Zbyszek
12:17 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 18:02 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
> On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > I know that you said that the scripts are needed because of "magic
stuff™"
> > that the scripts do, but sorry, that's not a justification: *everything*
that
> > can be done using a shell script can also be reimplemented independently.
> > Right now audit pulls in the whole initscripts stack, this should all be
replaced
> > by some small helper. (Maybe a separate binary, or a small shell script, or
> > maybe something in auditctl…. I don't know because I don't know
audit.)
>
> As I understand the bug, it's not a question of whether the thing can
> be done, but whether it can be known *who did it*.
There is no magic functionality in the kernel that specifically records that
something was executed by some specific script. If that scripts sends a signal
somewhere, you can send the same signal with the same sender info and the same
privileges
using bash/python/C/Rust or even assembly. So the "who did it" information
can be provided in a different way without pulling in the initscripts stack,
or it is bogus, or maybe even both.
In this case the "who" is the user, not the script.
The problem of going through systemctl is that the "who" is lost
because all the audit system can see is that systemd started the
action. Basically the communication between systemctl and systemd masks
the identity of the user that initiated the action.
I believe a solution needs to be found between systemd and the audit
subsystem in general so that we remove this whole class of issues
altogether.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
2:01 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, Jan 06, 2022 at 01:17:01PM -0500, Simo Sorce wrote:
On Thu, 2022-01-06 at 18:02 +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
> > On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > >
> > > I know that you said that the scripts are needed because of "magic
stuff™"
> > > that the scripts do, but sorry, that's not a justification:
*everything* that
> > > can be done using a shell script can also be reimplemented independently.
> > > Right now audit pulls in the whole initscripts stack, this should all be
replaced
> > > by some small helper. (Maybe a separate binary, or a small shell script,
or
> > > maybe something in auditctl…. I don't know because I don't know
audit.)
> >
> > As I understand the bug, it's not a question of whether the thing can
> > be done, but whether it can be known *who did it*.
>
> There is no magic functionality in the kernel that specifically records that
> something was executed by some specific script. If that scripts sends a signal
> somewhere, you can send the same signal with the same sender info and the same
privileges
> using bash/python/C/Rust or even assembly. So the "who did it"
information
> can be provided in a different way without pulling in the initscripts stack,
> or it is bogus, or maybe even both.
In this case the "who" is the user, not the script.
Yes, obviously the user is outside of the machine and "user" always
means some program running under the UID assigned to the user.
All I'm trying to say is that if you can make one implementation of this
program (e.g. a set of bash scripts) send some bit of information, you can
make another implementation send the same signal.
The problem of going through systemctl is that the "who" is
lost
because all the audit system can see is that systemd started the
action. Basically the communication between systemctl and systemd masks
the identity of the user that initiated the action.
Yes, systemctl doesn't save this information. So audit uses some
alternative command to send this information somewhere. This
alternative command should just send this bit of information where appropriate
and then call systemctl. More-or-less as things are now, but without
the initscripts baggage.
I believe a solution needs to be found between systemd and the audit
subsystem in general so that we remove this whole class of issues
altogether.
If there's a need to add something to systemctl or systemd, we can do
it. But it's never been clearly articulated afaik.
Zbyszek
2:17 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 20:01 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 06, 2022 at 01:17:01PM -0500, Simo Sorce wrote:
> On Thu, 2022-01-06 at 18:02 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
> > > On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > >
> > > > I know that you said that the scripts are needed because of
"magic stuff™"
> > > > that the scripts do, but sorry, that's not a justification:
*everything* that
> > > > can be done using a shell script can also be reimplemented
independently.
> > > > Right now audit pulls in the whole initscripts stack, this should all
be replaced
> > > > by some small helper. (Maybe a separate binary, or a small shell
script, or
> > > > maybe something in auditctl…. I don't know because I don't
know audit.)
> > >
> > > As I understand the bug, it's not a question of whether the thing can
> > > be done, but whether it can be known *who did it*.
> >
> > There is no magic functionality in the kernel that specifically records that
> > something was executed by some specific script. If that scripts sends a signal
> > somewhere, you can send the same signal with the same sender info and the same
privileges
> > using bash/python/C/Rust or even assembly. So the "who did it"
information
> > can be provided in a different way without pulling in the initscripts stack,
> > or it is bogus, or maybe even both.
>
> In this case the "who" is the user, not the script.
Yes, obviously the user is outside of the machine and "user" always
means some program running under the UID assigned to the user.
All I'm trying to say is that if you can make one implementation of this
program (e.g. a set of bash scripts) send some bit of information, you can
make another implementation send the same signal.
> The problem of going through systemctl is that the "who" is lost
> because all the audit system can see is that systemd started the
> action. Basically the communication between systemctl and systemd masks
> the identity of the user that initiated the action.
Yes, systemctl doesn't save this information. So audit uses some
alternative command to send this information somewhere. This
alternative command should just send this bit of information where appropriate
and then call systemctl. More-or-less as things are now, but without
the initscripts baggage.
I believe the problem is that it is not just a fire and forget signal,
any kernel syscall can be traced back to that user by this method, so
anything the "scripts" do can be audited.
> I believe a solution needs to be found between systemd and the
audit
> subsystem in general so that we remove this whole class of issues
> altogether.
If there's a need to add something to systemctl or systemd, we can do
it. But it's never been clearly articulated afaik.
I am afraid the hurdle, so far, is that there is a belief that the only
way to get valid audit logs when systemd-init is involved is to trust
the whole of it, which would require the development of a whole trusted
audit subsystem/hand-off within systemd.
I think that potentially one option would be to provide a kernel audit
API that systemd could be trusted to use to set the user ids so that
the audit subsystem is given those when there is the systemctl ->
systemd hand-off.
But that requires the audit and systemd teams to agree on what that
trust and those controls means, and figure out how to comply to all
regulations in the process of adding this stuff. This is probably no
small feat.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
12:55 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Hello,
On Thursday, January 6, 2022 1:02:36 PM EST Zbigniew Jędrzejewski-Szmek
wrote:
On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
> On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > I know that you said that the scripts are needed because of "magic
> > stuff™" that the scripts do, but sorry, that's not a justification:
It is the justification. The audit system has regulatory requirements imposed
on it. This is required by common criteria and subsequently depended on for
PCI-DSS, CIS, DISA STIG, NIST risk management framework, and many other
security or regulatory schemes.
> > *everything* that can be done using a shell script can also
be
> > reimplemented independently. Right now audit pulls in the whole
> > initscripts stack, this should all be replaced by some small helper.
I moved it to initscripts-service in rawhide.
> > (Maybe a separate binary, or a small shell script, or maybe
something
> > in auditctl…. I don't know because I don't know audit.)>
It would be better if there was a systemctl solution. Any solution I
implement will be met with you need to migrate to systemctl. There have been
multiple bz opened and closed on this.
> As I understand the bug, it's not a question of whether the
thing can
> be done, but whether it can be known *who did it*.
Exactly. And "who" means login uid, pid, and their security label. You can
only get this if the signal is sent from the user's context.
There is no magic functionality in the kernel that specifically
records
that something was executed by some specific script.
There actually is magic in the kernel that records who sent a signal to the
audit daemon and the necessary atributes. This functionality has been there
since at least 2005. It's not new.
If that scripts sends a signal somewhere, you can send the same
signal with
the same sender info and the same privileges using bash/python/C/Rust or
even assembly. So the "who did it" information can be provided in a
different way without pulling in the initscripts stack, or it is bogus, or
maybe even both.
I honestly don't understand the revulsion of pulling in initscripts.
However, it should be minimal now.
Cheers,
-Steve
2:09 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, Jan 06, 2022 at 01:55:50PM -0500, Steve Grubb wrote:
Hello,
On Thursday, January 6, 2022 1:02:36 PM EST Zbigniew Jędrzejewski-Szmek
wrote:
> On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
> > On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > I know that you said that the scripts are needed because of "magic
> > > stuff™" that the scripts do, but sorry, that's not a
justification:
It is the justification. The audit system has regulatory requirements imposed
on it. This is required by common criteria and subsequently depended on for
PCI-DSS, CIS, DISA STIG, NIST risk management framework, and many other
security or regulatory schemes.
> > > *everything* that can be done using a shell script can also be
> > > reimplemented independently. Right now audit pulls in the whole
> > > initscripts stack, this should all be replaced by some small helper.
I moved it to initscripts-service in rawhide.
> > > (Maybe a separate binary, or a small shell script, or maybe something
> > > in auditctl…. I don't know because I don't know audit.)>
It would be better if there was a systemctl solution. Any solution I
implement will be met with you need to migrate to systemctl. There have been
multiple bz opened and closed on this.
> > As I understand the bug, it's not a question of whether the thing can
> > be done, but whether it can be known *who did it*.
Exactly. And "who" means login uid, pid, and their security label. You can
only get this if the signal is sent from the user's context.
> There is no magic functionality in the kernel that specifically records
> that something was executed by some specific script.
There actually is magic in the kernel that records who sent a signal to the
audit daemon and the necessary atributes. This functionality has been there
since at least 2005. It's not new.
Right, so is /usr/bin/stop-audit with the following contents the solution:
---------------
#!/bin/sh
set -e
exec kill $(systemctl show -P MainPID auditd)
---------------
?
Zbyszek
2:23 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 20:09 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 06, 2022 at 01:55:50PM -0500, Steve Grubb wrote:
> Hello,
>
> On Thursday, January 6, 2022 1:02:36 PM EST Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
> > > On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > > I know that you said that the scripts are needed because of
"magic
> > > > stuff™" that the scripts do, but sorry, that's not a
justification:
>
> It is the justification. The audit system has regulatory requirements imposed
> on it. This is required by common criteria and subsequently depended on for
> PCI-DSS, CIS, DISA STIG, NIST risk management framework, and many other
> security or regulatory schemes.
>
>
> > > > *everything* that can be done using a shell script can also be
> > > > reimplemented independently. Right now audit pulls in the whole
> > > > initscripts stack, this should all be replaced by some small helper.
>
> I moved it to initscripts-service in rawhide.
>
> > > > (Maybe a separate binary, or a small shell script, or maybe
something
> > > > in auditctl…. I don't know because I don't know audit.)>
>
> It would be better if there was a systemctl solution. Any solution I
> implement will be met with you need to migrate to systemctl. There have been
> multiple bz opened and closed on this.
>
> > > As I understand the bug, it's not a question of whether the thing can
> > > be done, but whether it can be known *who did it*.
>
> Exactly. And "who" means login uid, pid, and their security label. You can
> only get this if the signal is sent from the user's context.
>
> > There is no magic functionality in the kernel that specifically records
> > that something was executed by some specific script.
>
> There actually is magic in the kernel that records who sent a signal to the
> audit daemon and the necessary atributes. This functionality has been there
> since at least 2005. It's not new.
Right, so is /usr/bin/stop-audit with the following contents the solution:
---------------
#!/bin/sh
set -e
exec kill $(systemctl show -P MainPID auditd)
---------------
?
I do not believe this is currently usable for audit because the
information on who requested to kill the process is lost this way.
In terms of audit you can audit that user XYZ ran /usr/bin/stop-audit,
however the process that actually then kills the audit daemon will not
have the magic markers in the kernel side and will instead be the
systemd process.
This breaks the audit log chain, as there is no way to audit that
systemd is operating on behalf of that user. The audit trail chain is
broken by the systemcl -> systemd jump.
This is the problem that need to be solved to get rid of audit's use of
shell scripts that directly perform operations wrt the kernel.
I wonder if another option is to have the audit code in the kernel
intercept systemcl messages sent to systemd and interpret the commands
and log what they are asking ...
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
2:57 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Hello,
On Thursday, January 6, 2022 3:23:15 PM EST Simo Sorce wrote:
> > There actually is magic in the kernel that records who sent
a signal to
> > the audit daemon and the necessary atributes. This functionality has
> > been there since at least 2005. It's not new.
>
> Right, so is /usr/bin/stop-audit with the following contents the
> solution:
> ---------------
> #!/bin/sh
> set -e
> exec kill $(systemctl show -P MainPID auditd)
> ---------------
> ?
In essense, yeah. But there are a lot more signals than just SIGTERM and as I
said before, the systemd crowd has done such a good job taking over this
space that everyone will start asking that this be migrated to systemctl so
there is one and only one way to do things.
I do not believe this is currently usable for audit because the
information on who requested to kill the process is lost this way.
In terms of audit you can audit that user XYZ ran /usr/bin/stop-audit,
however the process that actually then kills the audit daemon will not
have the magic markers in the kernel side and will instead be the
systemd process.
Yep, that is the crux of the problem.
This breaks the audit log chain, as there is no way to audit that
systemd is operating on behalf of that user. The audit trail chain is
broken by the systemcl -> systemd jump.
This is the two generals problem. (How do you know the message really came
from the other general when it traveled through hostile territory?)
This is the problem that need to be solved to get rid of audit's
use of
shell scripts that directly perform operations wrt the kernel.
There have been several proposals. One is that systemctl could check a config
file and see that it needs to send a signal and which one. Another is systemd
could look it up in the unit files and answer back that systemctl should send
a signal instead.
I wonder if another option is to have the audit code in the kernel
intercept systemcl messages sent to systemd and interpret the commands
and log what they are asking ...
That's a new one. :-)
I'm afraid that would require knowing which sockets are part of the dbus comm
system and its protocol. Parsing dbus messages in the kernel is not something
the upstream kernel maintainers will take lightly. I'd expect pushback on
that.
Cheers,
-Steve
4:17 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, Jan 06, 2022 at 03:57:57PM -0500, Steve Grubb wrote:
Hello,
On Thursday, January 6, 2022 3:23:15 PM EST Simo Sorce wrote:
> > > There actually is magic in the kernel that records who sent a signal to
> > > the audit daemon and the necessary atributes. This functionality has
> > > been there since at least 2005. It's not new.
> >
> > Right, so is /usr/bin/stop-audit with the following contents the
> > solution:
> > ---------------
> > #!/bin/sh
> > set -e
> > exec kill $(systemctl show -P MainPID auditd)
> > ---------------
> > ?
In essense, yeah. But there are a lot more signals than just SIGTERM and as I
said before, the systemd crowd has done such a good job taking over this
space that everyone will start asking that this be migrated to systemctl so
there is one and only one way to do things.
auditd(8) lists 5 signals… This should be doable in two dozen lines.
This would cover the requirement to have those direct invocations logged.
> I do not believe this is currently usable for audit because the
> information on who requested to kill the process is lost this way.
>
> In terms of audit you can audit that user XYZ ran /usr/bin/stop-audit,
> however the process that actually then kills the audit daemon will not
> have the magic markers in the kernel side and will instead be the
> systemd process.
Yep, that is the crux of the problem.
> This breaks the audit log chain, as there is no way to audit that
> systemd is operating on behalf of that user. The audit trail chain is
> broken by the systemcl -> systemd jump.
This is the two generals problem. (How do you know the message really came
from the other general when it traveled through hostile territory?)
> This is the problem that need to be solved to get rid of audit's use of
> shell scripts that directly perform operations wrt the kernel.
There have been several proposals. One is that systemctl could check a config
file and see that it needs to send a signal and which one. Another is systemd
could look it up in the unit files and answer back that systemctl should send
a signal instead.
There are two ways to look at this: one way is that people interact with
auditd from the commandline and the script that was discussed above is a good
replacement that provides ~same functionality as what we have now.
Another way is to say that people interact with auditd through systemd,
and since the dbus api is open, there is an infinite number of ways to
call it, including systemctl, systemctl -M (injection into a container),
systemctl -H (ssh into another machine), the KDE systemd graphical wrapper
that I forgot how is called, busctl call, pydbus scripting.
While at least theoretically we could implement direct sending of signals
in systemctl, this would do nothing for the other approaches. And we certainly
are not going to implement direct sending of signals in those other places,
it wouldn't even be possible for the non-local transports.
Since auditd is started by systemd, you just _have_ to trust systemd.
If control over the manager is lost, the manager can just do anything
it wants, masquerading as any user. So the logging provided by recording
of the direct signal is only a "good will" effort, fairly easy to spoof
if you've actually gained some inappropriate privileges. The logging
that systemd does is effectively just as trustworthy as the audit log
as long as the system integrity is maintained.
So I think the approach with the script is good because it satisfies the
requirements, as far as they made sense when they were formulated. It could
never cover the more modern dbus-based approaches anyway.
Zbyszek
> > I wonder if another option is to have the audit code in the kernel
> > intercept systemcl messages sent to systemd and interpret the commands
> > and log what they are asking ...
>
> That's a new one. :-)
>
> I'm afraid that would require knowing which sockets are part of the dbus comm
> system and its protocol. Parsing dbus messages in the kernel is not something
> the upstream kernel maintainers will take lightly. I'd expect pushback on
> that.
8:25 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 22:17 +0000, Zbigniew Jędrzejewski-Szmek wrote:
Since auditd is started by systemd, you just _have_ to trust
systemd.
If control over the manager is lost, the manager can just do anything
it wants, masquerading as any user. So the logging provided by recording
of the direct signal is only a "good will" effort, fairly easy to spoof
if you've actually gained some inappropriate privileges. The logging
that systemd does is effectively just as trustworthy as the audit log
as long as the system integrity is maintained.
I think this is really a key point TBH.
Auditd trusts the kernel to behave correctly, and I think all problems
could be solved by also trusting systemd-init to provide correct info.
At the point auditd would simply trust the uids systemd can pull via
scm credentials or some dedicated kernel facility if more is needed and
get over the "dbus steals my knowledge" issue.
Steve,
what would it take for auditd to trust systemd's information?
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
4:20 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/6/22 13:55, Steve Grubb wrote:
On Thursday, January 6, 2022 1:02:36 PM EST Zbigniew
Jędrzejewski-Szmek
wrote:
> On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote:
>> On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>>> (Maybe a separate binary, or a small shell script, or maybe something
>>> in auditctl…. I don't know because I don't know audit.)>
It would be better if there was a systemctl solution. Any solution I
implement will be met with you need to migrate to systemctl. There have been
multiple bz opened and closed on this.
What would you need in order to be able to migrate to systemctl? Could
the dbus daemon or systemd generate the necessary audit records? Or could
auditctl handle everything itself, perhaps by talking to auditd over a
socket instead of sending a signal?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
11:27 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Hello,
On Thursday, January 6, 2022 5:20:04 PM EST Demi Marie Obenour wrote:
> It would be better if there was a systemctl solution. Any
solution I
> implement will be met with you need to migrate to systemctl. There have
> been multiple bz opened and closed on this.
What would you need in order to be able to migrate to systemctl?
That's a good question and parallels Simo's question. I did not answer this
right away to think about it.
Could the dbus daemon or systemd generate the necessary audit
records?
I don't think so. The trust boundary is the kernel. It creates all audit
records and in the case where the event originates in user space, it adds a
preamble that identifies who sent that event. The audit daemon is really a
fancy syslog. It only generates a startup, stopped logging, resumed logging,
and shutdown events. The last two are communicated via signals. Signals was
chosen because they are the most basic of communication methods and have
consequences for the receiving program. All daemons have to handle signals.
Or could auditctl handle everything itself, perhaps by talking to
auditd
over a socket instead of sending a signal?
To use a socket or dbus means more attack surface. But assuming this was
acceptable, we could identify who is at the other end in the socket scenario.
This is because the kernel can see both ends of the socket and can answer
with authority. With dbus, I don't know how trustworthy it's identification of
remote processes are. (Can answers be spoofed by a malicious app?) At one
point, a kernel dbus was being proposed. It would have allowed authoritative
answers to who I'm talking to because the answer came from the kernel.
Still thinking about it. But signals have to be handled no matter what. And
since they have to be, they seem like the natural solution.
Cheers,
-Steve
12:16 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/7/22 12:27, Steve Grubb wrote:
Hello,
On Thursday, January 6, 2022 5:20:04 PM EST Demi Marie Obenour wrote:>> Or could
auditctl handle everything itself, perhaps by talking to auditd
> over a socket instead of sending a signal?
To use a socket or dbus means more attack surface. But assuming this was
acceptable, we could identify who is at the other end in the socket scenario.
This is because the kernel can see both ends of the socket and can answer
with authority.
The (implicit) assumption is that unauthorized users are not able to connect
to the auditd control socket. That should be easy to check. auditd can even
emit a record indicating who connected to it.
With dbus, I don't know how trustworthy it's identification
of
remote processes are. (Can answers be spoofed by a malicious app?) At one
point, a kernel dbus was being proposed. It would have allowed authoritative
answers to who I'm talking to because the answer came from the kernel.
D-Bus’s identification is unspoofable. dbus-broker gets the information from
the kernel and passes it on to the dbus client. You have to trust dbus-broker
anyway, because it can cause systemd to execute arbitrary commands as any user
it desires.
Still thinking about it. But signals have to be handled no matter
what. And
since they have to be, they seem like the natural solution.
Signals absolutely do need to be handled, but they are also racy due to PID
reuse unless one uses fancy tricks with pidfds. Using a socket has other
advantages too, such as being able to know that one’s command to the daemon
was successfully processed.
It is also worth noting that systemd can signal *any* process on the system,
and can be made to do so via systemctl. systemd *must* be able to do so for
system shutdown to work properly, so there is no changing this. You have to
trust your init system.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
4:43 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
I'd say we want to get rid of both;)
There are use-cases that NetworkManager just doesn't support that network-scripts
does. If network-scripts is orphaned I'll probably pick it up.
I have raised the use cases with upstream, but they haven't had time to address
them. I suspect they won't unless I pony up patches, which I cannot commit the time.
There's nothing inherently wrong with network-scripts. They call the latest and
greatest network command tools. I'd love to switch to NetworkManager, but we're
not
there yet.
5:18 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 17:43, Michael Cronenworth wrote:
On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> I'd say we want to get rid of both;)
There are use-cases that NetworkManager just doesn't support that network-scripts
does. If network-scripts is orphaned I'll probably pick it up.
Which use-cases are these? Does systemd-networkd address them?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:21 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 6:19 PM Demi Marie Obenour <demiobenour(a)gmail.com> wrote:
On 1/5/22 17:43, Michael Cronenworth wrote:
> On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> I'd say we want to get rid of both;)
>
> There are use-cases that NetworkManager just doesn't support that
network-scripts
> does. If network-scripts is orphaned I'll probably pick it up.
Which use-cases are these? Does systemd-networkd address them?
systemd-networkd has even *less* functionality than the legacy network-scripts.
I am, however, curious what functionality exists in network-scripts
that doesn't in NetworkManager, since most of the newer networking
features were only implemented in ifcfg-rh on NetworkManager.
--
真実はいつも一つ！/ Always, there's only one truth!
7:38 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 18:21 -0500, Neal Gompa wrote:
On Wed, Jan 5, 2022 at 6:19 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 1/5/22 17:43, Michael Cronenworth wrote:
> > On 1/5/22 2:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > > I'd say we want to get rid of both;)
> >
> > There are use-cases that NetworkManager just doesn't support that
network-scripts
> > does. If network-scripts is orphaned I'll probably pick it up.
>
> Which use-cases are these? Does systemd-networkd address them?
systemd-networkd has even *less* functionality than the legacy network-scripts.
I am, however, curious what functionality exists in network-scripts
that doesn't in NetworkManager, since most of the newer networking
features were only implemented in ifcfg-rh on NetworkManager.
I already cited one upthread - openvswitch integration. And possibly
ifup-pre , I haven't found a NetworkManager equivalent to that
mechanism yet, but I might be missing it.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
9:52 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org> said:
I already cited one upthread - openvswitch integration. And possibly
ifup-pre , I haven't found a NetworkManager equivalent to that
mechanism yet, but I might be missing it.
Do you mean /sbin/ifup-pre-local? If so, is there a difference between
that and NM's dispatcher pre-up? I can't find any documentation about
the semantics of ifup-pre-local (just that it was called near the end of
the ifup script).
--
Chris Adams <linux(a)cmadams.net>
1:17 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, 2022-01-05 at 21:52 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org>
said:
> I already cited one upthread - openvswitch integration. And possibly
> ifup-pre , I haven't found a NetworkManager equivalent to that
> mechanism yet, but I might be missing it.
Do you mean /sbin/ifup-pre-local? If so, is there a difference between
that and NM's dispatcher pre-up? I can't find any documentation about
the semantics of ifup-pre-local (just that it was called near the end of
the ifup script).
Hmm, yeah, looks like that may be equivalent indeed. Not sure why I
didn't find it before. Thanks for the pointer.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
7:43 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/5/22 5:21 PM, Neal Gompa wrote:
I am, however, curious what functionality exists in network-scripts
that doesn't in NetworkManager, since most of the newer networking
features were only implemented in ifcfg-rh on NetworkManager.
One case is a reliable IPv6 RA server. The last time I tried to use it it works for
initial assignment but never renews addresses so devices fall off the network after
their address expires. [1]
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/475
7:53 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Once upon a time, Michael Cronenworth <mike(a)cchtml.com> said:
On 1/5/22 5:21 PM, Neal Gompa wrote:
>I am, however, curious what functionality exists in network-scripts
>that doesn't in NetworkManager, since most of the newer networking
>features were only implemented in ifcfg-rh on NetworkManager.
One case is a reliable IPv6 RA server. The last time I tried to use
it it works for initial assignment but never renews addresses so
devices fall off the network after their address expires. [1]
ifcfg scripts don't run an RA server. You can set signaling radvd,
which can also be done with NM dispatcher scripts (which would be much
more flexible, since it wouldn't be hard-coded to just radvd like the
ifcfg scripts).
--
Chris Adams <linux(a)cmadams.net>
8:10 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/6/22 7:53 AM, Chris Adams wrote:
ifcfg scripts don't run an RA server. You can set signaling
radvd,
which can also be done with NM dispatcher scripts (which would be much
more flexible, since it wouldn't be hard-coded to just radvd like the
ifcfg scripts).
Do you use this in real-life?
How do you get the PD address into the radvd config using NM dispatcher?
9:08 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Once upon a time, Michael Cronenworth <mike(a)cchtml.com> said:
On 1/6/22 7:53 AM, Chris Adams wrote:
>ifcfg scripts don't run an RA server. You can set signaling radvd,
>which can also be done with NM dispatcher scripts (which would be much
>more flexible, since it wouldn't be hard-coded to just radvd like the
>ifcfg scripts).
Do you use this in real-life?
How do you get the PD address into the radvd config using NM dispatcher?
No, I haven't done this (been considering it though for a project). But
if I wanted to not use NM for IPv6 PD, I just wouldn't use NM for IPv6
PD at all (not use it for part and then try to pass the info out). So
do it like the ifcfg scripts, I guess using dhclient and radvd.
But, for that matter, I have no idea how ifcfg handles it, since I can't
find any documentation about it. The only references to radvd in the
ifcfg doc are for 6to4/PPP. Which is part of the problem with the ifcfg
scripts anyway - there's a pile of undocumented functionality with
hard-coded assumptions (like, what if I want to use some other software
for IPv6 PD). At least with NM, the docs are better (IMHO), the UI is
better, and the dispatcher is flexible for many more situations.
It might be a good feature request for NM to export PD info, since it's
not listed in the NM-dispatcher man page.
--
Chris Adams <linux(a)cmadams.net>
7:07 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, 2022-01-06 at 08:10 -0600, Michael Cronenworth wrote:
On 1/6/22 7:53 AM, Chris Adams wrote:
> ifcfg scripts don't run an RA server. You can set signaling radvd,
> which can also be done with NM dispatcher scripts (which would be
> much
> more flexible, since it wouldn't be hard-coded to just radvd like
> the
> ifcfg scripts).
Do you use this in real-life?
How do you get the PD address into the radvd config using NM
dispatcher?
Don't know any way in native NM to do this, but there is a package in
Github, https://github.com/sshambar/nmutils which adds appropriate
dispatcher scripts into NM to do all this.
It doesn't handle extremely complex cases and is still needs a bit of
work to get going, but does show how you do most things within the NM
environment.
I'm using it and once I got my head around some of the configurations
it just keeps working.
Frank
2:41 a.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Thu, Jan 06, 2022 at 07:43:18AM -0600, Michael Cronenworth wrote:
On 1/5/22 5:21 PM, Neal Gompa wrote:
>I am, however, curious what functionality exists in network-scripts
>that doesn't in NetworkManager, since most of the newer networking
>features were only implemented in ifcfg-rh on NetworkManager.
One case is a reliable IPv6 RA server. The last time I tried to use it it
works for initial assignment but never renews addresses so devices fall off
the network after their address expires. [1]
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/475
Would the RA support in systemd-networkd work for your case? I don't know
much more about than that various improvements have been done recently with
renewing and propagating of the ipv6 routing info, and would be very interested
if it's enough to serve your usecase.
https://www.freedesktop.org/software/systemd/man/systemd.network.html#IPv...
https://www.freedesktop.org/software/systemd/man/systemd.network.html#IPv...
https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5B...
https://www.freedesktop.org/software/systemd/man/systemd.network.html#Exa...
Zbyszek
1:11 p.m.
New subject: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On 1/7/22 2:41 AM, Zbigniew Jędrzejewski-Szmek wrote:
Would the RA support in systemd-networkd work for your case? I
don't know
much more about than that various improvements have been done recently with
renewing and propagating of the ipv6 routing info, and would be very interested
if it's enough to serve your usecase.
https://www.freedesktop.org/software/systemd/man/systemd.network.html#IPv...
https://www.freedesktop.org/software/systemd/man/systemd.network.html#IPv...
https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5B...
https://www.freedesktop.org/software/systemd/man/systemd.network.html#Exa...
After a quick glance it looks like that would work. Thanks!
I'll try it out next time I have some downtime.
837
days inactive
840
days old
31 comments
10 participants
participants (10)
-
Adam Williamson -
Chris Adams -
Demi Marie Obenour -
Frank Crawford -
Michael Cronenworth -
Neal Gompa -
Simo Sorce -
Steve Grubb -
Xose Vazquez Perez -
Zbigniew Jędrzejewski-Szmek