Hello, On Thursday, January 6, 2022 5:20:04 PM EST Demi Marie Obenour wrote: > > 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. > > What would you need in order to be able to migrate to systemctl? That's a good question and parallels Simo's question. I did not answer this right away to think about it. > Could the dbus daemon or systemd generate the necessary audit records? I don't think so. The trust boundary is the kernel. It creates all audit records and in the case where the event originates in user space, it adds a preamble that identifies who sent that event. The audit daemon is really a fancy syslog. It only generates a startup, stopped logging, resumed logging, and shutdown events. The last two are communicated via signals. Signals was chosen because they are the most basic of communication methods and have consequences for the receiving program. All daemons have to handle signals. > 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. 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. 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. 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
