Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2009-03-27 at 11:56 -0700, Jarrett Lu wrote:
> Nicolas Williams wrote:
> > On Fri, Mar 27, 2009 at 10:03:35AM -0700, Jarrett Lu wrote:
> >   
> >> I agree with your statements on TE vs. MLS/BLP. The problem we try to 
> >> solve is whether a DOI field + an opaque string is sufficient to solve 
> >> the interoperability problem. My opinion is that it's insufficient as it 
> >> doesn't take the "how to interpret MAC attribute agreement among all 
> >> communicating peers" into account. The current proposal seems to assume 
> >> when a node sees a DOI value of 5, it knows how to interpret the opaque 
> >> field. This may not be true. In MLS, one also needs to know which agreed 
> >> upon label encoding file to use in order to interpret label in the 
> >> opaque filed. I believe the same is true for TE -- one needs to know the 
> >> security policy being used in order to correctly interpret security 
> >> context string in the opaque field. DOI + opaque field doesn't say which 
> >> label encoding scheme or which security policy.
> >>     
> >
> > What would you add or remove on the wire to solve this problem?  My
> > guess: a registry of per-DOI rules, like CALIPSO does.  I don't think a
> > registry of DOI rules is strictly necessary for NFS (though I can see
> > how it helps in the case of IP), but I certainly don't object.
> >   
> 
> I don't yet see a good way to solve this problem using bits on the wire. 
> The agreement on what label encodings or security policy to use seems 
> better solved in an out of band manner. For example, on a (secure) 
> website, you can say "download this label encoding file or configure 
> your MAC system with this policy and use DOI number 5. Then we can talk".
> 
> BTW, CALIPSO with IP module has the same issue. While the spec talks a 
> lot about how a CALIPSO  system should behave, CALIPSO can't tell its 
> peers to use a particular label encoding. That's done outside CALIPSO.
> 
> I believe it's still worthwhile to request adding a DOI + an opaque 
> field in NFSv4 protocol. The spec should be clear that other 
> arrangements need to be made before interoperability can take place.
> 
> Once we decouple DOI from how the opaque field should be interpreted, 
> it's possible for NFSv4 to use CALIPSO DOI. For example, DOD can reserve 
> DOI 1000 through 1005. It can then decide that 1000 is only used by MLS 
> systems with a particular label encoding; and 1004 is for TE systems 
> configured with a particular secular security policy. As long as all 
> systems using these DOIs agreeing to that, they can communicate with 
> each other. But the agreement happens outside NFSv4 protocol itself. I 
> understand this is different from the public internet where all you need 
> is an IP address to communicate. But this is how MAC systems are used, I 
> believe.

I'm not sure if this conflicts with what you are saying, but the DOI
should merely identify the (externally) agreed-upon network label space
for the data to be shared between the communicating systems.  That label
space shouldn't need to be identical to the native/host label spaces of
any of the individual systems; they just need to have a way of mapping
between their host label spaces and the network label space identified
by the DOI in a manner that preserves their security goals.  The two
systems shouldn't necessarily have to share a label encodings file or
security policy configuration in order to communicate using a given DOI.

-- 
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.