[Labeled-nfs] Current development prototype patches.

[David P. Quigley]

On Mon, 2007-08-06 at 12:22 -0700, Casey Schaufler wrote:
> --- "David P. Quigley" <dpquigl at tycho.nsa.gov> wrote:
> 
> > On Mon, 2007-08-06 at 11:08 -0700, Casey Schaufler wrote:
> > > --- "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 am somewhat new to the problem but I don't see this as a composition
> > problem. Based on my understanding of the design requirements put forth
> > by James there is no need for the server to know about the clients
> > rules. I understand that a request to work in this manner. The client
> > makes a request based on the task and file label that it has. This
> > request is enforced first against the client policy,
> 
> It can't be done on client first because you have to fetch the
> file label from the server, or at the very least check to see if
> it has changed before you can do anything. This has really interesting
> implications for file creation, requiring that the label be included
> in the creation request.

Why can't it be done on the client side first? We already have the label
by virtue of having a handle to the file. This causes a small problem in
that our cache might be stale but we can attempt to revalidate the label
just before we copy the data to userspace inside the NFS code. Also
create requests are done through the open operation which allows us to
specify that it is a open_create operation and we can pass the label as
an argument into that. We can have the server check if it is OK for that
task to create a file in that directory with that label.

> 
> > and then the
> > client's request with it's task label and DOI are sent over the wire to
> > the server. On the server side a DOI translation is performed to obtain
> > the server's representation of the label. At this point the server
> > enforces the local policy based on the translated task context and the
> > local file context.
> 
> So you translate ClientTaskLabel to a ServerTaskLabel and a
> ClientFileLabel to a ServerFileLabel and then apply ServerPolicy.
> You have a translation table for each client, because each will
> have a different policy. You are sending a context rather than a
> secid because the client may have changed it's policy between
> requests, making the secid unreliable.

secid's are also platform dependent and that is why the context on the
wire is formatted as a string instead. As Paul said we want to obtain
the greatest amount of cross platform/security model interoperability
possible, so we need some sort of translation mechanism. 

> 
> No flaws, but a lot of work. If the policies are at all compatible
> you shouldn't have to do the server side.
> 
> 
> Casey Schaufler
> casey at schaufler-ca.com