On 1/7/22 12:27, Steve Grubb wrote: > Hello, > > On Thursday, January 6, 2022 5:20:04 PM EST Demi Marie Obenour wrote:>> Or could auditctl handle everything itself, perhaps by talking to auditd >> over a socket instead of sending a signal? > > To use a socket or dbus means more attack surface. But assuming this was > acceptable, we could identify who is at the other end in the socket scenario. > This is because the kernel can see both ends of the socket and can answer > with authority. The (implicit) assumption is that unauthorized users are not able to connect to the auditd control socket. That should be easy to check. auditd can even emit a record indicating who connected to it. > With dbus, I don't know how trustworthy it's identification of > remote processes are. (Can answers be spoofed by a malicious app?) At one > point, a kernel dbus was being proposed. It would have allowed authoritative > answers to who I'm talking to because the answer came from the kernel. D-Bus’s identification is unspoofable. dbus-broker gets the information from the kernel and passes it on to the dbus client. You have to trust dbus-broker anyway, because it can cause systemd to execute arbitrary commands as any user it desires. > Still thinking about it. But signals have to be handled no matter what. And > since they have to be, they seem like the natural solution. Signals absolutely do need to be handled, but they are also racy due to PID reuse unless one uses fancy tricks with pidfds. Using a socket has other advantages too, such as being able to know that one’s command to the daemon was successfully processed. It is also worth noting that systemd can signal *any* process on the system, and can be made to do so via systemctl. systemd *must* be able to do so for system shutdown to work properly, so there is no changing this. You have to trust your init system. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
