my thoughts on how Labeled NFSv4 draft should move forward

[Jarrett Lu <Jarrett.Lu@sun.com>]

David,

There were a lot of discussion on labeled NFSv4 recently. I like to make 
a suggestion in how your draft should go forward.  I believe you should 
continue proposing adding a DOI + an opaque label field. There are two 
slightly different usage models of DOI:
(1) the current proposal -- DOI is used to indicate the format of label 
in the opaque field. A new predefined DOI / label format pairing needs 
to exist in a registry. Being able to parse a label doesn't necessarily 
imply one can correctly interpret or translate a label. Label policy 
consistency is administered outside of the Labeled NFSv4 protocol 
extension. (2) Using same DOI implies that communicating peers can 
correctly parse the opaque label field AND label policy between 
communicating parties are consistent, i.e. they can correctly interpret 
labels using same DOI.  This DOI usage is consistent with CALIPSO DOI; 
hence the same DOI registry can be used by NFSv4. I like (2) better for 
following reasons:

- It removes the need for another DOI registry. I believe a new DOI 
registry will be under scrutiny and may cause uneasiness in IETF later on.

- It is consistent with how MAC systems use DOI today. Granted that the 
CALIPSO spec is MLS centric. But DOI need not favor MLS systems in any 
way. It could be effectively used on DTE systems as well. For example, 
DOI number 5 means a pair of DTE system sharing consistent label 
security policies.

- I believe it's easier to implement MAC policy consistency on a system 
where DOI conveys the same meaning in different layer of a system stack.

In any case, the "DOI  + opaque label" proposal relies on an OOB method 
to be useful. This is weak in terms of interoperability. But I believe 
that allowing systems to share file label attribute still adds value, 
even when an OOB method is required. I can help writing some usage 
scenarios about how such extensions may be used on MLS systems.

Now there is a separate discussion on saag list in how to do policy 
exchange among MAC systems. If this can be done, labeled NFS can 
definitely benefit from that effort and improve its interoperability 
story. It's probably wise to separate the two efforts so that each can 
proceed independently. I haven't studied the "labeled policy exchange 
framework" enough to know if it changes the current NFSv4 proposal.


Jarrett


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