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