Re: [nfsv4] my thoughts on how Labeled NFSv4 draft should move forward

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Tue, Apr 14, 2009 at 11:59:29AM -0400, David P. Quigley wrote:
> On Fri, 2009-04-10 at 15:38 -0500, Nicolas Williams wrote:
> > Of course, it's not clear yet that it will be of much practical value to
> > have such smart servers (e.g., if all the clients would be fully trusted
> > anyways).  It may be possible that "dumb" servers are good enough, in
> > which case we don't need to complicate RPCSEC_GSSv3 with process label
> > assertions (though it's not much of a complication, but the client does
> > need to know, via an NFS operation, whether the server is smart or
> > dumb).
> 
> It is unclear to me why an NFS operation is needed for this. Why can't

It could be an attribute.  That's how a variety of things are negotiated
already.

> this be something that is negotiated in the GSS context? When the GSS
> context is created they can decide if the server is smart or not and if
> it is then the process label is something that is part of the context.
> Then when the server is making a decision if it is Smart it will use the
> credential from the GSS context if not it will ignore it.

I'm thinking that the server could even be selectively smart or dumb.
For example, for objects labeled with MLS the server could be smart.
For objects labeled with Smack the server could be smart if it can
retrieve the rules matched by the client process' label's DOI.  For
objects with DTE labels in a DOI where the number of domains is too
large for it to be meaningful for the server to be smart then the server
could be dumb.

A filesystem attribute seems potentially too coarse for this, but it
could be a per-object attribute.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.