[Labeled-nfs] Client process label operation (OP_PUTCLIENTLABEL)

[Dave Quigley]

On Sat, 2007-12-15 at 20:34 +1100, James Morris wrote:
> On Wed, 5 Dec 2007, Matthew N. Dodd wrote:
> 
> > So, as an alternative to a new RPCSEC flavor, encoding the requesting process
> > label in all client compound operations was suggested.
> > 
> > Attached is a patch that demonstrates one way of doing this.
> 
> Looks like a good start.  I'd suggest making this more general (perhaps 
> OP_SECURITYLABEL), which includes various optional security state and 
> which is always present in client and server messages when labeling is 
> active.
> 
> So, for SELinux, we'd likely want to convey, in addition to the current 
> security context of the principal:
> 
> - the "fscreate" attribute (client only), if applicable, which the server 
>   may honor and use as the file creation label if permitted 

This is unnecessary. fscreate can be enforced on the client side with no
protocol level changes. When you create an object on the server part of
the create is an fattr4 mask and structure so we can atomically set the
value on create.

> 
> - security policy serial number (client only), which the server uses to 
>   know when to flush cached policy

Not quite sure what you mean by this? I don't see how a change in policy
on the client side effects the server's decision. The only thing the
server should care about is mapping. Unless you mean flush cached
translations and then I can see a need for it.

> 
> - operating mode (enforcing/permissive)

I read over the section on operating modes in the requirements document
and I don't really see merit to parts of the operating modes. Because of
this I'm not sure if you need to pass this over the network. 
> 
> - DOI

Not quite sure why this is needed? We have been going with the doi
embedded in the label itself.

> - security policy version (e.g. "21")
> 
> - security model (e.g. "selinux:ibac+rbac+te+mcs")

Not sure what the point of passing this data is? 

> 
> The latter three would not be expected to change during a session, so 
> would only be mandatory in the first messages between a client and server 
> effectively as negotiation.
> 
> 

I really think we need to sit down and have a telecon and figure out
what the new plan is. We have come quite far since the requirements
document and we have learned more about NFS so we can make better
decisions on what is needed and what isn't. I know you're in Australia
so scheduling a time will be a bit difficult but I think we can get a
lot out of a real-time discussion on this.