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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
