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

[Michael Scherer]

Le jeudi 02 janvier 2014 à 11:30 -0500, Daniel J Walsh a écrit :
> On 12/28/2013 11:47 AM, Michael Scherer wrote:
> > 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.
> > 
> 
> I like this patch, and I have seen people saying we have this capability in
> RHEL7  :^(
> 
> Currently people in a sysvinit scripts are using runcon for similar features.
>  And as someone described handling of java, mono, erlang type scripts where
> the command is not easy to differentiate.
> 
> We also allow people to do something similar with sudo.  ROLE=unconfined_r
> TYPE=unconfined_t.
> 
> I would prefer if app writers do not start hard coding SELinux contexts into
> the unit files, but allowing administrators or third parties like openshift to
> override I do not have a problem with it.
> 
> It could allow a administrator to say run this script as unconfined_t, which
> may or may not cause other problems.
> 
> We might want to allow more granularity on this then just context.    Since we
> allow sudo to specify role and type and we allow runcon to specify all fields
> of SELinux.

IE, you would like to have something like SELinuxRole, SELinuxType,
SELinuxRange and SELinuxUser, each permitting to override 1 single field
of the context ?

It shouldn't be that hard to do ( a bit longer to properly test maybe ),
I am however not sure if we should keep the 2 styles of configuration
For example, in what order would the different field be applied, if I
set SELinuxuser and the context etc.

And if we use 4 configurations directives instead of 1, it also make the
request for a default SELinux context asked by David a bit harder and a
bit less elegant ( since that would mean 4 directive for the settings, 1
directive for disabling, and 4 directive for each default of the field,
unless we only offer default context ).

I will try to cook a new version of the patch with 4 splitted fields for
next week while we discuss the proposal
-- 
Michael Scherer