On Sat, Jan 11, 2014 at 11:34:43PM -0600, Dustin C. Hatch wrote:
> Ansible connects to the server as an unprivileged user (typically the
> user running it) over SSH and then executes all change commands via
> sudo. This works for most things, like copying files, etc., but if it
> has to restart a service after making a configuration change, it fails.
> I am not sure how to configure SELinux policy and/or sudo to get the
> user into the correct context to be able to restart arbitrary services.
> I cannot use run_init because Ansible does not know how to do so.
>
> Here's what I've tried so far:
[... user mapped to staff_u so it is granted staff_r/sysadm_r roles ...]
[... pam_rootok.so used in run_init to remove root password requirement ...]
> My understanding is that in order to be able to control services, one
> needs to have the system_r role[1]. I don't know how to get there, though:
> dustin@test-3238ec ~ $ sudo -r system_r rc-service nfsmount restart
> Password:
> sudo: unable to get default type for role system_r
> sudo: unable to execute /sbin/rc-service: Invalid argument
> dustin@test-3238ec ~ $ sudo -r system_r -t sysadm_t rc-service nfsmount
> restart
> sudo: staff_u:system_r:sysadm_t is not a valid context
> sudo: unable to execute /sbin/rc-service: Invalid argument
> dustin@test-3238ec ~ $ sudo -r system_r -t run_init_t rc-service
> nfsmount restart
> sudo: staff_u:system_r:run_init_t is not a valid context
> sudo: unable to execute /sbin/rc-service: Invalid argument
You shouldn't directly mention system_r (as role) in sudo at any point as
far as I know. Either a role is granted the right to start services directly
(which is used for the services that use what I call "named init scripts")
or the role is allowed the run_init_t domain and calls it through
run_init.
In Gentoo, OpenRC calls run_init internally so you don't need to pass it on
directly when invoked through a shell. But it does require the policy change
as you mentioned (but you don't need to add it yourself, it should already
be in the Gentoo policy).
> I tried a policy change that should allow OpenRC to make the transition
> for me[2] but it did not work:
[...]
> dustin@test-3238ec ~ $ sudo -r sysadm_r -t sysadm_t rc-service nfsmount
> restart
> Password:
> Authenticating root.
> Cannot find your entry in the shadow passwd file.
>
> I'm not sure where to go from here. Any help would be appreciated.
I'll look into it (it's reproduceable).
Seems that the trick from the blog post doesn't work for sudo. As far as I
can see, the transition to the sysadm_r role and sysadm_t domain work
nicely, and rc-service is a regular bin_t (so it's not about mismatching
transitions).
In the mean time you can use "sudo run_init rc-service nfsmount" and grant
the user the rights for it in the sudoers file. You can also directly enter
the ROLE= and TYPE= parameters in the sudoers file so that you don't need to
pass it on directly.
Wkr,
Sven Vermeulen
