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