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 |