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

[James Morris]

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.

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

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

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



-- 
James Morris
<jmorris at namei.org>