[Labeled-nfs] Labeled RPC & NFS

[Dave Quigley]

On Sun, 2007-12-02 at 07:21 -0500, Matthew N. Dodd wrote:
> James Morris wrote:
> > 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.
> 
> So a couple of potential issues.
> 
> The userland/kernel GSS protocol provides credential service on a 
> per-UID basis.
> 
> The credential cache mechanism matches per UID.  (As did the auth_unix 
> mechanism which is why I created a whole new auth_seclabel.)
> 
> In general the current RPC implementation seems poorly suited to MAC 
> environments.
> 
> RPCSEC_GSS seems like a good idea, but the implementation isn't actually 
> very extensible (in the way we need to be able to add additional fields 
> to the credential.)
> 
> > 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.
> 
> As far as GSS goes, I agree.
> 
> > 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.
> 
> This notion grows on me.
> 
> OP_PUTCLIENTLABEL (or something.)

This also solves the concerns that Trond had with the callbacks. This op
can have a stateid associated with it and if they don't match get a new
label/stateid from the server. Since relabeling is rare this shouldn't
be much of a problem. 

> _______________________________________________
> Labeled-nfs mailing list
> Labeled-nfs at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs