[systemd-devel] [PATCH] Add SELinuxContext configuration item

[Michael Scherer]

Le samedi 28 décembre 2013 à 14:30 +0100, Lennart Poettering a écrit :
> On Fri, 27.12.13 23:26, misc at zarb.org (misc at zarb.org) wrote:
> 
> > From: Michael Scherer <misc at zarb.org>
> > 
> > This permit to let system administrators decide of the domain of a service.
> > This can be used with templated units to have each service in a différent
> > domain ( for example, a per customer database, using MLS or anything ),
> > or can be used to force a non selinux enabled system (jvm, erlang, etc)
> > to start in a different domain for each service.
> 
> Hmm, so far (as I understood it) the SELinux guys always wanted to make
> sure that label configuration stays in the the selinux database and
> nowhere else.

Yep, I know and they are right, we shouldn't put configuration
everywhere in the system. But there is a few cases where the selinux
policy cannot express what we want ( or at least, I do not know how to
do it ).

First case is doing something like openshift, with 1 different domain
per user. Since the transitions are mostly handled in kernel space
( except for specific case like sepostgresql ), it kinda restrict what
we can do in term of "smart" transition. In the case of openshift, this
use a specific pam module (pam_openshift) and specific plugins in the
code, because the policy is a bit too static to handle that.

So using templated units, we could do for example :
SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023

or similar tricks.
Or just handle things manually, with static SELinuxContext ( or include,
or anything ).


The second case is caused by a limitation of the current way of doing
transition. My main motivation is to solve
https://bugzilla.redhat.com/show_bug.cgi?id=969757 , because right now,
we cannot ask to erlang to run in a different domain unless if we write
1 shell wrapper per erlang application just to trigger the transition,
or until we make erlang selinux-aware, like postgresql is. 
So rather than duplicate shell wrappers or adding code everywhere, I was
thinking doing it in systemd directly would be beneficial for everybody
by reducing needed changes to the only stuff that matter, having the
context we want to switch to.

I do not expect SELinuxContext to be used by upstream units, and I guess
that a distribution can decide to have them being unused by policy if
that's a issue.

It should also be noted that upstart do support a similar configuration
for apparmor,
https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/+merge/164169
And I was pondering on adding it as well to systemd, since some systemd
consumers are using apparmor, and because feature parity is IMHO
important if we want to let people use systemd on Ubuntu.


> I'd like Dan Walsh's opinion whether this addition fits into what the
> SELinux guys want or not. Dan?
> 
> Patch looks fine though.

-- 
Michael Scherer