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