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. -- Michael Scherer _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel