Gentoo Archives: gentoo-hardened

From: Jason Zaman <perfinion@g.o>
To: gentoo-hardened@l.g.o, Simon Maurer <gentroid@××××××××××××.ch>
Subject: Re: [gentoo-hardened] systemd + selinux
Date: Sat, 20 Jun 2015 19:14:56
Message-Id: 20150620191446.GA11049@meriadoc.Home
In Reply to: [gentoo-hardened] systemd + selinux by Simon Maurer
1 On Sat, Jun 20, 2015 at 08:09:08PM +0200, Simon Maurer wrote:
2 > Hi,
3 > I tried to use selinux with systemd, but without much success. Looks
4 > like the whole transitioning is broken. (Most daemons are stuck in the
5 > init_t domain) What I don't understand is, while more and more disros
6 > switching to systemd, it seems like there is still no working selinux
7 > policy with systemd support. So how do other distros support selinux?
8
9 Redhat has a lot of extra stuff in their policy to make systemd work. I
10 am not that familiar with how theirs works but it is a lot less confined
11 than upstream will accept so things cant be upstreamed from redhat.
12 Redhat also does not support large parts of it. Last I heard, there
13 wasnt really support for the user parts of systemd in their policy.
14 Systemd is extremely complex and writing a full policy is rather
15 involved :/.
16
17 Other than the redhat-based distros, there isnt really support for
18 systemd that I know of. Debian is pretty close to upstream refpol like
19 us which means not much support yet unfortunately since selinux is not
20 as widely used there.
21
22 The init_t problem comes because in other init systems, when init runs
23 the init scripts it will transition to initrc_t and then initrc_t has a
24 lot of transition to run the daemons and everything works easily. In
25 systemd there are no init scripts, it reads and does some checks on the
26 unit files and then runs daemons directly from init_t. There will need to
27 be quite a lot of additions to the policy to make this work. I added an
28 interface upstream which is fairly flexible so adding the unit handling
29 is doable but still involved.
30
31 On top of the init_t transition problem, there is the fact that there is
32 no policy for all of the parts of systemd other than pid1 and they will
33 also need a lot of policy development.
34
35 > While I'm tying to figure this selinux thingy out, a few questions came
36 > to mind:
37 > Most packages with the selinux use flag are just pulling their reference
38 > policy module as a dependency. Wouldn't it be better to use the seinux
39 > flag only for packages which are linked against libselinux and use
40 > instead a SELINUX_MODULES variable in the make.conf file (similar to
41 > APACHE2_MODULES)?
42
43 Having something like SELINUX_MODULES would mean that the user needs to
44 go through all the packages they have installed and then decide which
45 policy modules they need and set in make.conf. The way we currently have
46 it they get pulled in automatically with no work for the user. Yes there
47 is double-duty for both things linking to libselinux and for the
48 policies but that hasnt really been a problem so far and I dont see why
49 you'd want to enable one but not the other.
50
51 > The tresys reference policy uses the distro_gentoo directive, but AFAIK
52 > it only affects openrc stuff. So shouldn't it be renamed to init_openrc?
53
54 The ifdef is used for a *lot* more than openrc, so changing it to
55 init_openrc would not work. Once systemd support is in the policy we
56 might have a boolean to choose systemd vs openrc or a useflag. We'll
57 have to see what the additions for systemd look like before deciding
58 that. distro_gentoo is used for anything in our policy that is not
59 upstreamed tho, so it is far more than openrc.
60
61 If you know systemd well and can write a policy for parts of it I can
62 help in getting it upstream. I unfortunately do not know it well enough
63 to write a policy for it. For the moment unfortunately you will have to
64 choose between either systemd or selinux tho.
65
66 Hope I managed to clear up a little. If you have other questions i'll
67 be more than happy to help.
68
69 -- Jason