[Labeled-nfs] Client and Server policies and file creation.

[David P. Quigley]

Sorry for the double post Casey but I hit reply instead of reply all.

On Mon, 2007-08-06 at 15:47 -0700, Casey Schaufler wrote:
> --- "Matthew N. Dodd" <Matthew.Dodd at sparta.com> wrote:
> 
> > [In reply to a new discussion in a differently titled thread.]
> > 
> > When a file is created by a client, the client passes the desired 
> > attributes to the server in the request.  Later, the client requests the 
> > attributes the server created the file with.
> > 
> > It seems to me that this is exactly the way we want things to function 
> > when we enforce policy on the client and the server.
> 
> An important question is whether the client is going to get back
> the same attributes it sent in all cases. This requires either that
> the server stores what the client sent or that the mapping between
> what the client sends and what the server stores is reverseable.
> 
> Let's consider an easy case. The server supports a binary MAC policy,
> with two labels, USER and SYSTEM, stored in a single bit. The client
> has a Bell&LaPadula label that supports 256 levels and 64k categories.
> If you store the Server Native label you can't go back to the client
> label, you can't even come close. Any client access check based on a
> translation from the server label will be wrong.

The answer to this is that the server must operate at the same
granularity as the most granular client. Otherwise you can't assure the
separation that you are trying to guarantee on the client. Also it seems
that your easy case is more of a fringe case than what is to be commonly
expected.

> If the file system saves both the client label and the server label,
> and uses each in its appropriate context, you are better off - and
> here's the gotcha - so long as you only have one client. If you have
> a second client with a different MAC scheme you can't give it the
> server's label to use because you know it is wrong and you can't give
> it the other client's label because that will be wrong, too.

Also that means you have to store a client label in the file for each
client you intend to use the system. This is why we intend to have a
daemon similar to idmapd to handle translations between the DOIs This
way the most verbose form can be stored on the server and the client can
translate it into whatever form it wants on its end. If the client
chooses to not make use of information from the label it is welcome to
do that but atleast the information is there for those who choose to use
it all.

> Arg! Someone, quick, show me the flaw in my logic. Don't try to
> anything including "some sort of mapping" unless you can address the
> cases I've outlined. I know that phase I is targeting SELinux, but
> I think the problem is the same there, just less obviously.
> 
> 
> Casey Schaufler
> casey at schaufler-ca.com
> _______________________________________________
> Labeled-nfs mailing list
> Labeled-nfs at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs