RHEL 6 Confined Users Running Third-Party Services

Miroslav Grepl mgrepl at redhat.com
Thu Sep 10 11:26:04 UTC 2015


On 09/10/2015 03:24 AM, Douglas Brown wrote:
> Hi all,
> 
> In a PaaS environment where service administrators are confined using RBACs on RHEL 6, how should third-party services be supported at scale?
> 
> Allowing a confined user to execute any arbitrary executable that transitions to system_r:unconfined_t would make breaking out of the user’s confinement trivial. In this way, executenotrans seems to be the best approach (assuming the service administrator role isn’t too restrictive), but on boot the default inirc_exec_t service script label would cause the service to run in the unconfined initrc_t domain, whereas if the service was started by the user it would be in the service administrator’s domain, leading to inconsistent application of policy.
> 
> The init_labeled_script_domtrans macro could be used to allow the service administrator role to use initrc_exec_t labelled service scripts, but that would allow service administrators to start/stop a number of managed system services. Furthermore, if the user started their service manually (ie. not via the service script), it too would lead to the same inconsistent application of policy as noted above.
> 
> These issues are resolved in RHEL 7 with the use of systemd?
> 
> Your thoughts would be much appreciated.
> 
> Thanks,
> Doug
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 

If I understand correctly, you are looking for run_init on RHEL-6.

# service abrtd start

vs.

# run_init service abrtd start

In the second case, abrtd service will run in the proper SELinux context.

If you run a service directly, you will end up with a user context which
is expected. Services should be started using service scripts. Otherwise
you would need to have proper transitions for your SELinux users.

-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.


More information about the selinux mailing list