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,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.
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.
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.
Wont users also need to check if selinux is enabled or not in the unit
file?
Should systemd warn users if selinux is not installed,enabled and fail or?
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.
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.
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.
JBG
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
