-----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,[email protected] ([email protected]) wrote: >>>>> >>>>>>> From: Michael Scherer<[email protected]> >>>>>>> >>>>>>> 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLG6fEACgkQrlYvE4MpobNgkACgotbJeCzZcZ4mJ3D5G11NtEoY 3UQAniChzbarSjvf6pmhdNl+2rWLnuZc =gvT5 -----END PGP SIGNATURE----- _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
