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

Casey Schaufler casey at schaufler-ca.com
Mon Aug 6 18:47:55 EDT 2007


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

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.

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


More information about the Labeled-nfs mailing list