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

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

BTW Use dwalsh at redhat.com for my email, not my private (Not so private) home
email.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLFlCoACgkQrlYvE4MpobMVZgCghr6UOCybitcKKqV5HKISjKDc
EhoAn36vppR/4zrjhBeyypzlWqawDxdn
=3jEw
-----END PGP SIGNATURE-----