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

Fri Jan 3 08:48:49 PST 2014

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

On 01/03/2014 09:16 AM, Michael Scherer wrote:
> 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 )
> 
Well thinking about this again, I think still to the single label.  Lets not
break the field up into multiple labels.

And not make it SELinux specific.  Maybe the field could be SecurityLabel:

That would allow smack to also use the field and any other LSM that used a
labeling system.