[Labeled-nfs] Current development prototype patches.

[Casey Schaufler]

--- "David P. Quigley" <dpquigl at tycho.nsa.gov> wrote:

> On Mon, 2007-08-06 at 07:24 -0700, Casey Schaufler wrote:
> > --- "David P. Quigley" <dpquigl at tycho.nsa.gov> wrote:
> > 
> > > On Fri, 2007-08-03 at 16:33 -0400, Matthew N. Dodd wrote:
> > > [snip...]
> > > 
> > > There is a small problem with doing file labeling in this manner. This
> > > method works assuming that we only use dumb servers. However one of the
> > > requirements is to have MAC enabled servers be part of the decision
> > > process. In this case we need to send the process secid over to the
> > > server most likely as part of the RPC.
> > 
> > I expect that you want the server to enforce its policy and the client
> > to enforce its policy and that you do not want to even consider
> > attempting to enforce the client's policy on the server. There's just
> > too much internal state (e.g. what LSM is on the client, for SELinux
> > the policy) on the clients to duplicate it for each client on the
> > server. The best that the server can do is call back to the client
> > and ask what decision the client would have made, and why not have the
> > client do that itself?
> 
> After a brief discussion with Steve it seems that the way to go with
> this is to have the client initially try to determine the label and have
> the server be a verifier for it.

Better, but you still need to have some sort of criteria for
the server to use for verification, and if that doesn't take
the client policy into account, what will it do?

> The negotiating of the label between
> the client and the server adds unneeded complexity.

Yes, that too.

> At this point the
> server can determine if it wants that client to be able to label the
> file in that manner and send a create/setattr failure back to the client
> if it chooses to do so. 

But what criteria can it use in the absence of understanding
the client's rules? In the old MLS world we could store the MAC
label as level/category-set values and mandate that everyone used
the same level and category definitions. The vendors who did that
were able to support NFS whereas the one who used mapped (e.g.
secid) schemes had real struggles because everything has to be
translated by everyone.

It seems that your best bet may be simply label identification.
Store the source of the label with the label and let the clients
(and local use on the server) fight out the access control rules.

Isn't the composition problem fun?

> > > I know this is an initial
> > > implementation however it is something we need to consider moving
> > > forward so we don't shoot ourselves in the foot later. 
> > >  
> > > > +/*
> > > > + * For now, we need a way to compute a SID for 
> > > > + * a dentry as the inode is not yet available
> > > > + * (and under NFSv4 has no label backed by an EA anyway.
> > > > + */
> > > > +static int selinux_dentry_init_security(struct dentry *dentry, int
> > > > mode, u32 *sid)
> > > 
> > > 
> > > _______________________________________________
> > > Labeled-nfs mailing list
> > > Labeled-nfs at linux-nfs.org
> > > http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs
> > > 
> > > 
> > > 
> > 
> > 
> > Casey Schaufler
> > casey at schaufler-ca.com
> 
> 
> 


Casey Schaufler
casey at schaufler-ca.com