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, m...@zarb.org (m...@zarb.org) wrote: > >> > >>> From: Michael Scherer <m...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
