[systemd-devel] auditd.service and RefuseManualStop

[Steve Grubb]

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.

Thanks,
-Steve