[systemd-devel] auditd.service and RefuseManualStop

[Lennart Poettering]

On Fri, 11.04.14 10:29, Steve Grubb (sgrubb at redhat.com) wrote:

> 
> On Friday, April 11, 2014 03:14:31 AM Lennart Poettering wrote:
> > On Thu, 03.04.14 18:00, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> > > Alternatively we can do "systemctl kill" in this case prior to uninstall
> > > and that will work (systemctl kill does not respect RefuseManualStop).
> > 
> > Yeah, this is probably what I'd do.
> > 
> > > Anyway, just wanted to discuss the best approach here. Perhaps the
> > > upstream unit could be tweaked? Perhaps RefuseManualStop is overkill?
> > 
> > We added RefuseManualStop= justfor this. Don't remember the details
> > though, why this is a good thing though... Sounds like tpyicial audit
> > security theatre to me in retrospect...
> > 
> > Steve, what's the precise reason auditd.service makes use of
> > RefuseManualStop=?
> 
> The reason is because we have to record who issued the shutdown request. The 
> way that it worked prior to systemd is to use the service command which runs 
> in the user's context. The user is identified by a field, auid, in the task 
> struct in the kernel. They also have selinux subject lable on the process. 
> When a signal is sent to the audit daemon, the kernel looks at the sending 
> process and grabs the auid and selinux subject label from its task struct and 
> saves it for the audit daemon to retrieve.
> 
> When systemctl is used, systemd sends the term signal and the auid for systemd 
> is -1 (meaning unset) which is normal and expected for a daemon. It also has 
> the initrc_t subject label which is also normal for init, but clearly not the 
> user. So, we really can't tell who issued the shutdown command. The "fix" is 
> not allow the dbus path so that the shutdown occurs in the users context so 
> the auid & selinux subject label are available.
> 
> If you can think of a change to the spec file get the restart to occur in the 
> user's context so that a yum update by an admin records the admin's auid & 
> subject label, then I'd be happy to make the change.

This is really not convincing. If you want the full audit trail for stop
requests for auditd, then it would be wise to fix the kernel to do
SCM_AUDIT or something like that, so that systemd can generate an audit
record containing the client's audit identity when executing it. I mean,
let's not forget that REfuseManualStep= is snake oil here, since it will
only block explicit auditd shutdowns, but not implicit onces that are
executed due to a dependency on something else. This idea of not
allowing a service to stop, because the audit system is so fucked up
that it cannot generate a good record on stop is just so broken...

I really wonder what I thought when I added RefuseManualStop=. I have
trouble coming up with the valid usecase for this that I must have seen
back then.... I have the suspicion though that it was totally unrelated
to auditd, and that it was mostly about userspace daemons whose death
can cause the system to come to a standstill (for example storage
daemons backing the root fs, or so), and where we wanted to protect the
user from accidental mistakes.

Lennart

-- 
Lennart Poettering, Red Hat