On Sat, Jun 20, 2015 at 08:09:08PM +0200, Simon Maurer wrote: > Hi, > I tried to use selinux with systemd, but without much success. Looks > like the whole transitioning is broken. (Most daemons are stuck in the > init_t domain) What I don't understand is, while more and more disros > switching to systemd, it seems like there is still no working selinux > policy with systemd support. So how do other distros support selinux?
Redhat has a lot of extra stuff in their policy to make systemd work. I am not that familiar with how theirs works but it is a lot less confined than upstream will accept so things cant be upstreamed from redhat. Redhat also does not support large parts of it. Last I heard, there wasnt really support for the user parts of systemd in their policy. Systemd is extremely complex and writing a full policy is rather involved :/. Other than the redhat-based distros, there isnt really support for systemd that I know of. Debian is pretty close to upstream refpol like us which means not much support yet unfortunately since selinux is not as widely used there. The init_t problem comes because in other init systems, when init runs the init scripts it will transition to initrc_t and then initrc_t has a lot of transition to run the daemons and everything works easily. In systemd there are no init scripts, it reads and does some checks on the unit files and then runs daemons directly from init_t. There will need to be quite a lot of additions to the policy to make this work. I added an interface upstream which is fairly flexible so adding the unit handling is doable but still involved. On top of the init_t transition problem, there is the fact that there is no policy for all of the parts of systemd other than pid1 and they will also need a lot of policy development. > While I'm tying to figure this selinux thingy out, a few questions came > to mind: > Most packages with the selinux use flag are just pulling their reference > policy module as a dependency. Wouldn't it be better to use the seinux > flag only for packages which are linked against libselinux and use > instead a SELINUX_MODULES variable in the make.conf file (similar to > APACHE2_MODULES)? Having something like SELINUX_MODULES would mean that the user needs to go through all the packages they have installed and then decide which policy modules they need and set in make.conf. The way we currently have it they get pulled in automatically with no work for the user. Yes there is double-duty for both things linking to libselinux and for the policies but that hasnt really been a problem so far and I dont see why you'd want to enable one but not the other. > The tresys reference policy uses the distro_gentoo directive, but AFAIK > it only affects openrc stuff. So shouldn't it be renamed to init_openrc? The ifdef is used for a *lot* more than openrc, so changing it to init_openrc would not work. Once systemd support is in the policy we might have a boolean to choose systemd vs openrc or a useflag. We'll have to see what the additions for systemd look like before deciding that. distro_gentoo is used for anything in our policy that is not upstreamed tho, so it is far more than openrc. If you know systemd well and can write a policy for parts of it I can help in getting it upstream. I unfortunately do not know it well enough to write a policy for it. For the moment unfortunately you will have to choose between either systemd or selinux tho. Hope I managed to clear up a little. If you have other questions i'll be more than happy to help. -- Jason
