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

From: Jarrett Lu <[email-masked]>
Date: Mon, 06 Apr 2009 14:07:04 -0700

David,

There were a lot of discussion on labeled NFSv4 recently. I like to make 
a suggestion in how your draft should go forward.  I believe you should 
continue proposing adding a DOI + an opaque label field. There are two 
slightly different usage models of DOI:
(1) the current proposal -- DOI is used to indicate the format of label 
in the opaque field. A new predefined DOI / label format pairing needs 
to exist in a registry. Being able to parse a label doesn't necessarily 
imply one can correctly interpret or translate a label. Label policy 
consistency is administered outside of the Labeled NFSv4 protocol 
extension. (2) Using same DOI implies that communicating peers can 
correctly parse the opaque label field AND label policy between 
communicating parties are consistent, i.e. they can correctly interpret 
labels using same DOI.  This DOI usage is consistent with CALIPSO DOI; 
hence the same DOI registry can be used by NFSv4. I like (2) better for 
following reasons:

- It removes the need for another DOI registry. I believe a new DOI 
registry will be under scrutiny and may cause uneasiness in IETF later on.

- It is consistent with how MAC systems use DOI today. Granted that the 
CALIPSO spec is MLS centric. But DOI need not favor MLS systems in any 
way. It could be effectively used on DTE systems as well. For example, 
DOI number 5 means a pair of DTE system sharing consistent label 
security policies.

- I believe it's easier to implement MAC policy consistency on a system 
where DOI conveys the same meaning in different layer of a system stack.

In any case, the "DOI  + opaque label" proposal relies on an OOB method 
to be useful. This is weak in terms of interoperability. But I believe 
that allowing systems to share file label attribute still adds value, 
even when an OOB method is required. I can help writing some usage 
scenarios about how such extensions may be used on MLS systems.

Now there is a separate discussion on saag list in how to do policy 
exchange among MAC systems. If this can be done, labeled NFS can 
definitely benefit from that effort and improve its interoperability 
story. It's probably wise to separate the two efforts so that each can 
proceed independently. I haven't studied the "labeled policy exchange 
framework" enough to know if it changes the current NFSv4 proposal.

Jarrett

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 17:08:39 -0500

> hence the same DOI registry can be used by NFSv4. I like (2) better for 

The difference between (1) and (2) is artificial since in both cases the
client and the server have to agree on what each DOI they use means.
The difference is only whether we ought to have a registry.  Clearly we
should not, for all the reasons that you list in part because we may well want to go with DOI+opaque now
and later add support for agreeing on security policy subsets (by, e.g.,
exchanging URIs of policies specified in SPIF or whatever), so defining
a registry would be a waste of effort later.

Option 3: send DOI+label_format+opaque_label.  But still, this strikes
me as unnecessary -- the client and server have to agree on what the DOI
means, so they might as well agree on what the label format is (MLS,
DTE, ...).

> scenarios about how such extensions may be used on MLS systems.

Yes, but you've convinced me that we need to solve that interoperability
problem.  I don't think we should block labeled NFSv4 on solving that
problem, but we should have an idea of how we'll shoehorn a solution
into labeled NFSv4 later.  Fortunately labeled NFSv4 will rely on
RPCSEC_GSSv3, which I've designed to be extensible from the get-go.

> framework" enough to know if it changes the current NFSv4 proposal.

I agree.

---

From: "David P. Quigley" <[email-masked]>
Date: Fri, 10 Apr 2009 15:43:43 -0400

Hello,
   Pete, Steve, and I have taken in the results of the last week and a
half of discussion and have discussed the way we see things working. We
believe that the DOI usage model that you have marked as number 1 is the
one we would like to see agreed on eventually. There are several reasons
we it the first being that it allows for a much smaller DOI space than
would normally be required. By only specifying the format of the label
in the DOI it allows for implementers to easily develop systems to parse
these labels. This method also allows for a more dynamic policy at the
end points allowing for customizations to be made on a site specific
basis without having to use an external entity such as IANA. This
doesn't mean that there will be no authority to provide semantic
information on policies but rather that authority is not specified in
the DOI field. The cool part of using this method is that we can have
DOI 5 be CALIPSO formatted labels and in the opaque field we can use the
complete CALIPSO label specification DOI and all. In this case the
CALIPSO DOI would be an authority identifier to allow the system to
obtain the necessary information. 

To address your first point below we believe that if the DOI space is
sufficiently small and we can define a reasonable way to specify the
label format for parsing purposes that the IETF won't mind that we have
this registry. The question here is how finely do we define the label
specification for a DOI. For example, the SELinux context can be
described as, 1) a string, 2) a colon separated string, 3) a colon
separated string where the first component is a user, the second
component is a role, the third component is a type, and there is an
optional 4th component of an MLS range. We can even go further and say
do we want to specify in some form of regex the valid forms of each
component. I think if the registry contains information like that it
will be very valuable to implementers and will be accepted.

To address your second point, most MAC systems in deployment today are
in fact MLS centric and as Casey has pointed out the problem space has
grown to be larger than just MLS. Because the methods and documents that
people have been discussing over the last couple of weeks are so
engrained with MLS we don't believe that they will generalize well to
other MAC systems such as Type Enforcement. The reason these older
methods were able to work is because the policy was statically defined.
Modern systems require the ability to provide additional policy
configuration on the end points and this dynamic nature makes it seem
unlikely that the older methods will generalize to be able to
accommodate this.

Finally to address your third point we think that it is wrong to assume
that there should be the same DOI across all levels in a system. This
assumption is very limiting to the system design because it assumes that
all levels will be concerned with all information. For example a system
may be using CALIPSO to label its network traffic but once that traffic
comes into the endpoint or is received by the other endpoint it may
translate it into a preferred internal label representation that is
completely different.

Dave

---

From: "David P. Quigley" <[email-masked]>
Date: Fri, 10 Apr 2009 15:43:45 -0400

So we agree that in abstract there is no difference between 1 and 2
however fundamentally we believe that the label format belongs in a
registry that people can consult, for the reasons that I specified in my
reply to Jarrett, while the label semantics really belong to the
specific authorities that determine them. By separating the two we
separate the hard problem (policy reconciliation) from the label
transport problem within the respective applications.

We see something similar to your option three as being the correct
solution. Instead of DOI+label_format+opaque_label we see the DOI as
being the label format specifier and then within the opaque label we
have an authority field which will allow you to determine the label
semantics. An example of its use would be for CALIPSO to request a DOI
for their label format and then within the opaque section use their DOI
to identify the label semantics.

With respect to the URIs we have a few issues with using them as a way
of specifying policy. First off they are spoofable as we can't
definitively guarantee the integrity of the URI and its source. A
related question is can we actually define the policy documents it would
point to in the face of the variability required by today's systems? The
specifications in the past worked to some extent due to the static
nature of the policy which isn't something we can assume with today's
systems. Also taking this into account how do we then proceed to
automate this process?

Dave

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Apr 2009 15:17:18 -0500

After that long thread on SAAG and a subsequent off-list discussion with
Casey (plus my reading Smack documentation) I'm almost ready to reach
the following conclusions:

 - We don't need policy agreement for MLS.  Servers have all the
   necessary information when comparing labels without reference to a
   policy.  However, clients have to be sharing a common MLS policy.

 - For "smart" MLS and Smack servers we need a method by which servers
   can determine the label range/set of client and user principals, but
   this need not be specified in a standard way except where label
   range/set is borne by authentication credentials (Kerberos V ticket
   authorization-data, PKIX cert extensions).

   This is already described in my RPCSEC_GSSv3 document.

 - For Smack we don't need policy agreement either, but it will be
   useful to distribute common subsets of Smack policy to clients, and
   to prefix labels from local-only sub-policies with a client ID (or
   client DOI, if you wish).

 - For DTE I've no idea what to do.  Policy agreement seems like a
   flight of fancy for DTE.  But *much* more importantly, because the
   process label transitions can span so many labels we simply cannot
   have too smart a server: the server can't meaningfully constrain the
   labels that a user@client can assert, therefore the server must trust
   all client assertions of process DTE labels or none at all.

   I.e., for DTE we can only have "dumb" servers.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Apr 2009 15:38:39 -0500

> the following conclusions:

I should expand on this.  See below.

>    policy.  However, clients have to be sharing a common MLS policy.

Which means DOI + label in CALIPSO-like label representation is
sufficient.  DOI + opaque label is also good enough for MLS if the DOI
can be used to find the label representation.

>    This is already described in my RPCSEC_GSSv3 document.

Which means we can proceed with this RPCSEC_GSSv3 aspect of labeled NFS.

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

>    client DOI, if you wish).

Which means we may want to have DOI + opaque label, and, perhaps, DOI +
client ID + opaque label (but a client ID can be in the opaque label).

It should be noted that Smack does have a way to encode Smack labels as
CIPSO MLS labels, though it is a hack.  We could similarly represent
Smack labels via whatever MLS label representation we use -- but it'd be
better (i.e., not hacky) to just have opaque labels for Smack.

>    I.e., for DTE we can only have "dumb" servers.

Which means that for DTE we should have DOI + opaque label and all the
server does is store them.  The server would not enfore DTE policies:
only clients would.  Of course, the server can have share-level ACLs to
decide which clients are trusted, but the server remains dumb.

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Mon, 13 Apr 2009 09:19:17 -0400

>    policy.  However, clients have to be sharing a common MLS policy.

That is too limiting.  Think coalitions.

>    I.e., for DTE we can only have "dumb" servers.

Why?  While it is certainly true that a given client may be authorized
to assert numerous discrete domains, that does not mean that a server
cannot limit a client to a specific set of domains.  That can be modeled
via a permission check on a label pair and security class, just like
everything else.

-- 
Stephen Smalley
National Security Agency

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 10:31:29 -0500

> That is too limiting.  Think coalitions.

I wrote that we don't _need_ policy agreement for MLS, not that we
couldn't use it if it were available.  A subtle distinction, I know :)
But you're right of course, that when label equivalencies come in we
then need policy agreement.

> via a permission check on a label pair and security class, just like

If the set of domains that a policy defines is enormous then it may be
difficult to limit the set of domains that a user@client could
reasonably claim when referring to objects on given file server.  IF
(and this is a big 'if' for me) the number of domains that a user@client
could assert cannot be constrained meaningfully then I don't see the
point of the server enforcing MAC: the server wouldn't be meaningfully
limiting what the client can do, therefore we might as well let the
client enforce MAC.

However, I imagine that much of any DTE policy is local-only -- that it
relates to system components like, say, passwd(1), or to user apps that
won't be straying outside a home directory or a sandbox therein.  If
local-only subsets of a DTE policy can be identified as such, and if
it's possible for the remainder to be shared by a DOI, and if it's
possible to ascertain what domains any user and any client can assert,
then we're back to where we can have a smart server.

Nico
--

---

From: Casey Schaufler <[email-masked]>
Date: Mon, 13 Apr 2009 21:02:22 -0700

Stephen Smalley wrote:
>> ...

I think that the point is that for that to be interesting you need
to have a significant number of subject-label/object-label/class
triples from the client available on the server. Additionally, it
assumes that the object label available to the server is in fact
the label from that client, not the server, and not a different
client. Unless you can map the object label on the file, wherever
it originated, to a label that is appropriate to the client's
policy. And heaven forbid that the client that "owns" the label
on the file should change it's policy and reboot. Now what you have
is at best no mapping, and at worst a mapping that reflects the
old, no longer considered "secure" policy.

---

From: "David P. Quigley" <[email-masked]>
Date: Tue, 14 Apr 2009 11:59:29 -0400

> need to know, via an NFS operation, whether the server is smart or

It is unclear to me why an NFS operation is needed for this. Why can't
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.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 12:10:19 -0500

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 12:26:24 -0500

> old, no longer considered "secure" policy.

My point was different.

With MLS and Smack there's typically a small number of process labels
that a given user on a given client could claim, and these labels could
be listed in a directory or in the client's and user's cryptographic
credentials.  Therefore the server can simply reject any assertions of
process labels outside the allowable set of labels for the given
user@client.

With DTE there may be an enormous number of domains (process labels),
and since these domains relate to domain transition rules that are very
much local affairs to the client, the server can only trust what the
client says.  Now, I do exagerate since DTE can express MLS-type
policies -- it's possible that there is a small set of domains that a
given user@client could assert meaningfully to a server, in which case
DTE would be on par with MLS and Smack.  The problem lies in identifying
that small set of domains relevant to server-enforced MAC, and making
sure that such small sets of domains exist.

Nico
--