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