Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2014 12:35 PM, Michael Scherer wrote:
Le vendredi 03 janvier 2014 à 11:48 -0500, Daniel J Walsh a écrit :
On 01/03/2014 09:16 AM, Michael Scherer wrote:
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.
I fail to follow you. The current code use setexecon, and this is quite
selinux specific. What would be the equivalent for apparmor, for smack and
others ?
No idea, I only do SELinux...
But as Kay Pointed out, there is some similar code in udev for this.
Udev uses: SECLABEL{selinux}=foo SECLABEL{smack}=bar
I think we should be able to distinguish the LSM-module-specific label type
somehow in the key or value.
Kay
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLKsRYACgkQrlYvE4MpobOZaACfZTo4JI3dYFhZ9bXKTVkQrQy0
nB4AoLS6FYmmiasReuREK+oedjWn/jI5
=K5oJ
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
Le vendredi 03 janvier 2014 à 00:58 +, 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 Schererm...@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. 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. 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. Usually, the type of transition from 1 domain to another is done at the kernel level based on the label of the file executed. See https://wiki.gentoo.org/wiki/SELinux/Tutorials/How_does_a_process_get_into_a_certain_context and http://danwalsh.livejournal.com/23944.html 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, I am ready to hear of it, but the only alternative I see is to make the JVM, erlang, etc, to be SELinux aware. That's a much bigger task, and I am not sure that's worth the code duplication ( not to mention that it make sysadmin look in several different places ). And the design I was thinking of ( ie, replicated the current system of doing transition based on file label ) would requires reimplementing the kernel code in userspace, in libselinux, and I would rather avoid this for various reasons ( security, code duplication avoidance ). Another solution would be to create shell wrapper for every java, erlang and mono software, and then use process transition on the shell wrapper, but that doesn't scale that well and do not offer the flexibility of the current patch to the sysadmin. ( and would likely be Fedora specific as well ). -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On 01/03/2014 10:56 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 00:58 +, 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 Schererm...@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
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
Le vendredi 03 janvier 2014 à 12:23 +, Jóhann B. Guðmundsson a écrit : On 01/03/2014 10:56 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 00:58 +, 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 Schererm...@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
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2014 09:16 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 12:23 +, Jóhann B. Guðmundsson a écrit : On 01/03/2014 10:56 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 00:58 +, 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 Schererm...@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
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Fri, Jan 03, 2014 at 11:48:49AM -0500, Daniel J Walsh wrote: 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. I think the usual style of - as the first character of RHS meaning that the setting can be ignored should be used. In general, if selinux=0 is used, or selinux support is not compiled in, those options should not result in failure. So the algorithm should be: if disabled, ignore, if enabled, and impossible to apply, fail, unless - was prefixed. 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. Yes, this sounds nicer: easier to document, to configure, etc. 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. This would make it impossible to use the same unit file with more than one security framework. This might be desirable, even if they cannot be enabled at the same time. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
Le vendredi 03 janvier 2014 à 18:21 +0100, Zbigniew Jędrzejewski-Szmek a écrit : On Fri, Jan 03, 2014 at 11:48:49AM -0500, Daniel J Walsh wrote: 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. I think the usual style of - as the first character of RHS meaning that the setting can be ignored should be used. In general, if selinux=0 is used, or selinux support is not compiled in, those options should not result in failure. So the algorithm should be: if disabled, ignore, if enabled, and impossible to apply, fail, unless - was prefixed. Good idea, i have coded that, I will test and send it later. -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Fri, Jan 3, 2014 at 6:21 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
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.
This would make it impossible to use the same unit file with more than
one security framework. This might be desirable, even if they cannot be
enabled
at the same time.
Udev uses:
SECLABEL{selinux}=foo
SECLABEL{smack}=bar
I think we should be able to distinguish the LSM-module-specific label
type somehow in the key or value.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/28/2013 11:47 AM, Michael Scherer wrote: 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. I like this patch, and I have seen people saying we have this capability in RHEL7 :^( Currently people in a sysvinit scripts are using runcon for similar features. And as someone described handling of java, mono, erlang type scripts where the command is not easy to differentiate. We also allow people to do something similar with sudo. ROLE=unconfined_r TYPE=unconfined_t. I would prefer if app writers do not start hard coding SELinux contexts into the unit files, but allowing administrators or third parties like openshift to override I do not have a problem with it. It could allow a administrator to say run this script as unconfined_t, which may or may not cause other problems. We might want to allow more granularity on this then just context.Since we allow sudo to specify role and type and we allow runcon to specify all fields of SELinux. BTW Use dwa...@redhat.com for my email, not my private (Not so private) home email. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLFlCoACgkQrlYvE4MpobMVZgCghr6UOCybitcKKqV5HKISjKDc EhoAn36vppR/4zrjhBeyypzlWqawDxdn =3jEw -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
Le jeudi 02 janvier 2014 à 11:30 -0500, Daniel J Walsh a écrit : On 12/28/2013 11:47 AM, Michael Scherer wrote: 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. I like this patch, and I have seen people saying we have this capability in RHEL7 :^( Currently people in a sysvinit scripts are using runcon for similar features. And as someone described handling of java, mono, erlang type scripts where the command is not easy to differentiate. We also allow people to do something similar with sudo. ROLE=unconfined_r TYPE=unconfined_t. I would prefer if app writers do not start hard coding SELinux contexts into the unit files, but allowing administrators or third parties like openshift to override I do not have a problem with it. It could allow a administrator to say run this script as unconfined_t, which may or may not cause other problems. We might want to allow more granularity on this then just context.Since we allow sudo to specify role and type and we allow runcon to specify all fields of SELinux. IE, you would like to have something like SELinuxRole, SELinuxType, SELinuxRange and SELinuxUser, each permitting to override 1 single field of the context ? It shouldn't be that hard to do ( a bit longer to properly test maybe ), I am however not sure if we should keep the 2 styles of configuration For example, in what order would the different field be applied, if I set SELinuxuser and the context etc. And if we use 4 configurations directives instead of 1, it also make the request for a default SELinux context asked by David a bit harder and a bit less elegant ( since that would mean 4 directive for the settings, 1 directive for disabling, and 4 directive for each default of the field, unless we only offer default context ). I will try to cook a new version of the patch with 4 splitted fields for next week while we discuss the proposal -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
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 Schererm...@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 ). 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? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
Le lundi 30 décembre 2013 à 03:14 -0600, David Timothy Strauss a écrit : On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer m...@zarb.org wrote: So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 In the spirit of making isolation easy, it would be neat to have a built-in convention for selinux isolation in systemd where the full service/unit name has a default context name, constructed much like the quoted example, that the admin or packager can use simply by turning isolation on (SELinux=true). We would love to use SELinuxContext= or SELinux= for our needs at Pantheon. Using SELinux=true is a bit weird when it come to the naming, because SELinux=false wouldn't disable selinux, it would just let the current policy do the transition, that's a bit misleading. I am not sure of the value of having 2 configuration file doing the same thing. What about SELinuxContext=auto , and so replace auto by some default configuration in that case ? -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Tue, Dec 31, 2013 at 3:33 AM, Michael Scherer m...@zarb.org wrote: I am not sure of the value of having 2 configuration file doing the same thing. What about SELinuxContext=auto , and so replace auto by some default configuration in that case ? That works for me. I just like the idea of naming that corresponds to the unit's name. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer m...@zarb.org wrote: So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 In the spirit of making isolation easy, it would be neat to have a built-in convention for selinux isolation in systemd where the full service/unit name has a default context name, constructed much like the quoted example, that the admin or packager can use simply by turning isolation on (SELinux=true). We would love to use SELinuxContext= or SELinux= for our needs at Pantheon. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
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. I'd like Dan Walsh's opinion whether this addition fits into what the SELinux guys want or not. Dan? Patch looks fine though. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Sat, Dec 28, 2013 at 2:30 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 27.12.13 23:26, m...@zarb.org (m...@zarb.org) wrote:
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.
I'd like Dan Walsh's opinion whether this addition fits into what the
SELinux guys want or not. Dan?
I guess it matches a bit what we do for udev with SECLABEL{selinux}=.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
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
[systemd-devel] [PATCH] Add SELinuxContext configuration item
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.
---
man/systemd.exec.xml | 11 +++
src/core/dbus-execute.c | 1 +
src/core/execute.c| 27 +++
src/core/execute.h| 2 ++
src/core/load-fragment-gperf.gperf.m4 | 3 ++-
src/shared/exit-status.c | 3 +++
src/shared/exit-status.h | 3 ++-
7 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 17748d4..d93de4c 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -931,6 +931,17 @@
/varlistentry
varlistentry
+termvarnameSELinuxContext=/varname/term
+
+listitemparaSet the SELinux context of the
+executed process. If set, this will override
the
+automated domain transition. However, the
policy
+still need to autorize the transition. See
+
citerefentryrefentrytitlesetexeccon/refentrytitlemanvolnum3/manvolnum/citerefentry
+for details./para/listitem
+/varlistentry
+
+varlistentry
termvarnameIgnoreSIGPIPE=/varname/term
listitemparaTakes a boolean
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index b79a456..d1b7c58 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -422,6 +422,7 @@ const sd_bus_vtable bus_exec_vtable[] = {
SD_BUS_PROPERTY(PrivateNetwork, b, bus_property_get_bool,
offsetof(ExecContext, private_network), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SameProcessGroup, b, bus_property_get_bool,
offsetof(ExecContext, same_pgrp), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(UtmpIdentifier, s, NULL, offsetof(ExecContext,
utmp_id), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(SELinuxContext, s, NULL, offsetof(ExecContext,
selinux_context), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(IgnoreSIGPIPE, b, bus_property_get_bool,
offsetof(ExecContext, ignore_sigpipe), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(NoNewPrivileges, b, bus_property_get_bool,
offsetof(ExecContext, no_new_privileges), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SystemCallFilter, au, property_get_syscall_filter,
0, SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/execute.c b/src/core/execute.c
index 6ae9a5e..2a6ceb4 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -47,6 +47,10 @@
#include security/pam_appl.h
#endif
+#ifdef HAVE_SELINUX
+#include selinux/selinux.h
+#endif
+
#include execute.h
#include strv.h
#include macro.h
@@ -1570,6 +1574,20 @@ int exec_spawn(ExecCommand *command,
goto fail_child;
}
}
+#ifdef HAVE_SELINUX
+if (context-selinux_context) {
+err =
security_check_context(context-selinux_context);
+if (err 0) {
+r = EXIT_SELINUX_CONTEXT;
+goto fail_child;
+}
+err = setexeccon(context-selinux_context);
+if (err 0) {
+r = EXIT_SELINUX_CONTEXT;
+goto fail_child;
+}
+}
+#endif
}
err = build_environment(context, n_fds, watchdog_usec, home,
username, shell, our_env);
@@ -1728,6 +1746,9 @@ void exec_context_done(ExecContext *c) {
free(c-utmp_id);
c-utmp_id = NULL;
+free(c-selinux_context);
+c-selinux_context = NULL;
+
free(c-syscall_filter);
c-syscall_filter = NULL;
}
@@ -2096,6 +2117,12 @@ void exec_context_dump(ExecContext *c, FILE* f, const
char *prefix) {
fprintf(f,
%sUtmpIdentifier: %s\n,
prefix, c-utmp_id);
+
+if (c-selinux_context)
+fprintf(f,
+%sSELinuxContext: %s\n,
+prefix, c-selinux_context);
+
}
void exec_status_start(ExecStatus *s, pid_t pid) {
diff --git a/src/core/execute.h b/src/core/execute.h
