[Labeled-nfs] Labeled RPC & NFS

[James Morris]

On Thu, 29 Nov 2007, Matthew N. Dodd wrote:

> Stephen Smalley wrote:

Btw, looks like Stephen's email did not make it to the list.

> > I assume that's just for prototyping purposes?  My understanding was
> > that we were going to do this via GSS.
> 
> GSS adds nothing but additional complexity at this point.  The key 
> changes here are the ones that change the various cred structures 
> consumed by the RPC and NFS code.

Well, labeled NFS must work with existing GSS implementations, and it 
seems that this scheme is incompatible with GSS as it is a distinct 
security flavor of its own.

I'm also not quite sure where things sit in terms of potentially extending 
GSS-API to support MAC labels & credentials, as it seems that v2 can no 
longer be extended, and further extensions need to happen in v3: 
http://www.ietf.org/html.charters/kitten-charter.html

So, it seems that modifications at the RPC layer are unlikely to result in 
a workable solution in the near or medium future.  Of course, if I'm 
mistaken here, please let me know.

One approach I was considering was to encode all MAC labels and related 
security state within the NFS protocol and not necessarily involve the RPC 
layer at all.  i.e. via a "security" OP which is always prepended to 
compound OPs when labeling is active -- an approach which has been 
discussed recently in relation to volatile security state.

This would allow existing GSS implementations to work with Labeled NFS 
without modification.  Given that a security OP may be necessary (or at 
least desirable) in any case, it seems reasonable and practical to 
consider this approach for all MAC labeling.

It does not have to be the only possible mechanism.  A distinct security 
flavor as you have proposed may be useful when other security mechanisms 
are in place (e.g. labeled IPsec, trusted networks), and it may also be 
useful to try and add provisions for MAC labeling to v3 of GSS_API as a 
future option.

However, I think that to get something practical up and running soon which 
is also acceptable to the IETF, I think we need to first determine if a 
security OP approach: 

a) can meet our needs, and 
b) will be acceptable to  IETF and NFS maintainers.

If anyone with more understanding of IETF thinking in these areas has some 
comments, please let us know your thoughts.

Btw, my feeling on the IETF process is that we need to reach broad 
consensus on major aspects of this project first within the Linux security 
and Linux NFS communities before officially engaging in the IETF process 
Does this seem correct?



- James
-- 
James Morris
<jmorris at namei.org>