Subject: [nfsv4] Common labeled security (comment on CALIPSO, labeled NFSv4)

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 10:44:02 -0500

Over at the NFSv4 WG we've been having a discussion of a labeled NFSv4
proposal.  [Note: NFSv4 WG and others cc'ed, Reply-To: set to SAAG.]

An interop issue has arisen that we believe applies equally to CALIPSO
(draft-stjohns-sipso-11.txt)and requires input from the IETF security
area.

The issue is: how do do nodes in a labeled network/application know if
they agree on a common labeled security policy for a given DOI?

Agreeing on a DOI is accomplished easily enough -- that's not an issue.
Agreeing on what a given numeric sensitivity level or compartment bit
means in a given DOI is quite another.  Without a solution to this we're
left with out-of-band agreement, which leaves interop in a lurch.

I think we need a generic MLS and DTE labeled security policy document
format that allows a DOI to define the names and numeric assignments of
sensitivity levels, compartments, etcetera.

We also need a way for nodes to agree that they have the same policy for
a given DOI, or that they agree on a common subset of a DOI's policy.

This last problem can be solved by use of a labeled security policy URI
scheme that includes a version number (+ a requirement that changes be
in the form of additions and obsolescence of old assignments, but not
removals).

To recap: I think we need a) a common MLS and DTE labeled security
policy document format, b) a labeled security policy URI scheme to refer
to such documents by.

Given (a) and (b) NFSv4.x clients and servers would only have to
exchange {DOI #, policy URI} tuples to determine whether they agree on a
common policy.

Note that CALIPSO describes how to encode and compare MLS labels on the
wire, but it does not describe how nodes agree on the meaning of
particular sensitivity levels or compartments.  Therefore CALIPSO is
going to have much the same problem as NFSv4.

Nico
--

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Apr 2009 11:22:38 -0400

As part of MISSI and DMS, in mid to late 90's we did work on something
called Security Policy Information File (SPIF).

At high level SPIF entailed the following:

1.  It was ASN.1 based.
2.  It permitted you to convert the machine representation to human
readable representation.
3.  It permitted you to convert the human readable input to machine
representation.
4.  It mapped labels (hierarchical sensitivity levels and
non-hierarchical categories) from one labeling policy to another (i.e.,
establish equivalency mapping)
5.  It allowed you to constrain labels since for some policies,
existence of a category may mean some categories, levels, may be
included and/or excluded.

Different labeling policies were indicated by different policy OID.

Some of the concept from that work may be applicable here. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Nicolas Williams
> Sent: Thursday, April 02, 2009 11:44 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [saag] Common labeled security (comment on CALIPSO, 
> labeled NFSv4)
> 
> Over at the NFSv4 WG we've been having a discussion of a 
> labeled NFSv4 proposal.  [Note: NFSv4 WG and others cc'ed, 
> Reply-To: set to SAAG.]
> 
> An interop issue has arisen that we believe applies equally 
> to CALIPSO (draft-stjohns-sipso-11.txt)and requires input 
> from the IETF security area.
> 
> The issue is: how do do nodes in a labeled 
> network/application know if they agree on a common labeled 
> security policy for a given DOI?
> 
> Agreeing on what a given numeric sensitivity level or 
> compartment bit means in a given DOI is quite another.  
> Without a solution to this we're left with out-of-band 
> agreement, which leaves interop in a lurch.
> 
> I think we need a generic MLS and DTE labeled security policy 
> document format that allows a DOI to define the names and 
> numeric assignments of sensitivity levels, compartments, etcetera.
> 
> We also need a way for nodes to agree that they have the same 
> policy for a given DOI, or that they agree on a common subset 
> of a DOI's policy.
> 
> This last problem can be solved by use of a labeled security 
> policy URI scheme that includes a version number (+ a 
> requirement that changes be in the form of additions and 
> obsolescence of old assignments, but not removals).
> 
> To recap: I think we need a) a common MLS and DTE labeled 
> security policy document format, b) a labeled security policy 
> URI scheme to refer to such documents by.
> 
> Given (a) and (b) NFSv4.x clients and servers would only have 
> to exchange {DOI #, policy URI} tuples to determine whether 
> they agree on a common policy.
> 
> Note that CALIPSO describes how to encode and compare MLS 
> labels on the wire, but it does not describe how nodes agree 
> on the meaning of particular sensitivity levels or 
> compartments.  Therefore CALIPSO is going to have much the 
> same problem as NFSv4.
> 
> Nico
> --
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 10:42:54 -0500

> called Security Policy Information File (SPIF).

Oh, very nice!  Thanks for the pointer.  That would be ISO15816.  I've
found the spec, though it's non-free (hadn't they learned the lesson
with ASN.1??  will they ever learn it??).

> At high level SPIF entailed the following:

Not surprisingly :)  Converting that to XML is probably the correct
first step in order to ensure adoption, sadly.  (Actually, apparently
that has already been done once, though outside the ISO/ITU-T.)

> Some of the concept from that work may be applicable here. 

I think so!  Except for the part about this spec being non-free.  I
think that means: start over in the IETF.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 11:51:44 -0500

On Fri, Apr 03, 2009 at 12:44:30PM -0400, Russ Housley wrote:
> I really do not have time to write about all of my 
> concerns.  However, once you get beyond the basic classifications, 
> the SPIF model breaks.  They are markings that are only to be known 
> to people that have the clearance for those markings, this leads to a 
> SPIF distribution nightmare, as a subset of the real SPIF must be 
> given out based on access (or not) to various compartments and 
> such.  It just does not scale.

I'm aware of the fact that labels can themselves be labeled.  But I
don't think that implies that we can't make a SPIF-like solution scale.

Peers that have access to different subsets of the policy should still
be able to interop if care is taken to specify what happens when a node
sees a label that falls outside its policy subset, and provided, of
course, that the peers can agree that they have subsets of the *same*
master policy.  Peers can check whether they do have subsets of the
*same* master policy by exchanging [for each DOI to both] a master
policy URI that includes a version number.

Nico
--

---

From: Shawn Campbell <[email-masked]>
Date: Fri, 3 Apr 2009 12:34:20 -0400

Similar activity with SILS 802.10 work involved SDE security labels.  Though that has been disbanded, some of that may be a help in this area.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Santosh Chokhani [[email-masked]]
Sent: Friday, April 03, 2009 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Common labeled security (comment on CALIPSO,        labeled NFSv4)

1.  It was ASN.1 based.

---

From: Russ Housley <[email-masked]>
Date: Fri, 03 Apr 2009 12:44:30 -0400

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Apr 2009 13:34:23 -0400

The work I am mentioning was done for NSA and can be released if NSA is
ok with it.

I suspect NSA will be ok with it. 

> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Friday, April 03, 2009 11:43 AM
> To: Santosh Chokhani
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Oh, very nice!  Thanks for the pointer.  That would be 
> ISO15816.  I've found the spec, though it's non-free (hadn't 
> they learned the lesson with ASN.1??  will they ever learn it??).
> 
> Not surprisingly :)  Converting that to XML is probably the 
> correct first step in order to ensure adoption, sadly.  
> (Actually, apparently that has already been done once, though 
> outside the ISO/ITU-T.)
> 
> > non-hierarchical categories) from one labeling policy to another 
> > (i.e., establish equivalency mapping) 5.  It allowed you to 
> constrain 
> > labels since for some policies, existence of a category may 
> mean some 
> > categories, levels, may be included and/or excluded.
> > 
> I think so!  Except for the part about this spec being 
> non-free.  I think that means: start over in the IETF.
> 
> Nico
> -- 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Apr 2009 13:36:17 -0400

Russ,

My thinking was that the features of SPIF that are not needed could be
discarded.

I was hoping that we could help the group save the baby and throw out
the bath water. 

> From: Russ Housley [mailto:[email-masked]] 
> Sent: Friday, April 03, 2009 12:45 PM
> To: Santosh Chokhani; [email-masked]
> I really do not have time to write about all of my concerns.  
> However, once you get beyond the basic classifications, the 
> SPIF model breaks.  They are markings that are only to be 
> known to people that have the clearance for those markings, 
> this leads to a SPIF distribution nightmare, as a subset of 
> the real SPIF must be given out based on access (or not) to 
> various compartments and such.  It just does not scale.
> 
> Russ
> 
> >establish equivalency mapping) 5.  It allowed you to 
> constrain labels 
> >since for some policies, existence of a category may mean some 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Nicolas Williams
> > > Subject: [saag] Common labeled security (comment on 
> CALIPSO, labeled 
> > > NFSv4)
> > >
> > > Over at the NFSv4 WG we've been having a discussion of a labeled 
> > > NFSv4 proposal.  [Note: NFSv4 WG and others cc'ed,
> > > Reply-To: set to SAAG.]
> > >
> > > An interop issue has arisen that we believe applies equally to 
> > > CALIPSO (draft-stjohns-sipso-11.txt)and requires input 
> from the IETF 
> > > security area.
> > >
> network/application know 
> > > if they agree on a common labeled security policy for a given DOI?
> > >
> > > Agreeing on what a given numeric sensitivity level or compartment 
> > > bit means in a given DOI is quite another.
> > > Without a solution to this we're left with out-of-band agreement, 
> > > which leaves interop in a lurch.
> > >
> > > document format that allows a DOI to define the names and numeric 
> > > assignments of sensitivity levels, compartments, etcetera.
> > >
> > > We also need a way for nodes to agree that they have the 
> same policy 
> > > for a given DOI, or that they agree on a common subset of a DOI's 
> > > policy.
> > >
> > > This last problem can be solved by use of a labeled 
> security policy 
> > > URI scheme that includes a version number (+ a requirement that 
> > > changes be in the form of additions and obsolescence of old 
> > > assignments, but not removals).
> > >
> security 
> > > policy document format, b) a labeled security policy URI 
> scheme to 
> > > refer to such documents by.
> > >
> > > exchange {DOI #, policy URI} tuples to determine whether 
> they agree 
> > > on a common policy.
> > >
> labels on 
> > > the wire, but it does not describe how nodes agree on the 
> meaning of

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Apr 2009 13:43:49 -0400

I am hoping that SPIF labeling in this community will either not be a
problem or if it is part of the labeling and MAC policy, SPIF is not the
only mechanism that is exacerbating it. 

> Sent: Friday, April 03, 2009 12:52 PM
> To: Russ Housley
> Cc: Santosh Chokhani; [email-masked]; 
> [email-masked]; [email-masked]; 
> concerns.  However, 
> > once you get beyond the basic classifications, the SPIF 
> model breaks.  
> > They are markings that are only to be known to people that have the 
> > clearance for those markings, this leads to a SPIF distribution 
> > nightmare, as a subset of the real SPIF must be given out based on 
> > access (or not) to various compartments and such.  It just does not 
> > scale.
> 
> I'm aware of the fact that labels can themselves be labeled.  
> But I don't think that implies that we can't make a SPIF-like 
> solution scale.
> 
> Peers that have access to different subsets of the policy 
> should still be able to interop if care is taken to specify 
> what happens when a node sees a label that falls outside its 
> policy subset, and provided, of course, that the peers can 
> agree that they have subsets of the *same* master policy.  
> Peers can check whether they do have subsets of the
> *same* master policy by exchanging [for each DOI to both] a 
> master policy URI that includes a version number.
> 
> Nico
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 12:36:55 -0500

> I suspect NSA will be ok with it. 

Great!

But I was referring to the ISO15816 spec -- that does not belong to the
NSA, though the NSA might be able to pull strings to make it a free
spec.  It took so long to make the ASN.1 specs free that I wouldn't hold
my breath.  I may be better for the IETF to start over on a replacement
for SPIF.

Nico
--

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Apr 2009 14:11:27 -0400

I do not know what the ISO spec has in it and how it relates to SPIF
work we did. 

> Sent: Friday, April 03, 2009 1:37 PM
> To: Santosh Chokhani
> > The work I am mentioning was done for NSA and can be 
> released if NSA 
> > is ok with it.
> > 
> But I was referring to the ISO15816 spec -- that does not 
> belong to the NSA, though the NSA might be able to pull 
> strings to make it a free spec.  It took so long to make the 
> ASN.1 specs free that I wouldn't hold my breath.  I may be 
> better for the IETF to start over on a replacement for SPIF.
> 
> Nico
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 14:18:38 -0500

> I do not know what the ISO spec has in it and how it relates to SPIF

It defines the ASN.1 module that you need to code to.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Apr 2009 14:57:05 -0500

On Fri, Apr 03, 2009 at 03:51:46PM -0400, Santosh Chokhani wrote:
> NSA document on SPIF also had ASN.1 module for SPIF.

Ah, good!  A link would be great.

> May be you can use the applicable concepts to get a head start on XML. 

If the ASN.1 module can be obtained freely then the XML follows
trivially (and, as I said, has already been done).

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Apr 2009 15:51:46 -0400

> Sent: Friday, April 03, 2009 3:19 PM
> To: Santosh Chokhani

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 4 Apr 2009 11:44:24 -0700

> I really do not have time to write about all of my concerns.

Understand.  It might be a long write-up!

> However, once you get beyond the basic classifications, the SPIF  
> model breaks.

I would say that the SPIF model discussed in SDN 801 has some  
significant limitations.  Dealing with the "black project" problem you  
allude to is certainly one of them.  Another is that the SPIF only  
describes authorization to access (e.g., read) an object (given the  
policy, the object's label, and the accessor's clearance).  It doesn't  
describes what labels an entity is allowed to use in labeling an  
object.  While one might assume that "right to read" implies a "right  
to label", this assumption is only useful in simple environments.  It  
cannot handle various national or international policies.

I do think there is a need to develop a SPIF replacement that  
addresses various limitations, and would be willing to provide input  
in such an effort.  However, it needs to be driven by key stakeholders.

Until there is a suitable SPIF replacement for labeling at the  
application level (e.g., Directory, email, XMPP), I'll continue to  
implement SPIF-based solutions as simply there simply ain't anything  
better policy-neutral solution (that I'm aware of)... and that's what  
my customers are asking for (as they find it useful in their use cases).

-- Kurt

---

From: Russ Housley <[email-masked]>
Date: Sat, 04 Apr 2009 14:39:29 -0400

Santosh:

There may be things that can be kept for this environment, especially 
if all of the clients of a particular file system are probably 
operating under a single security policy.  If you can eliminate 
policy mapping and markings that must be hidden from some clients, 
then a subset of the SPIF may be useful.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 4 Apr 2009 18:10:42 -0400

Russ,

I was thinking along the same lines.  More specifically,

1.  They can use he feature that helps covert machine representation to
human readable representation and vice versa.

2.  I suspect the distribution nightmare you mentioned and Kurt seconded
relates to label names being sensitive or aggregation of labels' names
being sensitive.  I hope this is not a problem in the environments they
mention in the sense that SPIF can be classified such that all users can
access it.

3.  They probably do not need the excluded and required features (i.e.,
they do not need to worry about some labels in the lattice being
semantically permitted).  This will simplify SPIF a lot.

4.  I am torn on the issue of mapping you mentioned.  At a minimum SPIF
can let them label the data for different labeling policies and do away
with the mapping as you suggest.  This may mean that subject may need
authorizations spelled out in multiple policy domains.  This approach
will get rid of one of your key concerns about complexity of SPIF.
Item 2 above hopefully addresses the other.

> Sent: Saturday, April 04, 2009 2:39 PM
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [saag] Common labeled security (comment on 
> CALIPSO, labeled NFSv4)
> 
> Santosh:
> 
> There may be things that can be kept for this environment, 
> especially if all of the clients of a particular file system 
> are probably operating under a single security policy.  If 
> you can eliminate policy mapping and markings that must be 
> hidden from some clients, then a subset of the SPIF may be useful.
> 
> Russ
> 
> > > model breaks.  They are markings that are only to be 
> known to people 
> > > that have the clearance for those markings, this leads to a SPIF 
> > > distribution nightmare, as a subset of the real SPIF must 
> be given 
> > > out based on access (or not) to various compartments and 
> such.  It 
> > > just does not scale.
> > >
> > > Russ
> > >
> > > > > Agreeing on a DOI is accomplished easily enough -- 
> that's not an 
> > > > > issue.
> > > > > for a given DOI, or that they agree on a common subset of a 
> > > > > DOI's policy.
> > > > >

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 4 Apr 2009 18:46:39 -0400

Kurt,

Thanks. 

On the issue of authorization to "label" an object, I assume you are not
saying that write authorizations need to be separate from read
authorization.  I suspect you are saying that since one may be providing
information to multiple parties operating under different policies, one
may need to label the information for each party.

SDN series took care of this by providing the subject clearance in X.509
certificate in the subject's policy domain.  These clearance checks are
made during message creation.

It is required that the SPIF in the recipient policy domain use the
equivalency mapping to enforce the access control, just like the subject
makes these checks in their domain.

To illustrate,

Let us say that subject A has clearance asserted in policy X and has a
SPIF that specifies policy X and maps policy X to Y.

Let us say that subject B has clearance asserted in policy Y and has a
SPIF that specifies policy Y and maps policy Y to X.

Now, under the reader to writer security model, the following should
occur:

1.  When A creates a message for B with label L, A's clearance under
policy X to create label L can be checked.  Also, B's clearance under
Policy Y can be converted to equivalent under Policy X using SPIF X.
Then, it can be determined if B is allowed to receive message with Label
L.

2.  B can do a mirror image of this when B receives the message.

This approach also fits nicely with the traditional subject, subject
clearance, object, object label, and MAC policy in the computer security
world.

Alternative means can be explored if SPIF equivalency is deemed overly
complex.

I hope once the alternative solutions are developed, their complexity
and SPIF complexity due to equivalency will be compared to determine
which solution is the best.

> From: Kurt Zeilenga [mailto:[email-masked]] 
> Sent: Saturday, April 04, 2009 2:44 PM
> To: Russ Housley
> SPIF model 
> > breaks.
> significant limitations.  Dealing with the "black project" 
> problem you allude to is certainly one of them.  Another is 
> that the SPIF only describes authorization to access (e.g., 
> read) an object (given the policy, the object's label, and 
> the accessor's clearance).  It doesn't describes what labels 
> an entity is allowed to use in labeling an object.  While one 
> might assume that "right to read" implies a "right to label", 
> this assumption is only useful in simple environments.  It 
> addresses various limitations, and would be willing to 
> provide input in such an effort.  However, it needs to be 
> driven by key stakeholders.
> 
> Until there is a suitable SPIF replacement for labeling at 
> the application level (e.g., Directory, email, XMPP), I'll 
> continue to implement SPIF-based solutions as simply there 
> simply ain't anything better policy-neutral solution (that 
> I'm aware of)... and that's what my customers are asking for 
> (as they find it useful in their use cases).
> 
> -- Kurt
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 4 Apr 2009 16:00:36 -0700

On Apr 4, 2009, at 3:46 PM, Santosh Chokhani wrote:
> authorization.

No, I am saying the lack of separate "to read"/"to label"  
authorizations is a significant limitation of the SDN SPIF model.  For  
instance, one might not require any particular clearance to read  
UNCLASSIFIED//RELEASEABLE-TO-PUBLIC under a particular policy, but  
under that policy one might be required a specific clearance to create  
an object with a UNCLASSIFIED//RELEASEABLE-TO-PUBLIC label.  (There  
are a number of real world national/international policies that have  
asymmetric "to read"/"to label" handling of security labels.)  The SDN  
SPIF model, unfortunately, assumes that authorization to read implies  
authorization to label, so one cannot represent such a policy in a SPIF.

-- Kurt

---

From: Sean Turner <[email-masked]>
Date: Sat, 04 Apr 2009 21:28:02 -0400

Nico,

I usually try to find the corresponding ITU spec because I think ITU 
gives out all of it's ASN.1 modules freely?  Anyway, here's a link to 
the ITU-T X.841 Spec:
http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html

The one thing that's missing from the module is definitions for security 
categories.  Some suggested categories were defined in Annex B, but it's 
an informative annex so there's no ASN.1 freely available (they wouldn't 
allow them in the normative text/module).  Those categories are based on 
FIPS 188 (the syntax is not the same).

Note that some of the syntax for labels has made it's way to some 
IDs/RFCs notably RFC 2634.

spt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 5 Apr 2009 08:01:06 -0400

Nico,

The link provided by Sean should help you quite a bit.

The main module leaves up to you to define the semantics of categories
and their interactions.  (May be this is consistent with what Russ is
saying about categories adding excessive complexity)

I did not look at other modules to see if they define categories any
further. 

> From: Sean Turner [mailto:[email-masked]] 
> Sent: Saturday, April 04, 2009 9:28 PM
> To: Nicolas Williams
> Cc: Santosh Chokhani; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> I usually try to find the corresponding ITU spec because I 
> think ITU gives out all of it's ASN.1 modules freely?  
> Anyway, here's a link to the ITU-T X.841 Spec:
> The one thing that's missing from the module is definitions 
> for security categories.  Some suggested categories were 
> defined in Annex B, but it's an informative annex so there's 
> no ASN.1 freely available (they wouldn't allow them in the 
> normative text/module).  Those categories are based on FIPS 
> 188 (the syntax is not the same).
> 
> Note that some of the syntax for labels has made it's way to 
> some IDs/RFCs notably RFC 2634.
> 
> spt
> 
> Nicolas Williams wrote:

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 6 Apr 2009 07:03:32 -0400

Kurt,

Good point.

This capability should not impact SPIF.  The capability to read Vs.
assert should impact the clearance structure and the companion access
control decision function.

I view SPIF as performing the following functions: converting machine to
human representation and vice versa; establishing equivalency between
two labeling policies, and defining which labels with the lattice are
valid and which are invalid.

> Sent: Saturday, April 04, 2009 7:01 PM
> To: Santosh Chokhani
> Cc: Russ Housley; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> > On the issue of authorization to "label" an object, I 
> assume you are 
> > not saying that write authorizations need to be separate from read 
> > authorization.
> 
> authorizations is a significant limitation of the SDN SPIF 
> model.  For instance, one might not require any particular 
> clearance to read UNCLASSIFIED//RELEASEABLE-TO-PUBLIC under a 
> particular policy, but under that policy one might be 
> required a specific clearance to create an object with a 
> UNCLASSIFIED//RELEASEABLE-TO-PUBLIC label.  (There are a 
> number of real world national/international policies that 
> have asymmetric "to read"/"to label" handling of security 
> labels.)  The SDN SPIF model, unfortunately, assumes that 
> authorization to read implies authorization to label, so one 
> cannot represent such a policy in a SPIF.
> 
> -- Kurt
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 10:16:06 -0500

> valid and which are invalid.

If I understand Russ' comment correctly the difficulty with SPIF lies in
the label equivalency concept.  I think there's a better solution for
dealing with the idea that parts of a policy are classified differently
than others.

Nico
--

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 6 Apr 2009 11:51:38 -0400

Nico,

Either you need equivalency or not.

If you do not, that part of SPIF can be stripped off.

If you do need one, the complexity, scalability, and interoperability of
other alternatives should be assessed against SPIF approach.

(We want to compare apples to apples) 

> Sent: Monday, April 06, 2009 11:16 AM
> To: Santosh Chokhani
> Cc: Kurt Zeilenga; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> > I view SPIF as performing the following functions: 
> converting machine 
> > to human representation and vice versa; establishing equivalency 
> > between two labeling policies, and defining which labels with the 
> > lattice are valid and which are invalid.
> 
> If I understand Russ' comment correctly the difficulty with 
> SPIF lies in the label equivalency concept.  I think there's 
> a better solution for dealing with the idea that parts of a 
> policy are classified differently than others.
> 
> Nico
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 10:11:01 -0500

> http://www.itu.int/ITU-T/asn1/database/itu-t/x/x841/2000/index.html

Thanks.  I'm sure the spec needs to be read too, not just the ASN.1
module (it's mostly self-evident, but some types, like
LabelAndCertValue, require an explanation).

> IDs/RFCs notably RFC 2634.

Thanks.  That's very useful.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 11:22:26 -0500

> other alternatives should be assessed against SPIF approach.

Indeed.  I think, however, that it will be necessary to support policies
parts of which are classified differently from each other.  It'd be nice
to be able to get rid of such a complication.

But you can see why this is needed.  Remember that during WWII very few
people on the Allied side knew about some of the cryptanalysis efforts
being made, and, IIRC, all such information was classified as "Ultra"
and no one who didn't have Ultra clearance was allowed to know that
Ultra existed (presumably because public knowledge of such a
classification might have caused the enemy to wonder).

Today the names and existence of specific compartments rather than
specific sensitivity level, are likley to be the cause of thie
requirement.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 13:10:53 -0500

On Mon, Apr 06, 2009 at 01:50:32PM -0400, Russ Housley wrote:
> No.  They are two separate concerns.
> 
> Mapping labels between two different policies.  Hopefully this can be 
> avoided altogether in the NFS context.

There should be no impact from this on NFS.  If a server is able to map
some labels between multiple distinct DOIs, so much the better for it,
but that would be an implementation detail.

Making it possible to express label equivalencies is not an
implementation detail.  But it's also not a detail we should care about
in the context of NFSv4, whereas security policy agreement _is_
something that we should care about in the context of NFSv4.

> Some label values are not releasable to clients that do not have 
> access to data associated with that label.  This one is a real-world 
> problem, and it leads to different clients having different subsets 
> of the SPIF if this community that is being supported has this 
> requirement in their policy.

Right, that's what I meant, but I had misunderstood "label equivalency"
as being related (d'oh).  This is a problem that we must deal with to
the extent that it impacts how a client and server determine that they
agree on a common security policy.

Nico
--

---

From: Casey Schaufler <[email-masked]>
Date: Mon, 06 Apr 2009 20:03:57 -0700

Russ Housley wrote:
> ...

I don't think so. Two SELinux machines will most likely have different
policies even if they installed from the same media on similar hardware
with similar configurations. If there's any reason for the NFS server
to know anything about the client that impacts policy enforcement the
server has to know enough to make that judgment correctly. If the server
can ignore the client's policy there is no need to send any information.
If the server can't ignore the client's policy it needs to be able to
reconcile the local policy to the remote policy in order to enforce
reasonable policy.

The problem is that the server is using client subject information
to enforce policy based on server object information. If the policies
are similar (e.g. two Bell & LaPadula MLS systems) enforcement is
merely difficult because the two system may have different values for
what means "UNCLASSIFIED". For an SELinux system and an MLS system
to work you've got much more on your hands than matching up category
bits. If you don't do so however you can not make an access control
decision based on the information passed from the other side that can
possibly make sense.

You could decide that the server should enforce server policy and
require that the client enforce client policy and hope that between
the two nothing leaks out that you really care about. I seriously
doubt that's what you want.

So you're back to mapping policies. You have to map policies if you
want either side to do all the work. The mechanisms used to map
labels used by different installations of the same 1990's MLS systems
will not work for SELinux systems installed for different purposes by
disjoint agencies.

I'm not trying to stop progress here. I am simply trying to point out
that choosing a mechanism to implement a facility that won't work in
the end is pretty pointless. Sure the old schemes worked in certain
cases in the olden days. The question is will they work now, and the
answer is obviously "no".

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 7 Apr 2009 12:20:48 -0400

One of looking at what Russ is saying is:

1.  See if you can avoid security policy mapping, e.g., define a Common
Extensible labeling Policy.

2.  See if you can live without non-hierarchical security categories,
since their very introduction brings in complexity.

3.  See if you can live with only the hierarchical sensitivity levels
mapping and without categories mapping.  If the answer to 1 and 2 is no,
the answer to this is likely to be no also.

4.  See if you need to invalidate all the possible labels in the
lattice.

5.  Use the answers to 1 through 4 to tailor the SPIF.

6.  See if you can achieve the same functionality using simpler
paradigm.

> From: Casey Schaufler [mailto:[email-masked]] 
> Sent: Monday, April 06, 2009 11:04 PM
> To: Russ Housley
> Cc: Nicolas Williams; Santosh Chokhani; [email-masked]; 
> [email-masked]; Kurt Zeilenga; 
> [email-masked]; [email-masked]; Casey Schaufler
> Subject: Re: [Labeled-nfs] [saag] Common labeled security 
> (comment on CALIPSO, labeled NFSv4)
> 
> Russ Housley wrote:
> > ...
> >
> I don't think so. Two SELinux machines will most likely have 
> different policies even if they installed from the same media 
> on similar hardware with similar configurations. If there's 
> any reason for the NFS server to know anything about the 
> client that impacts policy enforcement the server has to know 
> enough to make that judgment correctly. If the server can 
> ignore the client's policy there is no need to send any information.
> If the server can't ignore the client's policy it needs to be 
> able to reconcile the local policy to the remote policy in 
> order to enforce reasonable policy.
> 
> The problem is that the server is using client subject 
> information to enforce policy based on server object 
> information. If the policies are similar (e.g. two Bell & 
> LaPadula MLS systems) enforcement is merely difficult because 
> the two system may have different values for what means 
> "UNCLASSIFIED". For an SELinux system and an MLS system to 
> work you've got much more on your hands than matching up 
> category bits. If you don't do so however you can not make an 
> access control decision based on the information passed from 
> the other side that can possibly make sense.
> 
> You could decide that the server should enforce server policy 
> and require that the client enforce client policy and hope 
> that between the two nothing leaks out that you really care 
> about. I seriously doubt that's what you want.
> 
> So you're back to mapping policies. You have to map policies 
> if you want either side to do all the work. The mechanisms 
> used to map labels used by different installations of the 
> same 1990's MLS systems will not work for SELinux systems 
> installed for different purposes by disjoint agencies.
> 
> I'm not trying to stop progress here. I am simply trying to 
> point out that choosing a mechanism to implement a facility 
> that won't work in the end is pretty pointless. Sure the old 
> schemes worked in certain cases in the olden days. The 
> question is will they work now, and the answer is obviously "no".
> 
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Apr 2009 11:44:21 -0500

> reconcile the local policy to the remote policy in order to enforce

We can have label-aware servers with non-label-aware protocols.  But
that's too constraining: it means clients have to be at a single label
or otherwise communicate labels by convention (e.g., data location).  It
also means that interfaces to labeling will be proprietary.

We can have non-label-aware server, non-label-aware protocols, and label
aware clients, trusting the clients to enforce a common policy.  But
this too is too constraining: a) it forces one to associate labels with
document _location_, b) it forces one to trust the clients too much.

We need multi-level clients, since many users will have a
range of clearances, not just a single one (and they need a trusted
desktop).

Given the above then we need label-aware servers and label-aware
protocols so as to support for multi-level clients (with clients trusted
to within a range of labels associated with clients' and users'
authenticated identities and other authorization information).

Even before putting labels on the wire we'd have a security policy
management issue since storage can span many servers.

With labels appearing on the wire (in IP headers, in application
protocols, in PKIX certificate extensions and Kerberos V authorization-
data, ...) we simply cannot avoid the need to express common security
policies.  We also cannot force everything and everyone to operate in a
single DOI.  And we cannot avoid the need to classify the security
policies themselves, including varying classification for different
subsets of the policies.

IMO that means that we need something like SPIF, including:

 - a generic security policy data model/syntax
 - an interoperable encoding of security policies
 - a method by which two peers can detect and agree that they know a
   given common subset of a common security policy
 - label equivalencies

The last item is the least critical -- we can deal with that later.

> want either side to do all the work. The mechanisms used to map

Yes.

> will not work for SELinux systems installed for different purposes by

That's fine, unless you want them to interop and you can establish
equivalencies.  And provided SELinux can deal -- but that's less
important because if it's just a small matter of programming (i.e., we
have specs to code to or know what to code that we can write specs
from) then it's just a matter of time.

So we need to know whether solutions in this space are technically
feasible.  I believe they are.  (We also need to know whether they are
politically feasible, but here I think we'll find that they are
politically required :)

> the end is pretty pointless. Sure the old schemes worked in certain

No one is knowingly proposing a mechanism that won't work so far as I
can tell.

---

From: Casey Schaufler <[email-masked]>
Date: Tue, 07 Apr 2009 20:02:50 -0700

> The last item is the least critical -- we can deal with that later.

Wow.

Before I go too far, how familiar are you with MLS, SELinux, or Smack?
All three provide general security policy models (Opinions vary on MLS)
but none would lend themselves as a "generic" model. MLS is strictly
oriented toward sensitivity, SELinux depends on the programs installed
on the machine, and Smack uses no syntax in its labels at all. An
interoperable encoding of policies might be possible for very limited
policies. I suggest that mapping any other policy to the SELinux
reference policy is beyond the state of the art, and I welcome an
informed argument that proves me wrong. Two peers negotiating a
policy subset? How does that help? Regarding the notion that the issue
of label equivalences is "least critical", I don't see how you can
claim to have successfully addressed any of the other bullet items
without it.

You're busy stocking the nursery and you haven't kissed the girl yet.

If the information from the client is meaningless to the server the
server can not use it to make an access control decision. Same goes
the other way. With Smack I can assert that the label space for the
client and server are the same and that it's OK if they use the labels
passed around even if their rule sets differ. I know a good number of
people who would find such an assertion dangerous, maybe even
criminal. Label representations are meaningless without the policy
behind them and mapping policies is hard enough that you could probably
get a PHD from a reputable institution by measuring just how hard it
is.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Apr 2009 00:17:45 -0500

> Before I go too far, how familiar are you with MLS, SELinux, or Smack?

I'm familiar with Solaris TX (which is MLS).  I'm also familiar with the
OpenSolaris community that is trying to extend the TX model to include
DTE.  I don't know much at all about SELinux or Smack.

I think common security policies for MLS are within reach.  DTE... not
so much.  Some subsets of specific DTE policies, probably on a
per-application basis, should be.

> informed argument that proves me wrong. Two peers negotiating a

IIUC it should be possible to generate SELinux policies from generic
ones, but not the reverse.  If so then that provides a path to
interoperable deployment, though it would mean sacrificing some
flexibility.  Can you clarify my understanding?

> claim to have successfully addressed any of the other bullet items

Why send data at some label to a peer who doesn't understand what that
label is?

As for label equivalencies I was referring to the example cited earlier
of multiple agencies with different MLS policies needing to communicate.
To clarify: by "less critical" I meant that we could solve the
equivalency problem later (provided we don't paint ourselves into any
corners).

Thanks.

> the other way. With Smack I can assert that the label space for the

Therein lies the interop problem.  Will SELinux and Solaris TX interop
with the labeled NFSv4 protocol we're working on?  Evidently: not w/o
policy agreement (that was Jarret's point, which kick-started this
thread on the NFSv4 WG list).

> criminal. Label representations are meaningless without the policy

So you're saying that a) "a good number of people" think a solution is
needed that allows the client and server to each know with certainty
that the other will understand their labels, b) you're among those
people (?), but c) no solution is feasible.  Correct?

So close up shop, forget interop?  Or did I misunderstand you?  What is
the message that you're imparting here?  I get the impression that it's
"you can't solve this problem" and "I know what I'm doing" (and "you
don't") but you're not telling us what it is that is.  Is what you
really mean "forget labeled protocol interop"?  Please clarify.

> get a PHD from a reputable institution by measuring just how hard it

I'm not interested in a PhD.  I'm interested in solutions.  SPIF is
evidence that it's been tried.  But I know little about how successful
SPIF has been.

Nico
--

---

From: James Morris <[email-masked]>
Date: Wed, 8 Apr 2009 20:45:06 +1000 (EST)

> thread on the NFSv4 WG list).

I don't know about TX, but it seems possible that someone might want to 
make SELinux with an MLS policy interoperate with a different MLS platform 
(note that this would not apply in the case of interop with purely legacy 
systems, as they won't have NFSv4.x support).  I have no idea how likely 
this scenario is, and I wouldn't try to accommodate this goal in the 
protocol unless a stakeholder could make a solid case for it.

Note that we should expect interoperability between Solaris FMAC and 
SELinux (i.e. the same security model implemented on different platforms, 
like Unix DAC).

- James
-- 
James Morris
<[email-masked]>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 Apr 2009 07:19:44 -0400

SPIF has been successfully implemented and used. 

> Sent: Wednesday, April 08, 2009 1:18 AM
> To: Casey Schaufler
> Cc: Russ Housley; Santosh Chokhani; [email-masked]; 
> I'm familiar with Solaris TX (which is MLS).  I'm also 
> familiar with the OpenSolaris community that is trying to 
> extend the TX model to include DTE.  I don't know much at all 
> about SELinux or Smack.
> 
> I think common security policies for MLS are within reach.  
> DTE... not so much.  Some subsets of specific DTE policies, 
> probably on a per-application basis, should be.
> 
> > All three provide general security policy models (Opinions vary on 
> > MLS) but none would lend themselves as a "generic" model. MLS is 
> > strictly oriented toward sensitivity, SELinux depends on 
> the programs 
> > installed on the machine, and Smack uses no syntax in its labels at 
> > all. An interoperable encoding of policies might be 
> possible for very 
> > limited policies. I suggest that mapping any other policy to the 
> > SELinux reference policy is beyond the state of the art, 
> and I welcome 
> > an informed argument that proves me wrong. Two peers negotiating a
> 
> IIUC it should be possible to generate SELinux policies from 
> generic ones, but not the reverse.  If so then that provides 
> a path to interoperable deployment, though it would mean 
> sacrificing some flexibility.  Can you clarify my understanding?
> 
> Why send data at some label to a peer who doesn't understand 
> what that label is?
> 
> As for label equivalencies I was referring to the example 
> cited earlier of multiple agencies with different MLS 
> policies needing to communicate.
> To clarify: by "less critical" I meant that we could solve 
> the equivalency problem later (provided we don't paint 
> ourselves into any corners).
> 
> Therein lies the interop problem.  Will SELinux and Solaris 
> TX interop with the labeled NFSv4 protocol we're working on?  
> Evidently: not w/o policy agreement (that was Jarret's point, 
> which kick-started this thread on the NFSv4 WG list).
> 
> So you're saying that a) "a good number of people" think a 
> solution is needed that allows the client and server to each 
> know with certainty that the other will understand their 
> labels, b) you're among those people (?), but c) no solution 
> is feasible.  Correct?
> 
> So close up shop, forget interop?  Or did I misunderstand 
> you?  What is the message that you're imparting here?  I get 
> the impression that it's "you can't solve this problem" and 
> "I know what I'm doing" (and "you
> don't") but you're not telling us what it is that is.  Is 
> what you really mean "forget labeled protocol interop"?  
> Please clarify.
> 
> > behind them and mapping policies is hard enough that you could 
> > probably get a PHD from a reputable institution by 
> measuring just how 
> > hard it is.
> 
> I'm not interested in a PhD.  I'm interested in solutions.  
> SPIF is evidence that it's been tried.  But I know little 
> about how successful SPIF has been.
> 
> Nico
> -- 
>

---

From: Casey Schaufler <[email-masked]>
Date: Wed, 08 Apr 2009 09:11:00 -0700

> per-application basis, should be.

The 1990's MLS solutions used labels that described sensitivity
levels and category sets. There was variation on exactly how
these were represented, some used fixed size bit maps, others
arrays of category numbers, but the information they contain is
a complete description of the information required to make an
access control decision. Unfortunately to the task at hand, MLS
is a technology that has seen its last development efforts.

The SELinux label, whose textual representation is called a "context",
contains enough information for the system on which it was generated
to interpret it relative to the system policy. It does not contain
sufficient information for a system that does understand that policy
to make decisions based on that context. For a context generated on
Stephen's machine to be meaningful on David's David's machine would
need a full understanding of both policies. Last I looked the
SELinux reference policy was approaching a million lines. Based on
the many interrelationships between policy elements, I do not
think that subsetting is going to be viable, although I'm willing
to be educated on that.

In some ways Smack is even worse. The Smack label contains no
actual information, it is just a character string and the access
control is left completely up to the access control rules specified
on the system. A Smack label from Etienne's system has no intrinsic
value on Casey's and give no hint as to how it should be interpreted
or enforced.

Summary: Old MLS systems passed sufficient information in their
labels for any number of mechanisms including SPIF, CIPSO, TSIX,
and IPSEC to be useful. 21st century MAC systems, including
SELinux and Smack, have labels that do not contain sufficient
information for another system to make an access control decision.

> flexibility.  Can you clarify my understanding?

An SELinux policy can be created from scratch, and we're seeing some
people in the embedded space trying to do just that. Sure, you can
limit the problem by constraining the variation of the policies, but
as we type the reference policy continues to be refined and expanded.
I'm not going to tell Joshua that he has to slow policy development
in support of NFS.

> equivalency problem later (provided we don't paint ourselves into any

Let's see if I can be clear for a change. (smiley here)

You are 100% correct. There is no point in sending a label to someone
who can't understand it.

You are also correct that in the case of MLS, where the label contains
sufficient information to make an access control decision, perhaps
after some amount of translation, label equivalence is a problem that
shouldn't require all that much work. Industry experience from the
1990's backs you up.

> thread on the NFSv4 WG list).

Again, you are correct. Jarret is correct.

The assumption that policy agreement can be assumed is inappropriate.

> people (?), but c) no solution is feasible.  Correct?

a) Else there's no point to labeled NFS.
b) Yup.
c) It is not feasible to meet "a" using just the information contained
   in either an SELinux context or a Smack label, regardless of how
   the information is transmitted between the client and server. You
   can meet "a" for 20th century MLS systems using just the information
   contained in the MLS label.

> So close up shop, forget interop?

Nope.

>   Or did I misunderstand you?  

I can see how you might come to your conclusions, sorry about being obtuse.

> What is
> the message that you're imparting here?  

The systems we created in an effort to appease "C2 in '92" were very
different from the systems we're using now. The interoperability
problem is not the same, and the mechanisms from the MLS era will
not address the interoperability issues, although they could be a
minor part of the end solution.

> I get the impression that it's
> "you can't solve this problem"

Sure you can. My concern is that y'all are looking at the issue as
a rehash of an MLS implementation, and it is much bigger than that.

>  and "I know what I'm doing" (and "you

No. I do have a bit of experience in the field, including close
involvement with CIPSO, three different implementations of labeled NFS
(SunOS/MLS, and two for Trusted Irix) and TSIG throughout its life,
but in no way would I claim to be an expert on the right way to do
protocols. I do understand Mandatory Access Control systems, and I
do see that the discussion to date is missing an element that is key
to the problem at hand.

> evidence that it's been tried.  But I know little about how successful

I do not deny that SPIF (or CIPSO, or TSIX) has been successful for
the problem it was designed to solve. This is not the same problem.
I hope I've clarified the difference between the problem of MLS systems
and the problem of our current set of technologies.

Thank you.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Apr 2009 10:43:29 -0500

> protocol unless a stakeholder could make a solid case for it.

Well, here at the IETF we do like to have interoperable protocols.  We
ought to at least try.

> SELinux (i.e. the same security model implemented on different platforms, 

OK.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 Apr 2009 12:37:27 -0400

If the label from a system does not carry the policy associated with the
label, could the policy not be construed from the authenticated system
identity.

Not an ideal solution and will have issues, but is doable.

> Sent: Wednesday, April 08, 2009 12:11 PM
> To: Nicolas Williams
> familiar with 
> > the OpenSolaris community that is trying to extend the TX model to 
> > include DTE.  I don't know much at all about SELinux or Smack.
> >
> DTE... not 
> The 1990's MLS solutions used labels that described 
> sensitivity levels and category sets. There was variation on 
> exactly how these were represented, some used fixed size bit 
> maps, others arrays of category numbers, but the information 
> they contain is a complete description of the information 
> required to make an access control decision. Unfortunately to 
> the task at hand, MLS is a technology that has seen its last 
> development efforts.
> 
> The SELinux label, whose textual representation is called a 
> "context", contains enough information for the system on 
> which it was generated to interpret it relative to the system 
> policy. It does not contain sufficient information for a 
> system that does understand that policy to make decisions 
> based on that context. For a context generated on Stephen's 
> machine to be meaningful on David's David's machine would 
> SELinux reference policy was approaching a million lines. 
> Based on the many interrelationships between policy elements, 
> I do not think that subsetting is going to be viable, 
> although I'm willing to be educated on that.
> 
> actual information, it is just a character string and the 
> access control is left completely up to the access control 
> rules specified on the system. A Smack label from Etienne's 
> system has no intrinsic value on Casey's and give no hint as 
> to how it should be interpreted or enforced.
> 
> Summary: Old MLS systems passed sufficient information in 
> their labels for any number of mechanisms including SPIF, 
> CIPSO, TSIX, and IPSEC to be useful. 21st century MAC 
> systems, including SELinux and Smack, have labels that do not 
> contain sufficient information for another system to make an 
> access control decision.
> 
> >> SELinux reference policy is beyond the state of the art, and I 
> >> welcome an informed argument that proves me wrong. Two peers 
> >> negotiating a
> >>     
> >
> An SELinux policy can be created from scratch, and we're 
> seeing some people in the embedded space trying to do just 
> that. Sure, you can limit the problem by constraining the 
> variation of the policies, but as we type the reference 
> policy continues to be refined and expanded.
> I'm not going to tell Joshua that he has to slow policy 
> development in support of NFS.
> 
> >> policy subset? How does that help? Regarding the notion that the 
> >> issue of label equivalences is "least critical", I don't 
> see how you 
> >> can claim to have successfully addressed any of the other bullet 
> >> items without it.
> >>     
> >
> > As for label equivalencies I was referring to the example cited 
> > earlier of multiple agencies with different MLS policies 
> needing to communicate.
> You are 100% correct. There is no point in sending a label to 
> someone who can't understand it.
> 
> You are also correct that in the case of MLS, where the label 
> contains sufficient information to make an access control 
> decision, perhaps after some amount of translation, label 
> equivalence is a problem that shouldn't require all that much 
> work. Industry experience from the 1990's backs you up.
> 
> TX interop 
> >> client and server are the same and that it's OK if they use the 
> >> labels passed around even if their rule sets differ. I know a good 
> >> number of people who would find such an assertion dangerous, maybe 
> >> even criminal. Label representations are meaningless without the 
> >> policy
> >>     
> >
> solution is 
> The systems we created in an effort to appease "C2 in '92" 
> were very different from the systems we're using now. The 
> interoperability problem is not the same, and the mechanisms 
> from the MLS era will not address the interoperability 
> issues, although they could be a minor part of the end solution.
> 
> Sure you can. My concern is that y'all are looking at the 
> issue as a rehash of an MLS implementation, and it is much 
> bigger than that.
> 
> No. I do have a bit of experience in the field, including 
> close involvement with CIPSO, three different implementations 
> of labeled NFS (SunOS/MLS, and two for Trusted Irix) and TSIG 
> throughout its life, but in no way would I claim to be an 
> expert on the right way to do protocols. I do understand 
> Mandatory Access Control systems, and I do see that the 
> discussion to date is missing an element that is key to the 
> problem at hand.
> 
> I do not deny that SPIF (or CIPSO, or TSIX) has been 
> successful for the problem it was designed to solve. This is 
> not the same problem.
> I hope I've clarified the difference between the problem of 
> MLS systems and the problem of our current set of technologies.
> 
> 
> Thank you.
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Apr 2009 16:12:09 -0500

> is a technology that has seen its last development efforts.

But has MLS seen its last days for deployment?  I think that for generic
non-governmental agency deployment you're quite right that MLS is barely
sufficient.  DTE is needed.

Incidentally, I should clarify that in the context of labeled NFS I only
care to solve the sub-problem of how the client and server can determine
what policy or subset thereof they share.  I currently think that's a
simpler problem than how to represent policies (and equivalencies), but
only if we also assume a solution that.

> think that subsetting is going to be viable, although I'm willing

I'm still learning about DTE.  If I understand correctly though we could
constrain ourselves to administrator defined policies built on system-
and vendor-defined types/roles.  If so then DTE policy subset agreement
seems within reach.

> value on Casey's and give no hint as to how it should be interpreted

Ouch.

> information for another system to make an access control decision.

Jarret's point was that this is true even for MLS labels because a node
might not know what the meaning of a given sensitivity and compartment
are.  This is not a problem for CALIPSO because middle boxes need only
determine label dominance, but Jarret thinks that this is a problem for
NFS.

> I'm not going to tell Joshua that he has to slow policy development

I see.  This is important knowledge.  I'm not sure what can be done
about that.

> Let's see if I can be clear for a change. (smiley here)

:)

> The assumption that policy agreement can be assumed is inappropriate.

I think you're very likely right about that w.r.t. DTE.  But I still
harbor some hope.

>    contained in the MLS label.

Crystal clear.  Thanks.

> and the problem of our current set of technologies.

You have.  Thanks!

I'll need to think about the DTE issues, and SELinux vs. Solaris FMAC.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 08 Apr 2009 15:41:55 -0700

> and vendor-defined types/roles.  If so then DTE policy subset agreement
It's not clear to me how much information is sufficient to guarantee a 
subset of policy is consistent so that labeled communication is safe and 
correct. One extreme is to require systems to be configured identically. 
As I understand it, roles/types on DTE systems usually depend on what 
kind of applications are run on the systems, and the types are defined 
to constrains what the applications can do on a system. In other words, 
policy on different systems are most likely different.

> determine label dominance, but Jarret thinks that this is a problem for

I believe this is a problem for MLS end systems (client and server), 
even when CALIPSO is in use. If labels are defined differently on 
different systems, e.g. same binary bit patten on two different systems 
maps to different labels, label comparison is meaningless. The 
underlying assumption is that if two systems use different label mapping 
schemes, they should not be using the same DOI to communicate without 
some sort of translation mechanism. The agreement of associating a DOI 
with a particular label mapping is done outside of a protocol option 
such as CIPSO (for IPv4) or CALIPSO (for IPv6). Just to be clear, 
CALIPSO spec defines "on-the-wire" format of (MLS) sensitivity label 
option for IPv6. It is not designed to communicate policy agreements 
among systems.

Jarrett

---

From: James Morris <[email-masked]>
Date: Thu, 9 Apr 2009 09:26:28 +1000 (EST)

> > value on Casey's and give no hint as to how it should be interpreted

It's not a new problem.  On a standard DAC Unix system, what does 'admin' 
mean as the owner of a file?

The reason why labeling protocols were so simple for MLS was that the 
security policy was fixed.  This is also why MLS is useless for most 
people and why we now have TE.

- James
-- 
James Morris
<[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Apr 2009 17:47:55 -0500

> policy on different systems are most likely different.

Right, but presumably applications using NFS can be made to have
identical sub-policies on all relevant NFS clients and servers.  If not
then why use NFS for such an application?  Of course, there's the matter
of home directories and random apps loaded on clients without server
knowledge, but if you're using labeled NFS then presumably you have an
infrastructure and site-/org-wide system administration that can ensure
orderly application deployment.

> option for IPv6. It is not designed to communicate policy agreements 

Based on this I think I'm ready to conclude that for MLS we don't need
anything more than the DOI number/name to produce MLS policy agreement,
though a URI scheme for naming policies (including version) would have
better semantics.  DTE does not seem as simple, though assuming common
per-app sub-policies then it may be doable.

Nico
--

---

From: Casey Schaufler <[email-masked]>
Date: Wed, 08 Apr 2009 18:04:40 -0700

Nicolas Williams wrote:
> identical sub-policies on all relevant NFS clients and servers.

I do not believe that you can make that assumption with SELinux.

> If not
> then why use NFS for such an application?  

That is a very good question.

> Of course, there's the matter

That's quite an assumption.

> better semantics.  

MLS is an easier problem to solve, unfortunately it is a technology
that has fallen off the roadmap.

> DTE does not seem as simple, though assuming common

If you can create an uber-policy that can be shown to
incorporate all the aspects of both the client policy and
the server policy, one case of which being either the client
policy or the server policy being a sub-set of the other,
you may have a chance.

Each policy is a million lines.

---

From: Russ Housley <[email-masked]>
Date: Mon, 06 Apr 2009 13:50:32 -0400

Russ