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

[Dave Quigley]

On Tue, 2007-12-18 at 01:58 +1100, James Morris wrote:
> On Mon, 17 Dec 2007, Dave Quigley wrote:
> 
> > 
> > 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.
> 
> "Client Labeling:
> 
>   When an object is newly created by the client, the correct security
>   label for the file must be determined by server policy (or overridden 
>   by the creating process's fscreate attribute if authorized by server
>   policy), "
> 
> This is from the requirements doc, which was reviewed extensively.  If you 
> find that you disagree with the requirements, please address that at the 
> requirements level, rather than at the implementation stage.

Ok so this is how it works then. If the client wishes to use fscreate it
places it in the fattr4 structure sent over. If it is blank then the
process label is sent over, translated into the server's doi, and then
the server makes the decision on how to label. Why is this field needed
then? You can still get your functionality without it. I'm not saying
that I disagree with the functionality just that this item doesn't seem
necessary.

> 
> > > - 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.
> 
> I had that reversed: the client needs to know when to flush cached server 
> policy for locally cached or delegated objects.

"Ok I think it is overly complicated to ask the client to enforce the
server's policy. That should be the job of the server. This is easily
handled since NFSv4 added an open operation. The only problem I see is
delegations and there seems to be only two reasonable ways to handle
this. Either we disable delegations, or it is a prerequisite that the
client and server must both be using the same policy." 

-Quote by Me from email about the specification document. Bringing it to
this list for public discussion.

> 
> > > - 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. 
> 
> Well, if you have a client operating in permissive mode, for example, the 
> server cannot provide it with the same level of trust or integrity as a 
> client in enforcing mode.

I agree. We should revisit what these modes mean and see if anything
needs to be changed based on what we have learned to this point.

> 
> > > - DOI
> > 
> > Not quite sure why this is needed? We have been going with the doi
> > embedded in the label itself.
> 
> Ok, I guess.
> 
> > 
> > > - 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? 
> 
> These could be considered aspects of the DOI, but you really do want to 
> ensure that the systems are running the same security model, and also know 
> whether a peer is running a different policy version, which you may or may 
> not be prepared to handle.

I agree with this but I see it all being part of the DOI and handled by
the DOI authority.

> 
> 
>