* MCS and default labels @ 2009-09-08 5:58 Michal Svoboda 2009-09-08 15:35 ` Stephen Smalley 0 siblings, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-08 5:58 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 1064 bytes --] Hello, I have implemented a simple MCS based system for hosting SVN repositories. I was happy with the performance until I found out that the s0-s0:c1 processes will happily create new revisions (ie. new files) as s0 inside a s0:c1 directory. According to various sources, new files are always created using the lowest security level in the range of the creating process, despite an inheritance mechanism already working for types. What is the reasoning behind this? I tried to mitigate this by forcing a ssh session into a certain MCS range, as in ssh user/foo_r:foo_t:s0:c1, however this only works for changing roles but not for MCS. Not even setting the MCS level in default_contexts works as one would expect. Again, why? Running out of ideas, my solution for now is to hope that a s0 process cannot search / modify the s0:c1 directory, even with s0 files present and to periodically "restorecon" the whole dir (no, restorecond does not seem to be working on dirs recursively). So the third question is, are there any better ways? Regards, Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-08 5:58 MCS and default labels Michal Svoboda @ 2009-09-08 15:35 ` Stephen Smalley 2009-09-08 16:36 ` Michal Svoboda 0 siblings, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2009-09-08 15:35 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Tue, 2009-09-08 at 07:58 +0200, Michal Svoboda wrote: > Hello, > > I have implemented a simple MCS based system for hosting SVN > repositories. I was happy with the performance until I found out that > the s0-s0:c1 processes will happily create new revisions (ie. new files) > as s0 inside a s0:c1 directory. According to various sources, new files > are always created using the lowest security level in the range of the > creating process, despite an inheritance mechanism already working for > types. What is the reasoning behind this? This may help in understanding: http://marc.info/?l=selinux&m=124688422726897&w=2 Understand that MCS is merely an alternative configuration of the MLS policy engine. Under MLS, new objects are labeled with the low level of the creating process. In a MLS system, the process would have a low level of s0:c1 and thus the files it creates would automatically be labeled as such. MCS deviates from this scheme by only using the high level and by requiring the user/application to intentionally label the objects as desired up to their high level - that is part of what makes it discretionary. Perhaps you ought to use MLS instead. Or just use TE and define domains and types for these processes and files. > I tried to mitigate this by forcing a ssh session into a certain MCS > range, as in ssh user/foo_r:foo_t:s0:c1, however this only works for > changing roles but not for MCS. Not even setting the MCS level in > default_contexts works as one would expect. Again, why? > > Running out of ideas, my solution for now is to hope that a s0 process > cannot search / modify the s0:c1 directory, even with s0 files present > and to periodically "restorecon" the whole dir (no, restorecond does not > seem to be working on dirs recursively). So the third question is, are > there any better ways? > > Regards, > Michal Svoboda -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-08 15:35 ` Stephen Smalley @ 2009-09-08 16:36 ` Michal Svoboda 2009-09-08 17:10 ` Stephen Smalley 0 siblings, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-08 16:36 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 1823 bytes --] Hello, Stephen Smalley wrote: > MCS deviates from this scheme by only using the high level and by > requiring the user/application to intentionally label the objects as > desired up to their high level - that is part of what makes it > discretionary. It is okay that the system is discretionary, and I don't question that fact. I question the way labels get assigned *per default*. In comparison to DAC, it would mean that all files are created with an umask of 000 and are required to change the resulting permissions afterwards. You can not expect that every application out there is aware of MCS and/or that every user uses chcat thoroughly on all new files (plus there are issues like text editors making a copy of a file prior to editing). So in other words DAC nature of MCS is okay it is just that there should be some more sensible defaults pointing towards preservation of labels on objects in their respective containers. The unix setgid bit can do that on directories, as do default ACLs, both being mechanisms of DAC. Secondly I don't see why a user is not able to discretionarily specify his range outright when going via ssh just as he can with roles. > Perhaps you ought to use MLS instead. Or just use TE and define domains > and types for these processes and files. No. MLS is about strict ordering 0 < 1 < 2 ... I just want a partially ordered set. I want compartments, not sensitivities. MCS and MLS are orthogonal, at least by their theoretical properties (and SELinux MCS strongly resembles the theory in practice). And TE? Almost any of these models can be simulated by TE, given types are granular enough, but I don't want the number of types be a quadratic function of compartments plus the hassle associated with that. With regards, Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-08 16:36 ` Michal Svoboda @ 2009-09-08 17:10 ` Stephen Smalley 2009-09-09 10:06 ` Michal Svoboda 0 siblings, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2009-09-08 17:10 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Tue, 2009-09-08 at 18:36 +0200, Michal Svoboda wrote: > It is okay that the system is discretionary, and I don't question that > fact. I question the way labels get assigned *per default*. In > comparison to DAC, it would mean that all files are created with an > umask of 000 and are required to change the resulting permissions > afterwards. You can not expect that every application out there is > aware of MCS and/or that every user uses chcat thoroughly on all new > files (plus there are issues like text editors making a copy of a file > prior to editing). > > So in other words DAC nature of MCS is okay it is just that there should > be some more sensible defaults pointing towards preservation of labels > on objects in their respective containers. The unix setgid bit can do > that on directories, as do default ACLs, both being mechanisms of DAC. Unfortunately for you, MCS is using the existing MLS engine, which doesn't presently support inheritance from parent directory (unlike the TE engine). So to support the behavior you want, you'd have to modify the actual code (and that's kernel code). Thus, you are more likely to find success using actual MLS or using TE. > Secondly I don't see why a user is not able to discretionarily specify > his range outright when going via ssh just as he can with roles. That's another artifact of the MLS model (label preservation / confinement). > > Perhaps you ought to use MLS instead. Or just use TE and define domains > > and types for these processes and files. > > No. MLS is about strict ordering 0 < 1 < 2 ... I just want a partially > ordered set. I want compartments, not sensitivities. MCS and MLS are > orthogonal, at least by their theoretical properties (and SELinux MCS > strongly resembles the theory in practice). I think you're confused about MLS; it supports a set of hierarchical sensitivities and a set of non-hierarchical categories, and MCS is nothing more than a particular configuration of the MLS engine. So you are free to just use a single MLS sensitivity and only use its categories. > And TE? Almost any of these models can be simulated by TE, given types > are granular enough, but I don't want the number of types be a quadratic > function of compartments plus the hassle associated with that. > > With regards, > Michal Svoboda -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-08 17:10 ` Stephen Smalley @ 2009-09-09 10:06 ` Michal Svoboda 2009-09-09 12:17 ` Stephen Smalley 0 siblings, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-09 10:06 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 2318 bytes --] Stephen Smalley wrote: > Unfortunately for you, MCS is using the existing MLS engine, which > doesn't presently support inheritance from parent directory (unlike the > TE engine). So to support the behavior you want, you'd have to modify > the actual code (and that's kernel code). Thus, you are more likely to > find success using actual MLS or using TE. Let me see if I can come up with a simple patch that does the work. It sounds better than rewriting each app to actually change the labels for themselves. (Is there even an API for specifying MCS label prior to file creation? If it has to be changed after the file exists then it's a huge race condition style hole.) > > Secondly I don't see why a user is not able to discretionarily specify > > his range outright when going via ssh just as he can with roles. > > That's another artifact of the MLS model (label preservation / > confinement). Unfortunately here I have no idea on what code should I look to remove that artifact. > > No. MLS is about strict ordering 0 < 1 < 2 ... I just want a partially > > ordered set. I want compartments, not sensitivities. MCS and MLS are > > orthogonal, at least by their theoretical properties (and SELinux MCS > > strongly resembles the theory in practice). > > I think you're confused about MLS; it supports a set of hierarchical > sensitivities and a set of non-hierarchical categories, and MCS is > nothing more than a particular configuration of the MLS engine. So you > are free to just use a single MLS sensitivity and only use its > categories. I think I am not confused. There are two principles, sensitivities and categories. Categories do have hierarchy, just not a strictly ordered one. For any two categories one could find a supremal and infimal ones, and that's what contributes to the quadratic number of types should TE be used instead. A MCS system is then just taking advantage of the categories principle, and not utilising the sensitivities one. That is perfectly what I want, but I just want it to be usable on my use case, ie. files inheriting categories from parent dirs, which I think is perfectly valid. I see this topic recurring and the standard reply "use something else than MCS" is just weird at least. Regards, Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 10:06 ` Michal Svoboda @ 2009-09-09 12:17 ` Stephen Smalley 2009-09-09 13:19 ` Michal Svoboda ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Stephen Smalley @ 2009-09-09 12:17 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Wed, 2009-09-09 at 12:06 +0200, Michal Svoboda wrote: > Stephen Smalley wrote: > > Unfortunately for you, MCS is using the existing MLS engine, which > > doesn't presently support inheritance from parent directory (unlike the > > TE engine). So to support the behavior you want, you'd have to modify > > the actual code (and that's kernel code). Thus, you are more likely to > > find success using actual MLS or using TE. > > Let me see if I can come up with a simple patch that does the work. It > sounds better than rewriting each app to actually change the labels for > themselves. (Is there even an API for specifying MCS label prior to file > creation? If it has to be changed after the file exists then it's a huge > race condition style hole.) setfscreatecon(3) specifies a security context prior to file creation. The kernel MLS logic lives in security/selinux/ss/mls.c. Determining the MLS level of a new subject or object is handled by mls_compute_sid(). Any change would have to support either model (inherit from source context or inherit from target context), so logically it would be policy-driven. Which likely means an extension to the policy language and compiler. Not an entirely trivial undertaking. There is a range_transition statement in the policy that allows one to specify a desired level/range for a new subject/object based on the type pair and class, but that does not support inheritance of the level from the target context. Possibly it could be extended to do so. > > > Secondly I don't see why a user is not able to discretionarily specify > > > his range outright when going via ssh just as he can with roles. > > > > That's another artifact of the MLS model (label preservation / > > confinement). > > Unfortunately here I have no idea on what code should I look to remove > that artifact. I think it is just lack of support in sshd due to lack of interest in supporting it for MLS. You could add it, but you'd need to make sure that it doesn't break the MLS behavior, as that is the one people care about. > > > No. MLS is about strict ordering 0 < 1 < 2 ... I just want a partially > > > ordered set. I want compartments, not sensitivities. MCS and MLS are > > > orthogonal, at least by their theoretical properties (and SELinux MCS > > > strongly resembles the theory in practice). > > > > I think you're confused about MLS; it supports a set of hierarchical > > sensitivities and a set of non-hierarchical categories, and MCS is > > nothing more than a particular configuration of the MLS engine. So you > > are free to just use a single MLS sensitivity and only use its > > categories. > > I think I am not confused. There are two principles, sensitivities and > categories. Categories do have hierarchy, just not a strictly ordered > one. For any two categories one could find a supremal and infimal ones, > and that's what contributes to the quadratic number of types should TE > be used instead. > > A MCS system is then just taking advantage of the categories principle, > and not utilising the sensitivities one. That is perfectly what I want, > but I just want it to be usable on my use case, ie. files inheriting > categories from parent dirs, which I think is perfectly valid. I see > this topic recurring and the standard reply "use something else than > MCS" is just weird at least. Nothing prevents you from using MLS with a single sensitivity, only using categories as the distinguishing element. But that is not identical to MCS, as I've explained - the use of the low/current level differs between MLS and MCS (which in turns creates the problem for you in terms of file labeling under MCS, but would work under MLS), and the set of policy constraints is quite different. TE gives you the desired labeling behavior (inherit from parent directory). MLS gives you the same end result (the process would be labeled s0:c1 and thus its files would get created as such). MCS does not. It isn't so odd then to recommend using something other than MCS. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 12:17 ` Stephen Smalley @ 2009-09-09 13:19 ` Michal Svoboda 2009-09-09 13:34 ` Stephen Smalley 2009-09-14 8:19 ` Michal Svoboda 2009-09-27 7:34 ` Russell Coker 2 siblings, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-09 13:19 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 1287 bytes --] Stephen Smalley wrote: > setfscreatecon(3) specifies a security context prior to file creation. Thanks, this might make it doable in the svn server as an alternative. > Any change would have to support either model (inherit from source > context or inherit from target context), so logically it would be > policy-driven. It can also be derived as the least upper bound of both. If c1-c1,c2 process creates file in a c2 dir, it would make sense that the new file is c1,c2. Alternatively it could just use the default file context from policy. > MLS gives you the same end result (the process would be labeled s0:c1 > and thus its files would get created as such). Maybe I am not seeing something after all. Suppose I use the full MLS variant and give a user the labels c1,c2. How exactly would it happen that in a c1 dir he would automatically create c1 files, and in c1,c2 dir c1,c2 files? > It isn't so odd then to recommend using something other than MCS. It was meant in the context of the article you linked, where it is stated that the goal of MCS is to be more acceptable than MLS for general userbase. And the contrast being that first reply that was given to me from various sources was 'dont use MCS, use MLS'. Regards, Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 13:19 ` Michal Svoboda @ 2009-09-09 13:34 ` Stephen Smalley 2009-09-09 13:59 ` Michal Svoboda 0 siblings, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2009-09-09 13:34 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Wed, 2009-09-09 at 15:19 +0200, Michal Svoboda wrote: > Stephen Smalley wrote: > > setfscreatecon(3) specifies a security context prior to file creation. > > Thanks, this might make it doable in the svn server as an alternative. > > > Any change would have to support either model (inherit from source > > context or inherit from target context), so logically it would be > > policy-driven. > > It can also be derived as the least upper bound of both. If c1-c1,c2 > process creates file in a c2 dir, it would make sense that the new file > is c1,c2. That would require privilege in the MLS case (c1 process cannot search c2 dir, and c1 process requires privilege to write-up to c1,c2 file). In SELinux, that gets represented by requiring that the subject type have a suitable type attribute used in the policy constraint. Such policy interfaces are defined in mls.if. > Alternatively it could just use the default file context from policy. The file_contexts configuration is only used by userspace; the kernel doesn't ever consult it. So if you were modifying the server, it could call matchpathcon(3) or selabel_lookup(3) to look up the context and then apply it using setfscreatecon(3) prior to creat or fsetfilecon(3) after creat. > > MLS gives you the same end result (the process would be labeled s0:c1 > > and thus its files would get created as such). > > Maybe I am not seeing something after all. Suppose I use the full MLS > variant and give a user the labels c1,c2. How exactly would it happen > that in a c1 dir he would automatically create c1 files, and in c1,c2 > dir c1,c2 files? He wouldn't. The first case would violate MLS write-down restrictions. > > It isn't so odd then to recommend using something other than MCS. > > It was meant in the context of the article you linked, where it is > stated that the goal of MCS is to be more acceptable than MLS for > general userbase. And the contrast being that first reply that was > given to me from various sources was 'dont use MCS, use MLS'. Different people have different views of MCS. And it hasn't really worked out the way it was envisioned. There has been some discussion of this, including during the SELinux summits (minutes are published). -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 13:34 ` Stephen Smalley @ 2009-09-09 13:59 ` Michal Svoboda 2009-09-09 14:34 ` Stephen Smalley 0 siblings, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-09 13:59 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 915 bytes --] Stephen Smalley wrote: > > Maybe I am not seeing something after all. Suppose I use the full MLS > > variant and give a user the labels c1,c2. How exactly would it happen > > that in a c1 dir he would automatically create c1 files, and in c1,c2 > > dir c1,c2 files? > > He wouldn't. The first case would violate MLS write-down restrictions. Ah, I see the point now. In some literature, categories are discretionary even when sensitivity levels are used. So a s1:c1 process can write to s1, but not to s0:c1. > Different people have different views of MCS. And it hasn't really > worked out the way it was envisioned. There has been some discussion of > this, including during the SELinux summits (minutes are published). Thanks, I guess I need to read more on that. I've googled the 2007 minutes, but not the other ones. Would you happen to have some links? Regards, Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 13:59 ` Michal Svoboda @ 2009-09-09 14:34 ` Stephen Smalley 0 siblings, 0 replies; 26+ messages in thread From: Stephen Smalley @ 2009-09-09 14:34 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Wed, 2009-09-09 at 15:59 +0200, Michal Svoboda wrote: > Stephen Smalley wrote: > > > Maybe I am not seeing something after all. Suppose I use the full MLS > > > variant and give a user the labels c1,c2. How exactly would it happen > > > that in a c1 dir he would automatically create c1 files, and in c1,c2 > > > dir c1,c2 files? > > > > He wouldn't. The first case would violate MLS write-down restrictions. > > Ah, I see the point now. In some literature, categories are > discretionary even when sensitivity levels are used. So a s1:c1 process > can write to s1, but not to s0:c1. > > > Different people have different views of MCS. And it hasn't really > > worked out the way it was envisioned. There has been some discussion of > > this, including during the SELinux summits (minutes are published). > > Thanks, I guess I need to read more on that. I've googled the 2007 > minutes, but not the other ones. Would you happen to have some links? I think that is likely the most relevant one. On the other hand, MCS categories are being used by the SELinux sandbox tool developed by Dan Walsh and by sVirt as a simple way of separating multiple instances of sandboxes and virtual machines from one another without requiring user configuration, while using TE to control the interactions with the host system. But note that MCS is being used in those cases with low==high (single level). -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 12:17 ` Stephen Smalley 2009-09-09 13:19 ` Michal Svoboda @ 2009-09-14 8:19 ` Michal Svoboda 2009-09-14 12:20 ` Stephen Smalley 2009-09-27 7:34 ` Russell Coker 2 siblings, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-14 8:19 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 1093 bytes --] Stephen Smalley wrote: > The kernel MLS logic lives in security/selinux/ss/mls.c. Determining > the MLS level of a new subject or object is handled by > mls_compute_sid(). Any change would have to support either model > (inherit from source context or inherit from target context), so > logically it would be policy-driven. Which likely means an extension to > the policy language and compiler. Not an entirely trivial undertaking. I have looked at the source code and it seems that in the said function mls_compute_sid(), under the "case AVTAB_CHANGE:" and in the "else" path (tclass != SECCLASS_PROCESS) the statement mls_context_cpy_low(newcontext, scontext) would need to be changed to mls_context_cpy(newcontext, tcontext). To support the original behavior, I would add a 1/0 readable/writable file to selinuxfs, say "mls_defcontext_inherit" by mimicking the behavior of the "enforce" file and its associated r/w functions. It seems to me that this would suffice enough and it would avoid the need to modify the policy language. Would this change be acceptable? Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-14 8:19 ` Michal Svoboda @ 2009-09-14 12:20 ` Stephen Smalley 2009-09-14 13:00 ` Stephen Smalley 2009-09-15 6:32 ` Michal Svoboda 0 siblings, 2 replies; 26+ messages in thread From: Stephen Smalley @ 2009-09-14 12:20 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Mon, 2009-09-14 at 10:19 +0200, Michal Svoboda wrote: > Stephen Smalley wrote: > > The kernel MLS logic lives in security/selinux/ss/mls.c. Determining > > the MLS level of a new subject or object is handled by > > mls_compute_sid(). Any change would have to support either model > > (inherit from source context or inherit from target context), so > > logically it would be policy-driven. Which likely means an extension to > > the policy language and compiler. Not an entirely trivial undertaking. > > I have looked at the source code and it seems that in the said function > mls_compute_sid(), under the "case AVTAB_CHANGE:" and in the "else" path > (tclass != SECCLASS_PROCESS) the statement > > mls_context_cpy_low(newcontext, scontext) > > would need to be changed to > > mls_context_cpy(newcontext, tcontext). > > To support the original behavior, I would add a 1/0 readable/writable > file to selinuxfs, say "mls_defcontext_inherit" by mimicking the > behavior of the "enforce" file and its associated r/w functions. It > seems to me that this would suffice enough and it would avoid the need > to modify the policy language. > > Would this change be acceptable? I don't think so - the problem with selinuxfs tunables is that they can't be changed atomically with a policy change, and this is a property that should be tied to a particular policy. For the same reason, properties like handle_unknown and permissive domains are defined in the policy itself rather than being selinuxfs tunables. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-14 12:20 ` Stephen Smalley @ 2009-09-14 13:00 ` Stephen Smalley 2009-09-15 6:32 ` Michal Svoboda 1 sibling, 0 replies; 26+ messages in thread From: Stephen Smalley @ 2009-09-14 13:00 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux On Mon, 2009-09-14 at 08:20 -0400, Stephen Smalley wrote: > On Mon, 2009-09-14 at 10:19 +0200, Michal Svoboda wrote: > > Stephen Smalley wrote: > > > The kernel MLS logic lives in security/selinux/ss/mls.c. Determining > > > the MLS level of a new subject or object is handled by > > > mls_compute_sid(). Any change would have to support either model > > > (inherit from source context or inherit from target context), so > > > logically it would be policy-driven. Which likely means an extension to > > > the policy language and compiler. Not an entirely trivial undertaking. > > > > I have looked at the source code and it seems that in the said function > > mls_compute_sid(), under the "case AVTAB_CHANGE:" and in the "else" path > > (tclass != SECCLASS_PROCESS) the statement > > > > mls_context_cpy_low(newcontext, scontext) > > > > would need to be changed to > > > > mls_context_cpy(newcontext, tcontext). > > > > To support the original behavior, I would add a 1/0 readable/writable > > file to selinuxfs, say "mls_defcontext_inherit" by mimicking the > > behavior of the "enforce" file and its associated r/w functions. It > > seems to me that this would suffice enough and it would avoid the need > > to modify the policy language. > > > > Would this change be acceptable? > > I don't think so - the problem with selinuxfs tunables is that they > can't be changed atomically with a policy change, and this is a property > that should be tied to a particular policy. For the same reason, > properties like handle_unknown and permissive domains are defined in the > policy itself rather than being selinuxfs tunables. Also, in your situation, I don't think you want to change the AVTAB_CHANGE behavior but only the AVTAB_TRANSITION behavior. Thus you'd need to change that logic to replicate the AVTAB_CHANGE logic under AVTAB_TRANSITION (and no longer fall through), and then change the copy under AVTAB_TRANSITION, so that you wouldn't affect the AVTAB_CHANGE behavior. AVTAB_CHANGE is exercised when relabeling the tty/pty at login time to match the user's credentials, and there you do not want to stay with the current object level but rather use the process' level even for your usage. AVTAB_TRANSITION is exercised when creating a new subject or object. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-14 12:20 ` Stephen Smalley 2009-09-14 13:00 ` Stephen Smalley @ 2009-09-15 6:32 ` Michal Svoboda 2009-09-15 11:16 ` Stephen Smalley 1 sibling, 1 reply; 26+ messages in thread From: Michal Svoboda @ 2009-09-15 6:32 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 1527 bytes --] Stephen Smalley wrote: > I don't think so - the problem with selinuxfs tunables is that they > can't be changed atomically with a policy change, and this is a property > that should be tied to a particular policy. For the same reason, > properties like handle_unknown and permissive domains are defined in the > policy itself rather than being selinuxfs tunables. There have been things like compat_net, why can't the inheritance be done on the same basis and must be part of the policy instead? Anyway, I've been looking at the policy loader code, and it seems that the easiest way to incorporate this into the policy would be to blend it with the config field (which is presently used for MLS and handle_unknown flags), perhaps by defining a flag like CATEGORY_INHERIT and to check for it right after ALLOW_UNKNOWN and REJECT_UNKNOWN are processed. This flag would then go to struct policydb and would be checked for in the mls_compute_sid function (I can see direct usage of the policydb global variable in that very function, so I guess it shouldn't be a problem). Perhaps there could also be an upgrade of the policy version number and a check for the policy being loaded just to prevent random values being present in that bit. There would also need to be a change in libsepol and checkpolicy to reflect this; perhaps checkpolicy could accept an additional command line argument (as it does with handle_unknown), and a new field defined in libsepol's policydb_t and further processed in its write.c. Michal Svoboda [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-15 6:32 ` Michal Svoboda @ 2009-09-15 11:16 ` Stephen Smalley 0 siblings, 0 replies; 26+ messages in thread From: Stephen Smalley @ 2009-09-15 11:16 UTC (permalink / raw) To: Michal Svoboda; +Cc: selinux, Joshua Brindle On Tue, 2009-09-15 at 08:32 +0200, Michal Svoboda wrote: > Stephen Smalley wrote: > > I don't think so - the problem with selinuxfs tunables is that they > > can't be changed atomically with a policy change, and this is a property > > that should be tied to a particular policy. For the same reason, > > properties like handle_unknown and permissive domains are defined in the > > policy itself rather than being selinuxfs tunables. > > There have been things like compat_net, why can't the inheritance be > done on the same basis and must be part of the policy instead? compat_net was viewed as a mistake in retrospect, something we don't want to repeat. > Anyway, I've been looking at the policy loader code, and it seems that > the easiest way to incorporate this into the policy would be to blend it > with the config field (which is presently used for MLS and > handle_unknown flags), perhaps by defining a flag like CATEGORY_INHERIT > and to check for it right after ALLOW_UNKNOWN and REJECT_UNKNOWN are > processed. This flag would then go to struct policydb and would be > checked for in the mls_compute_sid function (I can see direct usage of > the policydb global variable in that very function, so I guess it > shouldn't be a problem). > > Perhaps there could also be an upgrade of the policy version number and > a check for the policy being loaded just to prevent random values being > present in that bit. > > There would also need to be a change in libsepol and checkpolicy to > reflect this; perhaps checkpolicy could accept an additional command > line argument (as it does with handle_unknown), and a new field defined > in libsepol's policydb_t and further processed in its write.c. Sounds about right to me. It would technically be MLS_RANGE_INHERIT or similar since it involves more than just the categories. It might be cleaner to make it an actual statement in the policy language rather than a checkpolicy option, so that policy/mls or policy/mcs declares the desired default transition behavior for objects, at which point you'd generalize it. The current behavior is copy-low-from-source; you want copy-range-from-target. But others might want copy-high-from-source or copy-high-from-target or copy-low-from-target or copy-range-from-source. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-09 12:17 ` Stephen Smalley 2009-09-09 13:19 ` Michal Svoboda 2009-09-14 8:19 ` Michal Svoboda @ 2009-09-27 7:34 ` Russell Coker 2009-09-28 13:37 ` Stephen Smalley 2 siblings, 1 reply; 26+ messages in thread From: Russell Coker @ 2009-09-27 7:34 UTC (permalink / raw) To: Stephen Smalley; +Cc: Michal Svoboda, selinux On Wed, 9 Sep 2009, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > > Secondly I don't see why a user is not able to discretionarily > > > > specify his range outright when going via ssh just as he can with > > > > roles. > > > > > > That's another artifact of the MLS model (label preservation / > > > confinement). > > > > Unfortunately here I have no idea on what code should I look to remove > > that artifact. > > I think it is just lack of support in sshd due to lack of interest in > supporting it for MLS. You could add it, but you'd need to make sure > that it doesn't break the MLS behavior, as that is the one people care > about. If a user has a default range of A and they request a range of B then the same checks could be applied as for a runcon -l B operation when the source range was A. How could that break anything? -- russell@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-27 7:34 ` Russell Coker @ 2009-09-28 13:37 ` Stephen Smalley 2009-09-28 20:57 ` Russell Coker 2009-09-28 23:22 ` Kyle Moffett 0 siblings, 2 replies; 26+ messages in thread From: Stephen Smalley @ 2009-09-28 13:37 UTC (permalink / raw) To: russell; +Cc: Michal Svoboda, selinux On Sun, 2009-09-27 at 17:34 +1000, Russell Coker wrote: > On Wed, 9 Sep 2009, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > > > Secondly I don't see why a user is not able to discretionarily > > > > > specify his range outright when going via ssh just as he can with > > > > > roles. > > > > > > > > That's another artifact of the MLS model (label preservation / > > > > confinement). > > > > > > Unfortunately here I have no idea on what code should I look to remove > > > that artifact. > > > > I think it is just lack of support in sshd due to lack of interest in > > supporting it for MLS. You could add it, but you'd need to make sure > > that it doesn't break the MLS behavior, as that is the one people care > > about. > > If a user has a default range of A and they request a range of B then the same > checks could be applied as for a runcon -l B operation when the source range > was A. > > How could that break anything? 1. You can't switch levels via runcon under MLS policy - runcon runs in the caller's domain. 2. newrole -l is prohibited on an "insecure" tty under MLS policy, which means any ptys at all due to the potential for downgrading data through the pty. Same issue applies for a ssh connection. LSPP requires level preservation. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-28 13:37 ` Stephen Smalley @ 2009-09-28 20:57 ` Russell Coker 2009-09-28 23:22 ` Kyle Moffett 1 sibling, 0 replies; 26+ messages in thread From: Russell Coker @ 2009-09-28 20:57 UTC (permalink / raw) To: Stephen Smalley; +Cc: Michal Svoboda, selinux On Mon, 28 Sep 2009, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > I think it is just lack of support in sshd due to lack of interest in > > > supporting it for MLS. You could add it, but you'd need to make sure > > > that it doesn't break the MLS behavior, as that is the one people care > > > about. > > > > If a user has a default range of A and they request a range of B then the > > same checks could be applied as for a runcon -l B operation when the > > source range was A. > > > > How could that break anything? > > 1. You can't switch levels via runcon under MLS policy - runcon runs in > the caller's domain. > > 2. newrole -l is prohibited on an "insecure" tty under MLS policy, > which means any ptys at all due to the potential for downgrading data > through the pty. Same issue applies for a ssh connection. So it doesn't break anything for MLS. ;) -- russell@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-28 13:37 ` Stephen Smalley 2009-09-28 20:57 ` Russell Coker @ 2009-09-28 23:22 ` Kyle Moffett 2009-09-29 12:21 ` Stephen Smalley 1 sibling, 1 reply; 26+ messages in thread From: Kyle Moffett @ 2009-09-28 23:22 UTC (permalink / raw) To: Stephen Smalley; +Cc: russell, Michal Svoboda, selinux On Mon, Sep 28, 2009 at 09:37, Stephen Smalley <sds@tycho.nsa.gov> wrote: > On Sun, 2009-09-27 at 17:34 +1000, Russell Coker wrote: >> On Wed, 9 Sep 2009, Stephen Smalley <sds@tycho.nsa.gov> wrote: >>> I think it is just lack of support in sshd due to lack of interest in >>> supporting it for MLS. You could add it, but you'd need to make sure >>> that it doesn't break the MLS behavior, as that is the one people care >>> about. >> >> If a user has a default range of A and they request a range of B then the same >> checks could be applied as for a runcon -l B operation when the source range >> was A. >> >> How could that break anything? > > 1. You can't switch levels via runcon under MLS policy - runcon runs in > the caller's domain. > > 2. newrole -l is prohibited on an "insecure" tty under MLS policy, > which means any ptys at all due to the potential for downgrading data > through the pty. Same issue applies for a ssh connection. > > LSPP requires level preservation. Hmm, I've been thinking about a way to resolve this for a while now... The company I work for builds trusted guards, and people keep asking us about allowing some amount of secure remote management. I wonder if it is possible to build some kind of automatic IPsec negotiation based on the SELinux MLS label. Currently you can manually create IPsec tunnels and associate a different *type* with each tunnel, however I can find no way to do a different tunnel per MLS level (on-demand). I'm thinking of a user-interface along the lines of: Put this in your auto-IPsec-aware program: one = 1; setsockopt(fd, SOL_SOCKET, SO_AUTOIPSEC, &one, sizeof(one)); Then you would put some special configuration in your ipsec-tools.conf to indicate some traffic should be "auto-ctx" negotiated. The kernel would then pass the security label to the racoon daemon (running at the same MLS level as the wire). Racoon would negotiate an SA, and then install it with a level-specific match. The end result would be that your program (say, SSH) running at s4:c3 would make an automatically-IPsec-protected connection to the SSHD running on another computer. That SystemLow-SystemHigh SSHD would fork a child with the socket, which would run "getpeercon()" and switch to the appropriate level before trying to use it. There are still other issues, but that would at least make it possible. Cheers, Kyle Moffett -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-28 23:22 ` Kyle Moffett @ 2009-09-29 12:21 ` Stephen Smalley 2009-09-29 13:54 ` Kyle Moffett 0 siblings, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2009-09-29 12:21 UTC (permalink / raw) To: Kyle Moffett; +Cc: russell, Michal Svoboda, selinux, Joshua Brindle, Paul Moore On Mon, 2009-09-28 at 19:22 -0400, Kyle Moffett wrote: > On Mon, Sep 28, 2009 at 09:37, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > On Sun, 2009-09-27 at 17:34 +1000, Russell Coker wrote: > >> On Wed, 9 Sep 2009, Stephen Smalley <sds@tycho.nsa.gov> wrote: > >>> I think it is just lack of support in sshd due to lack of interest in > >>> supporting it for MLS. You could add it, but you'd need to make sure > >>> that it doesn't break the MLS behavior, as that is the one people care > >>> about. > >> > >> If a user has a default range of A and they request a range of B then the same > >> checks could be applied as for a runcon -l B operation when the source range > >> was A. > >> > >> How could that break anything? > > > > 1. You can't switch levels via runcon under MLS policy - runcon runs in > > the caller's domain. > > > > 2. newrole -l is prohibited on an "insecure" tty under MLS policy, > > which means any ptys at all due to the potential for downgrading data > > through the pty. Same issue applies for a ssh connection. > > > > LSPP requires level preservation. > > Hmm, I've been thinking about a way to resolve this for a while now... > The company I work for builds trusted guards, and people keep asking > us about allowing some amount of secure remote management. > > I wonder if it is possible to build some kind of automatic IPsec > negotiation based on the SELinux MLS label. Currently you can > manually create IPsec tunnels and associate a different *type* with > each tunnel, however I can find no way to do a different tunnel per > MLS level (on-demand). Doesn't this get done via labeled IPSEC already? It should request a separate SA for each unique sending socket security context. http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ > I'm thinking of a user-interface along the lines of: > > Put this in your auto-IPsec-aware program: > one = 1; > setsockopt(fd, SOL_SOCKET, SO_AUTOIPSEC, &one, sizeof(one)); > > Then you would put some special configuration in your ipsec-tools.conf > to indicate some traffic should be "auto-ctx" negotiated. The kernel > would then pass the security label to the racoon daemon (running at > the same MLS level as the wire). Racoon would negotiate an SA, and > then install it with a level-specific match. > > The end result would be that your program (say, SSH) running at s4:c3 > would make an automatically-IPsec-protected connection to the SSHD > running on another computer. That SystemLow-SystemHigh SSHD would > fork a child with the socket, which would run "getpeercon()" and > switch to the appropriate level before trying to use it. > > There are still other issues, but that would at least make it possible. > > Cheers, > Kyle Moffett > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-29 12:21 ` Stephen Smalley @ 2009-09-29 13:54 ` Kyle Moffett 2009-09-29 20:54 ` Paul Moore 0 siblings, 1 reply; 26+ messages in thread From: Kyle Moffett @ 2009-09-29 13:54 UTC (permalink / raw) To: Stephen Smalley Cc: russell, Michal Svoboda, selinux, Joshua Brindle, Paul Moore On Tue, Sep 29, 2009 at 08:21, Stephen Smalley <sds@tycho.nsa.gov> wrote: > On Mon, 2009-09-28 at 19:22 -0400, Kyle Moffett wrote: >> Hmm, I've been thinking about a way to resolve this for a while now... >> The company I work for builds trusted guards, and people keep asking >> us about allowing some amount of secure remote management. >> >> I wonder if it is possible to build some kind of automatic IPsec >> negotiation based on the SELinux MLS label. Currently you can >> manually create IPsec tunnels and associate a different *type* with >> each tunnel, however I can find no way to do a different tunnel per >> MLS level (on-demand). > > Doesn't this get done via labeled IPSEC already? It should request a > separate SA for each unique sending socket security context. > http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ The problem is that there is no way to do catch-all rules *based* on the MLS label. For example, if I have a TopSecret wire and I want to allow (for example) Unclass and TS//SI/TK traffic over it without risking mixing of data or exposure, there is no way for me to set it up without a lot of manual and duplicated configuration. What I want to happen is: (1) If any of 8 different SELinux domains of TS-level processes (IE: s4) try to communicate out the network interface, the policy is "none" (2) If those *same* SELinux domains with any of TS//SI/TK (s4:c1), TS//BYEMAN (s4:c2) try to communicate, the policy should be "esp/transport//require", using *different* certificates depending on the domain. (3) Again, if those *same* SELinux domains with U (IE: s1) try to communicate, the policy would be "ah/transport//require", (and yet more certificates). If it's possible to do this with the existing tools, that's great, but I played around with it for a good long while and was not able to work out a way to do so. I suppose at the very least the feature needs some better documentation :-D. If the feature does already exist, then assuming I can get it working, I'd be glad to go write some. Cheers, Kyle Moffett -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-29 13:54 ` Kyle Moffett @ 2009-09-29 20:54 ` Paul Moore 2009-09-30 3:51 ` Kyle Moffett 0 siblings, 1 reply; 26+ messages in thread From: Paul Moore @ 2009-09-29 20:54 UTC (permalink / raw) To: Kyle Moffett Cc: Stephen Smalley, russell, Michal Svoboda, selinux, Joshua Brindle On Tuesday 29 September 2009 09:54:56 am Kyle Moffett wrote: > The problem is that there is no way to do catch-all rules *based* on > the MLS label. For example, if I have a TopSecret wire and I want to > allow (for example) Unclass and TS//SI/TK traffic over it without > risking mixing of data or exposure, there is no way for me to set it > up without a lot of manual and duplicated configuration. What I want > to happen is: Just a few questions so I'm clear on your problem. > (1) If any of 8 different SELinux domains of TS-level processes (IE: > s4) try to communicate out the network interface, the policy is "none" So any of the eight domains can send network traffic w/o IPsec as long as their MLS label is "s4" ... > (2) If those *same* SELinux domains with any of TS//SI/TK (s4:c1), > TS//BYEMAN (s4:c2) try to communicate, the policy should be > "esp/transport//require", using *different* certificates depending on > the domain. ... and these same eight domains need to send network traffic using IPsec/ESP when their MLS label is "s4:c1" or "s4:c2" (do you really mean different certificates for each connection, which implies a new phase-1 IKE negotiation or did you simply mean new ESP SAs?) > (3) Again, if those *same* SELinux domains with U (IE: s1) try to > communicate, the policy would be "ah/transport//require", (and yet > more certificates). ... and if these same eight domains need to send network traffic using IPsec/AH when their MLS label is "s1" (once again, do you really mean SA instead of cert)? > If it's possible to do this with the existing tools, that's great, but > I played around with it for a good long while and was not able to work > out a way to do so. The different IPsec configurations per label is a little interesting, and not something that I've heard of people using (until just now). I'd have to go spelunking in the code but I'm pretty sure you can't pick SPD rules based on security labels (you can authorize access to a rule using labels, but I don't believe the label acts as a selector). I imagine you could get something working with manual SA creation but that is too ugly to spend much time thinking about it. At this point I have to ask some workaround type questions - can you isolate the traffic using traditional IPsec traffic selectors instead of labels, e.g. protocol/port? Is there any harm in applying both AH and ESP to all traffic that needs IPsec protection? Do you need to convey the type information across the wire or is the MLS label sufficient? Depending on your answers we may be able to arrive at a solution with the existing code. -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-29 20:54 ` Paul Moore @ 2009-09-30 3:51 ` Kyle Moffett 2009-09-30 13:19 ` Paul Moore 0 siblings, 1 reply; 26+ messages in thread From: Kyle Moffett @ 2009-09-30 3:51 UTC (permalink / raw) To: Paul Moore Cc: Stephen Smalley, russell, Michal Svoboda, selinux, Joshua Brindle On Tue, Sep 29, 2009 at 16:54, Paul Moore <paul.moore@hp.com> wrote: > On Tuesday 29 September 2009 09:54:56 am Kyle Moffett wrote: >> The problem is that there is no way to do catch-all rules *based* on >> the MLS label. For example, if I have a TopSecret wire and I want to >> allow (for example) Unclass and TS//SI/TK traffic over it without >> risking mixing of data or exposure, there is no way for me to set it >> up without a lot of manual and duplicated configuration. What I want >> to happen is: > > Just a few questions so I'm clear on your problem. > >> (1) If any of 8 different SELinux domains of TS-level processes (IE: >> s4) try to communicate out the network interface, the policy is "none" > > So any of the eight domains can send network traffic w/o IPsec as long as > their MLS label is "s4" ... > >> (2) If those *same* SELinux domains with any of TS//SI/TK (s4:c1), >> TS//BYEMAN (s4:c2) try to communicate, the policy should be >> "esp/transport//require", using *different* certificates depending on >> the domain. > > ... and these same eight domains need to send network traffic using IPsec/ESP > when their MLS label is "s4:c1" or "s4:c2" (do you really mean different > certificates for each connection, which implies a new phase-1 IKE negotiation > or did you simply mean new ESP SAs?) > >> (3) Again, if those *same* SELinux domains with U (IE: s1) try to >> communicate, the policy would be "ah/transport//require", (and yet >> more certificates). > > ... and if these same eight domains need to send network traffic using > IPsec/AH when their MLS label is "s1" (once again, do you really mean SA > instead of cert)? Yes, this is correct. Imagine, if you will, for government purposes (or even for a corporation complying with the various personal information requirements), you have a patched HTTPD running on one box. The parent process runs with a range like "s1 - s4:c1,c2" (or "s0 - s0:c1,c2" for the business case). When you receive a connection, the HTTPD server does "getpeercon" and then either forks and sets its range or sends the FD over a UNIX-domain socket to the right child process. The end result, is with *one* HTTP server started with "s1 - s4:c1,c2", communicating over a wire treated as "s4", you can serve multiple clients. For government or corporate purposes, it prevents somebody from a lower level from receiving data they are not allowed to access (either personal info or classified data), and prevents somebody from a higher level from contaminating files on the server that are of the lower level. The best part is, you can even have computers connected to the network which are not trusted to maintain data separation, as long as they are allowed to process data at the "level" of the unprotected data going over the wire (IE: s4). If you can use separate certificates to do the authentication, you can have partially-trusted systems (which only have keys issued for some levels and not others). >> If it's possible to do this with the existing tools, that's great, but >> I played around with it for a good long while and was not able to work >> out a way to do so. > > The different IPsec configurations per label is a little interesting, and not > something that I've heard of people using (until just now). I'd have to go > spelunking in the code but I'm pretty sure you can't pick SPD rules based on > security labels (you can authorize access to a rule using labels, but I don't > believe the label acts as a selector). I imagine you could get something > working with manual SA creation but that is too ugly to spend much time > thinking about it. > > At this point I have to ask some workaround type questions - can you isolate > the traffic using traditional IPsec traffic selectors instead of labels, e.g. > protocol/port? Is there any harm in applying both AH and ESP to all traffic > that needs IPsec protection? Do you need to convey the type information > across the wire or is the MLS label sufficient? Depending on your answers we > may be able to arrive at a solution with the existing code. Basically, my end goal is to be able to have a network of Linux boxes (with the network itself being "s4", for example) and *guarantee* that: (A) Any unlabelled data coming in off the network is treated by SELinux is s4 (B) No processes are allowed to communicate out the network unprotected unless they are exactly s4 (C) Processes which are *not* s4 may communicate over the network only when protected by IPsec, and only if the IPsec connection is specifically negotiated using certificates/keys based on the level of the data being protected. These kinds of guarantees are available if you take something like a hardware IPsec device, plug the plaintext and ciphertext ports into the SELinux box, and then label traffic through those two interfaces specifically. The problem is, that only works with the two MLS labels configured on the ports of that device. Beyond that, those devices are damn expensive and a lot of boards already have usable crypto-accelerators on them. Cheers, Kyle Moffett -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-30 3:51 ` Kyle Moffett @ 2009-09-30 13:19 ` Paul Moore 2009-09-30 13:49 ` Kyle Moffett 0 siblings, 1 reply; 26+ messages in thread From: Paul Moore @ 2009-09-30 13:19 UTC (permalink / raw) To: Kyle Moffett Cc: Stephen Smalley, russell, Michal Svoboda, selinux, Joshua Brindle On Tuesday 29 September 2009 11:51:42 pm Kyle Moffett wrote: > Basically, my end goal is to be able to have a network of Linux boxes > (with the network itself being "s4", for example) and *guarantee* > that: Thanks for the clarification; I'm pretty sure we can get something working. > (A) Any unlabelled data coming in off the network is treated by SELinux > is s4 You can either provide special handling for this in your application(s) or you can configure the kernel to return a static label for unlabeled traffic. Personally I think it would be easier to just configure the kernel to do it for you, but if you have a custom app, maybe not ... * http://paulmoore.livejournal.com/1758.html > (B) No processes are allowed to communicate out the network > unprotected unless they are exactly s4 It should be possible to configure the SPD and write policy such that the "no IPsec" SPD rule only matches traffic from "s4" labeled sockets, then all you need to do is add a catch-all SPD rule to wrap with ESP/AH (or drop) all traffic not explicitly specified in the SPD. I haven't tried this personally, but I don't see any reason why it wouldn't work (and I would consider it a bug if it didn't). > (C) Processes which are *not* s4 may communicate over the network > only when protected by IPsec, and only if the IPsec connection is > specifically negotiated using certificates/keys based on the level of > the data being protected. I think the tricky part here is the "... certificates/keys based on the level of the data ..." statement. Is is sufficient to have one certificate per host/node as long as you have one SA per label? -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-30 13:19 ` Paul Moore @ 2009-09-30 13:49 ` Kyle Moffett 2009-09-30 14:20 ` Paul Moore 0 siblings, 1 reply; 26+ messages in thread From: Kyle Moffett @ 2009-09-30 13:49 UTC (permalink / raw) To: Paul Moore Cc: Stephen Smalley, russell, Michal Svoboda, selinux, Joshua Brindle On Wed, Sep 30, 2009 at 09:19, Paul Moore <paul.moore@hp.com> wrote: > On Tuesday 29 September 2009 11:51:42 pm Kyle Moffett wrote: >> (C) Processes which are *not* s4 may communicate over the network >> only when protected by IPsec, and only if the IPsec connection is >> specifically negotiated using certificates/keys based on the level of >> the data being protected. > > I think the tricky part here is the "... certificates/keys based on the level > of the data ..." statement. Is is sufficient to have one certificate per > host/node as long as you have one SA per label? Unfortunately not. Imagine that the device is some kind of network appliance, router, etc. You would not want to reconfigure your storage server or router every time you add a new node. Beyond that, different data levels probably have different protection requirements. For instance, say you have a physical network that is safe to transport "personal data" unprotected, but not "trade secrets" (IE: the network itself is s0:c1): * When you send data between "s0" processes across the network, you would want to save CPU and enable better network debugging by just using AH (the data doesn't need protection against exposure, just against contamination). * When you send data between "trade secrets" (s0:c2) processes across the network, that *does* need protection, and so you would use ESP. For a lot of government classified-data systems, there's a lot more levels than that, and some levels require different key-lengths or algorithms. I'm afraid that for the purposes I am interested in, a separate root-CA per MLS level is really the only practical configuration. Given that, I guess the question is, how hard would it be to modify racoon and/or the kernel to give me the behavior I want? Cheers, Kyle Moffett -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: MCS and default labels 2009-09-30 13:49 ` Kyle Moffett @ 2009-09-30 14:20 ` Paul Moore 0 siblings, 0 replies; 26+ messages in thread From: Paul Moore @ 2009-09-30 14:20 UTC (permalink / raw) To: Kyle Moffett Cc: Stephen Smalley, russell, Michal Svoboda, selinux, Joshua Brindle On Wednesday 30 September 2009 09:49:51 am Kyle Moffett wrote: > On Wed, Sep 30, 2009 at 09:19, Paul Moore <paul.moore@hp.com> wrote: > > On Tuesday 29 September 2009 11:51:42 pm Kyle Moffett wrote: > >> (C) Processes which are *not* s4 may communicate over the network > >> only when protected by IPsec, and only if the IPsec connection is > >> specifically negotiated using certificates/keys based on the level of > >> the data being protected. > > > > I think the tricky part here is the "... certificates/keys based on the > > level of the data ..." statement. Is is sufficient to have one > > certificate per host/node as long as you have one SA per label? > > Unfortunately not. Imagine that the device is some kind of network > appliance, router, etc. You would not want to reconfigure your > storage server or router every time you add a new node. True, but I don't follow how having one IKE phase-1 negotiation with a node (single certificate for the node) requires reconfiguration ... I suppose if you require a certificate per-label (which it appears you do) ... > Beyond that, different data levels probably have different protection > requirements. For instance, say you have a physical network that is safe to > transport "personal data" unprotected, but not "trade secrets" (IE: > the network itself is s0:c1): > > * When you send data between "s0" processes across the network, you > would want to save CPU and enable better network debugging by just > using AH (the data doesn't need protection against exposure, just > against contamination). > > * When you send data between "trade secrets" (s0:c2) processes > across the network, that *does* need protection, and so you would use > ESP. I understand that, I'm just fairly certain that it isn't possible with the current implementation. I was asking about using the same/most-stringent IPsec configuration (AH/ESP, algorithms, key lengths, etc.) for the different labels as that is possible today. > For a lot of government classified-data systems, there's a lot more > levels than that, and some levels require different key-lengths or > algorithms. I'm afraid that for the purposes I am interested in, a > separate root-CA per MLS level is really the only practical > configuration. Unfortunately, that last requirement is the show stopper for the current implementation. While we generate per-label AH/ESP SAs, I am almost certain we do not generate a new phase-1 SA for each new AH/ESP SA (generally considered to be wasteful). > Given that, I guess the question is, how hard would it be to modify > racoon and/or the kernel to give me the behavior I want? I think one of the biggest problems that you will have to overcome is that I believe racoon maps a single "secret" (PSK, certificate, etc.) to a single IP address; what you want to do will require multiple "secrets" per node and will require some rework of the racoon code. The extent of the rework is not something I can scope with any certainty, but my guess would be that it is non-trivial. The kernel modifications should be fairly trivial, if any are required, since userspace is responsible for IKE negotiation. At this point I would encourage you to start thinking about alternative solutions to the problem but if the guard requirements are strict and explicit than I understand this may not be an option for you - in that case, I wish you the best of luck. -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2009-09-30 14:20 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-08 5:58 MCS and default labels Michal Svoboda 2009-09-08 15:35 ` Stephen Smalley 2009-09-08 16:36 ` Michal Svoboda 2009-09-08 17:10 ` Stephen Smalley 2009-09-09 10:06 ` Michal Svoboda 2009-09-09 12:17 ` Stephen Smalley 2009-09-09 13:19 ` Michal Svoboda 2009-09-09 13:34 ` Stephen Smalley 2009-09-09 13:59 ` Michal Svoboda 2009-09-09 14:34 ` Stephen Smalley 2009-09-14 8:19 ` Michal Svoboda 2009-09-14 12:20 ` Stephen Smalley 2009-09-14 13:00 ` Stephen Smalley 2009-09-15 6:32 ` Michal Svoboda 2009-09-15 11:16 ` Stephen Smalley 2009-09-27 7:34 ` Russell Coker 2009-09-28 13:37 ` Stephen Smalley 2009-09-28 20:57 ` Russell Coker 2009-09-28 23:22 ` Kyle Moffett 2009-09-29 12:21 ` Stephen Smalley 2009-09-29 13:54 ` Kyle Moffett 2009-09-29 20:54 ` Paul Moore 2009-09-30 3:51 ` Kyle Moffett 2009-09-30 13:19 ` Paul Moore 2009-09-30 13:49 ` Kyle Moffett 2009-09-30 14:20 ` Paul Moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.