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

[Michael Scherer]

Le vendredi 03 janvier 2014 à 12:23 +0000, "Jóhann B. Guðmundsson" a
écrit :
> On 01/03/2014 10:56 AM, Michael Scherer wrote:
> > Le vendredi 03 janvier 2014 à 00:58 +0000, "Jóhann B. Guðmundsson" a
> > écrit :
> >> On 12/28/2013 01:30 PM, Lennart Poettering wrote:
> >>> 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.
> >> Right and if you add this you need to add something for the other
> >> security solutions as well ( apparmor etc ).
> > I do not see why we need to equally support all MAC frameworks for each
> > change we do.
> 
> Because people will start to expect being able to configure that there.

So they can as well start to fill bug report and start to contribute
code for this.

We didn't added detection of all security framework for
ConditionSecurity at the first patch, it was added later as people
expressed interest ( hence the lack of tomoyo ), so I expect the same to
be done for security frameworks. Also, having done my homework, IMA do
not have the concept of domain, apparmor has profiles, and I have no
idea for smack, so I prefer to defer integration to people who know,
based on their use cases.

> >   And while I am familiar enough with apparmor to create a
> > equivalent setting ( and plan to do ), I have no idea on how to
> > translate the concept for smack, ima and tomoyo.
> >
> > In fact, the mere fact that tomoyo is not handled at all already show
> > that we do treat all security framework as equal.
> 
> How do you suppose we deal with man pages if selinux is not installed 
> but still refer to this.

In the same way we do for all #ifdef feature. For example, for PAMName,
the documentation is always present. 

> Wont users also need to check if selinux is enabled or not in the unit 
> file?

I would rather do it in the C code, no need to have everybody asking for
it.

> Should systemd warn users if selinux is not installed,enabled and fail or?

It all depend. Either we are consistent with the other settings ( ie,
setting a syscall filter will fail if not supported on the kernel ), and
so fail, or we decide that selinux is special and we should silently
ignore failure if it cannot be applied.

I choose the first one for the first patch, but adding a conditional
would be trivial if we decide to silently ignore if the setting cannot
be applied. 

The main issue being of course that people who disable selinux do not
always properly disable it ( ie using permissive rather than selinux=0
).


 
> >
> >> This introduces yet another place for administrators to look at while
> >> debugging problems so the question to ask here is.
> >>
> >> Is adding this ability to unit files the right way to solve what's
> >> trying to be solved here?
> > As Dan said, yes.
> 
> "I would prefer if app writers do not start hard coding SELinux contexts 
> into the unit file"
> 
> I hardly call that solid yes and this is what will start taking place if 
> this is introduced into the unit files.

Then what about :
"I like this patch, and I have seen people saying we have this
capability in RHEL7  :^("

We should separate the concern about "people in distribution/upstream
using it if offered" and the rest of the world. Distribution policy is a
matter of the distribution. If Fedora wish to forbid this unless there
is a good use case, that's up to Fedora to do it, and to have it
integrated into rpmlint or anything.

I must also say that I didn't really see a rush from application
developers to add selinux support or anything, and that people can
already distribute policy along their application, with all support
problem this could create for distributions. So we already have the
problem, adding the setting in systemd wouldn't change much. 

> >
> > However, as said, there is some case where the approach of making the
> > transition based on the executed filename is not sufficient. For
> > example, the erlang vm, the jvm, etc, because each software will run in
> > the same domain, in different processes, because that's always the same
> > jvm being used. See the bug I mentioned before.
> >
> > Now, if you have a more precise feedback and/or a better proposal,
> 
> Add this to the daemon startup itself ( the confile or the code ) and or 
> use runcon in an exec start pre section to set this up.

Runcon cannot be used in ExecStartPre, that's like "su". So you have to
run it in ExecStart, and this make things harder for sysadmins, and
doesn't look like in line with systemd philosophy since that's replacing
configuration by code. 

On the integration point of view, that mean that anyone wanting to use
this on a unit provided by a vendor have to duplicate the command line
in a custom unit and/or using dropin configuration, and add runcon
( along proper quoting ). This also mean that a tool to read/write unit
files would have to understand the command line of runcon if they want
to provides a higher level overview, or just not understand it.

So using runcon is just a workaround, and forking 1 process just to run
2 selinux functions ( as done by the patch ) seems like a waste to me.
It would also mean that we need to have runcon in a chroot/container if
we decide to go this way, unlike the approach of doing it with system
who doesn't need it.


> In anycase Lennart decides this to me this seems like a workaround being 
> put in systemd for a limitation in selinux or the concept there of with 
> the added complexity for administrators.

yes, that's put in systemd because placing this in every other possible
place would be duplication. As i said, we could add this to jvm, to
erlang, etc, but it would scale ( ie, we would have more place to look
for configuration )
-- 
Michael Scherer