MCS and default labels

MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Michal Svoboda]

[-- 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 --]

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Russell Coker]

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.

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Russell Coker]

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.

Re: MCS and default labels

[Kyle Moffett]

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.

Re: MCS and default labels

[Stephen Smalley]

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.

Re: MCS and default labels

[Kyle Moffett]

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.

Re: MCS and default labels

[Paul Moore]

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.

Re: MCS and default labels

[Kyle Moffett]

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.

Re: MCS and default labels

[Paul Moore]

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.

Re: MCS and default labels

[Kyle Moffett]

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.

Re: MCS and default labels

[Paul Moore]

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.