Previous Entry Share Next Entry
What is this new unconfined_service_t type I see on Fedora 21 and RHEL7?
Everyone that has ever used SELinux knows that the unconfined_t domain is a process label that is not confined.  But this is not the only unconfined domain on a SELinux system.  It is actually the default domain of a user that logs onto a system.  In a lot of ways we should have used the type unconfined_user_t rather then unconfined_t.

By default in an SELinux Targeted system there are lots of other unconfined domains.  We have these so that users can run programs/services without SELinux interfering if SELinux does not know about them. You can list the unconfined domains on your system using the following command.

seinfo -aunconfined_domain_type -x

In RHEL6 and older versions of Fedora, we used to run system services as initrc_t by default.  Unless someone has written a policy for them.  initrc_t is an unconfined domain by default, unless you disabled the unconfined.pp module. Running unknown serivices as initrc_t allows administrators to run an application service, even if no policy has never been written for it.

In RHEL6 we have these rules:

init_t @initrc_exec_t -> initrc_t
init_t @bin_t -> initrc_t

If an administrator added an executable service to /usr/sbin or /usr/bin, the init system would run the service as initrc_t.

We found this to be problematic, though. 

The problem was that we have lots of transition rules out of initrc_t.  If a program we did not know about was running as initrc_t and executed a program like rsync to copy data between servers, SELinux would transition the program to rsync_t and it would blow up.  SELinux mistakenly would think that rsync was set up in server mode, not client mode.  Other transition rules could also cause breakage. 

We decided we needed a new unconfined domain to run services with, that would have no transition rules.  We introduced the unconfined_service_t domain.  Now we have:

init_t @bin_t -> unconfined_service_t

A process running as unconfined_service_t is allowed to execute any confined program, but stays in the unconfined_service_t domain.  SELinux will not block any access. This means by default, if you install a service that does not have policy written for it, it should work without SELinux getting in the way.

Sometimes applications are installed in fairly random directories under /usr or /opt (Or in oracle's case /u01), which end up with the label of usr_t, therefore we added these transition rules to policy.

# sesearch -T -s init_t  | grep unconfined_service_t
type_transition init_t bin_t : process unconfined_service_t;
type_transition init_t usr_t : process unconfined_service_t;
You can see it in Fedora21.

Bottom Line

Hopefully unconfined_service_t will make leaving SELinux enabled easier on systems that have to run third party services, and protect the other services that run on your system.

Thanks to Simon Sekidde and Miroslav Grepl for helping to write this blog.

  • 1

systemd scripts which fork a daemon

I have a daemon exampled. The binary file is /path/exampled.

It's complex to start up and requires a script with different things. Script is /usr/sbin/example. The script calls another program which sets up ttys and pipes etc and eventually forks the binary.

I have a exampled.service unit file. It starts the script to start the daemon.

I want my binary to run in domain example_t.

My binary is type example_exec_t

Under sysv my daemon would transition properly to example_t, but after creating a new systemd unit file for it, it now just runs as unconfined_service_t. Nasty.

If I assign my script example_exec_t, then it transitions ok but this requires opening up the selinux perms too much as the scripts do lots of work to start the daemon up and when running the daemon doesn't need all those perms.

I'm thinking I just need a new transition rule to transition from unconfined_service_t to example_t, but haven't really seen other examples of this. Is this the correct approach?

Was also thinking of an intermediate example_helper_t for the start up scripts and the transition again but that seems like a lot of work for nothing to create that new domain type and open it up? The important thing I guess is to confine the actual daemon rather than the startup environment.

Interested in your thoughts. Thanks!

Re: systemd scripts which fork a daemon

If you label your script initrc_exec_t does everything work the way you want?

  • 1

Log in

No account? Create an account