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 _______________________________________________ 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