Subject: [nfsv4] Labeled NFS virtually connecting heterogeneous client policies

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 16 May 2012 21:09:23 +0000

While Labeled NFS explicitly provides for heterogeneous labeling systems, it purposely puts policy decisions out of scope. It also concentrates exclusively on single client-server connections. The former is good, but the latter may need "supplementing". In addition, the spec explicitly accounts for server-side labeling system heterogeneity, but does not mention that even when two federated servers speak the same labeling system, they may not implement the same policies. It's probably worth including a brief section on how multi-system policies may interact when connected by Labeled NFS. This is not to say that this spec should dictate policies, but it should give an idea of how Labeled NFS "joins" policies of individual participants into one effective system policy.

Attached is a figure containing two Venn diagrams. At the top is the "Full" mode. Allowable interactions, shaded green, are the intersection of all of the clients' policies and the server's policy. Note that it is completely possible to have mutually exclusive interactions (certain clients may only be able to access certain directories; each client gets a different directory.)

At the bottom is Limited Server mode, where the server is just acting as a label store; or guest mode, where the server provides no MAC information and all properties are inferred by MAC functional clients. In either case, the allowable interactions are the union of all of the clients' policies.

In both diagrams, the systems are either using the same labeling system or they are translating. In any case, the labels are doing their job and are communicating.

At the very least, I think it important to note that the primary difference between "Full" mode and the other modes is that Full mode represents the intersection of all clients' policies with the server's policy and the other modes allow the union of all clients' policies. The clients have no information whatsoever about which other clients are allowed to connect to the server, or how they might be configured. In both diagrams, there are more allowable interactions than a single client can possibly know about. Put this in all caps and bold. :)

My understanding of MAC labels is that they are persistent data used by MAC policies to control access. (i.e., A MAC-functional system requires more than just the label in order to make the decision; or: labels do not encode the entire policy framework). Clearly if the label is all that is needed to make the access decision, then this email is moot. But I think there just may be more to it than making sure a single client and a single server can talk the same language.

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 May 2012 17:06:33 -0500

On Wed, May 16, 2012 at 4:09 PM, Nordgren, Bryce L -FS
<[email-masked]> wrote:
> [...]
> At the very least, I think it important to note that the primary difference
> between “Full” mode and the other modes is that Full mode represents the
> intersection of all clients’ policies with the server’s policy and the other
> modes allow the union of all clients’ policies. The clients have no
> information whatsoever about which other clients are allowed to connect to
> the server, or how they might be configured. In both diagrams, there are
> more allowable interactions than a single client can possibly know about.
> Put this in all caps and bold. J
>
>[...]
> My understanding of MAC labels is that they are persistent data used by MAC
> policies to control access. (i.e., A MAC-functional system requires more
> than just the label in order to make the decision; or: labels do not encode
> the entire policy framework). Clearly if the label is all that is needed to
> make the access decision, then this email is moot. But I think there just
> may be more to it than making sure a single client and a single server can
> talk the same language.

MAC labels are persistent when applied to persistent objects.
Subjects are typically ephemeral ("processes") and persistent (e.g.,
users).  In a labeled system all objects and all subjects must be
labeled, implicitly so if necessary (that is, with default labels).

Some MAC systems require no further policy: those that are algorithmic
in nature, such as MLS.  Some do require policy: such as those that
are not entirely algorithmic, e.g., SMACK.

In Full mode the server must reject labels it cannot comprehend and
the server applies labeled security policy.  The clients' help the
server determine subject labels, and apply labeled security policy
locally (but the server can't enforce this).  Because of this the
server and its clients must at minimum agree on a subset of label
namesapce -- else they won't interoperate.  Then there is the obvious
(I should think) desire to have consistent labeled security policies,
whichmeans that not only must the server and its clients agree on [a
subset of] labels, they must also agree as to policies involving those
labels.

There is no requirement that the policies be the same at the server
and all its clients.  Some clients might have a subset of the policy
known to the server (and, presumably, the server's policy should not
allow such clients to see resources with labels outside the client's
policy).  Other clients might have a super-set of the server's policy
(and, presumably, such clients'policies should disallow the publishing
of data/metadata, including labels, to the server that the server
should not see).

In practice the most common scenario -the one that is easiest to
manage- will probably be to have synchronized policies across all of a
server's clients and their other servers.  But in sufficiently large
environments (e.g., in cross-organization networks, think of the DoD)
the policies will almost of necessity vary.

Do you believe that additional text is needed in the I-D to cover this?

Nico
--

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 16 May 2012 23:29:46 +0000

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2012 4:07 PM
> To: Nordgren, Bryce L -FS
> Cc: [email-masked]
> Subject: Re: [nfsv4] Labeled NFS virtually connecting heterogeneous client
> policies
>
> Then
> there is the obvious (I should think) desire to have consistent labeled
> security policies, whichmeans that not only must the server and its clients
> agree on [a subset of] labels, they must also agree as to policies involving
> those labels.

+1
I didn't see that in the I-D. Is this part of the negotiating to get a security context? This needs to be a MUST.

> There is no requirement that the policies be the same at the server and all its
> clients.  Some clients might have a subset of the policy known to the server
> (and, presumably, the server's policy should not allow such clients to see
> resources with labels outside the client's policy).

More Venn diagrams. :)

Given the presence of "consistent labeled security policies", I do think that a useful control for MAC-aware servers would be to guarantee that all clients connecting to the server possess a certain "policy set". This may be a "lower bound" for the full mode, but it should be a "upper bound" for the "limited server" and guest modes. Certainly, the admin should be given control over whether this guarantee is in place or not.

(e.g., Mac aware servers should be able to do simple "set comparisons" with labeled policies even if they don't bother to implement those policies.)

> manage- will probably be to have synchronized policies across all of a server's
> clients and their other servers.  But in sufficiently large environments (e.g., in
> cross-organization networks, think of the DoD) the policies will almost of
> necessity vary.
>

Yes! Labeled NFS is all about elevating MAC controls from a single-system, homogeneous environment to a heterogeneous networked environment. A HUGE component of this is that no client has the complete policy picture. If Labeled NFS offers absolutely no control over or information about the client policies which are allowed to govern server objects, clients have to assume that anything stored on the server is available to all, at least under the limited server and guest modes.

It's not the single client-server connection which is the problem here. It's the fact that in limited server or guest modes, the second client can always be non-MAC-functional, meaning both ends are non-MAC-functional. (It only takes one.) All access controls are out the window. But if there's a way to communicate to the client (via labeled policies?) that the server only allows connections from MAC-functional clients, different assumptions can be made.

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 17 May 2012 01:18:46 +0000

On 5/16/12 4:29 PM, "Nordgren, Bryce L -FS" <[email-masked]> wrote:

>I didn't see that in the I-D. Is this part of the negotiating to get a
>security context? This needs to be a MUST.

We describe a MAC model's security decision making as:

   MAC models base their security decisions on a system
   wide policy established by an administrator or organization which the
   users do not have the ability to override.

I'd argue as to whether the individual policies need to be consistent on
the client and server for a given label. But if not consistent, they are
by definition still set as part of the global policy.

>Given the presence of "consistent labeled security policies", I do think
>that a useful control for MAC-aware servers would be to guarantee that
>all clients connecting to the server possess a certain "policy set". This
>may be a "lower bound" for the full mode, but it should be a "upper
>bound" for the "limited server" and guest modes. Certainly, the admin
>should be given control over whether this guarantee is in place or not.
>
>(e.g., Mac aware servers should be able to do simple "set comparisons"
>with labeled policies even if they don't bother to implement those
>policies.)
>
>
>>server's
>Yes! Labeled NFS is all about elevating MAC controls from a
>single-system, homogeneous environment to a heterogeneous networked
>environment. A HUGE component of this is that no client has the complete
>policy picture. If Labeled NFS offers absolutely no control over or
>information about the client policies which are allowed to govern server
>objects, clients have to assume that anything stored on the server is
>available to all, at least under the limited server and guest modes.

Again, whether or not the client cares about that is a policy and we do
not set policies in this document. A client can tell whether a server is
MAC-Aware, MAC-Functional, or neither. It can act on this only if the MAC
model decides on that as a policy.

The client cannot tell if the server does or does not allow
non-MAC-Functional clients access. If this is a concern, the MAC model can
be extended to a LFS which has a policy which disallows this type of
connection.

>
>It's not the single client-server connection which is the problem here.
>It's the fact that in limited server or guest modes, the second client
>can always be non-MAC-functional, meaning both ends are
>non-MAC-functional. (It only takes one.) All access controls are out the
>window. But if there's a way to communicate to the client (via labeled
>policies?) that the server only allows connections from MAC-functional
>clients, different assumptions can be made.
>

Let LFS L be the registered model for the Limited Server. It allows any
client to have access.

Let LFS L' be a simple variant of that model, which is also registered. In
this variant, the Limited Server only allows MAC-Functional clients to
have access.

My point is that we don't need to call this out in this document. We
define a MAC model of security as above - if in that model they are
concerned about non-MAC-functional client access, they can address it as
part of their policy. We have provided enough for them to do so.

>
>
>
>This electronic message contains information generated by the USDA solely
>for the intended recipients. Any unauthorized interception of this
>message or the use or disclosure of the information it contains may
>violate the law and subject the violator to civil or criminal penalties.
>If you believe you have received this message in error, please notify the
>sender and delete the email immediately.
>_______________________________________________
>nfsv4 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 May 2012 00:26:03 -0500

> I didn't see that in the I-D. Is this part of the negotiating to get a security context? This needs to be a MUST.

No, there's no way to negotiate this other than by negotiating DOIs.

(You might utilize NFSv4 to distribute MAC policy/configuration to
clients, but that's a different story, and not in scope here.)

> Given the presence of "consistent labeled security policies", I do think that a useful control for MAC-aware servers would be to guarantee that all clients connecting to the server possess a certai…

There's nothing NFSv4 can do to guarantee consistent labeled security
policies.  There's nothing for us to do here.

There may be (probably is) a need for a method for distributing MAC
policy to hosts, but that's out of scope here.  Nothing prevents
interoperability with hosts configured in some unspecified,
out-of-band manner.  We'll definitely need more experience before we
can standardize a protocol to provide for MAC policy distribution.
It's a complex topic.  In a large, multi-organization network such as
DoD runs this will be anything but simple.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 May 2012 00:28:15 -0500

> part of their policy. We have provided enough for them to do so.

I agree.  I mean, I think it'd be nice to provide highly didactic text
on MAC -- it's a topic that could use simple, concise, correct, clear
exposition.  I'm not sure that we should be providing such text in
this document.

Nico
--

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Thu, 17 May 2012 20:25:57 +0000

> From: Haynes, Tom [mailto:[email-masked]]
> I'd argue as to whether the individual policies need to be consistent on the
> client and server for a given label. But if not consistent, they are by definition
> still set as part of the global policy.

Then I am confused as to why the document deals with those features of NFS4.2 which may cause an interaction to cross an LFS boundary. Federated filesystems would seem unlikely to possess a global policy. I certainly agree that keeping the entire filesystem within one administrative domain would be simpler, but this document appears to try to address a much more general use case.

If Labeled NFS is allowed to participate in cross-domain filesystems, I say it is certainly required to describe how the various policies established by the participating administrators will interact (intersection or union) given the approach laid out in this document.

> Let LFS L be the registered model for the Limited Server. It allows any client
> to have access.
>
> Let LFS L' be a simple variant of that model, which is also registered. In this
> variant, the Limited Server only allows MAC-Functional clients to have access.
>
> My point is that we don't need to call this out in this document. We define a
> MAC model of security as above - if in that model they are concerned about
> non-MAC-functional client access, they can address it as part of their policy.
> We have provided enough for them to do so.

Interesting.

Your ideas about communicating policy would be to instantiate a new LFS, with the semantics implicit in the labeling system itself rather than any particular label. Nico's take was that there is an obvious need to agree on a set of Labeled Policies (presumably not as part of this document). I infer from the context of his message that these labels would be orthogonal to the MAC model in play. I assume everyone agrees that the scope of this policy communication is the security context and not individual filesystem objects.

By inspection, this leads me to conclude that the document is not specific enough to proscribe an approach (and therefore it needs to be called out in the document). While I certainly understand that it is not going to define the policies which need to be communicated, I think it is unavoidable that there will be a need for this communication about policies. This document is the perfect place to outline an approach without getting into either the details of "what policy labels should exist?" or "exactly what should the API look like?" It is also the perfect place to show examples of what policy communication could accomplish using each of these modes.

Or, you could just disallow Labeled NFS on cross-domain filesystems, as that violates your definition anyway. :) It would certainly give administrators less rope with which to hang themselves.

Bryce

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 May 2012 15:40:29 -0500

> Your ideas about communicating policy would be to instantiate a new LFS, with the semantics implicit in the labeling system itself rather than any particular label. Nico's take was that there is an…

I think we need more precision here.  The MAC models, the policies,
and the actual labels, are all orthogonal to LNFS.  LNFS is
essentially just about carrying labels in the protocol (subject labels
in RPCSEC_GSSv3, object labels in NFSv4), and/or informative text
about how to infer them or look them up (e.g., from client principal
names).

There's no need to have any normative text whatsoever in LNFS about
any one MAC model unless we decide to have one (or more)
must-implement MAC models.  The need for clients and servers to agree
on at least pair-wise policy subsets is implied in MAC systems;
stating this doesn't hurt, and probably helps, but it's not strictly
necessary (again, unless we wish to have a must-implement model).  And
if we did want to have a must-implement model (or more) we'd still
specify them orthogonally to LNFS anyways.

I think we'd have a very hard time picking a MAC model to require
implementation of.  I'd bet we'd not have consensus on any one, and if
we had consensus on three or four then implementors would suddenly
have that much more work to do.  IMO it's best to leave this for
another day (year, decade).

Nico
--

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Thu, 17 May 2012 21:52:53 +0000

> I think we need more precision here.  The MAC models, the policies, and the
> actual labels, are all orthogonal to LNFS.  LNFS is essentially just about
> carrying labels in the protocol (subject labels in RPCSEC_GSSv3, object labels
> in NFSv4), and/or informative text about how to infer them or look them up
> (e.g., from client principal names).

Agreed. The piece which is missing is how to communicate about policies. The document already defines how to communicate the other two out of three orthogonal bits.

> The need for clients and servers to agree on at least pair-wise
> policy subsets is implied in MAC systems; stating this doesn't hurt, and
> probably helps, but it's not strictly necessary (again, unless we wish to have a
> must-implement model).

I think it's necessary without imposing a must-implement model. Tom suggests the method of agreement is to replicate an entire LFS, instantiating a new one  for each combination of policies (no new labels are added, semantics are attached to the LFS itself). You suggest policy labels as a subset of the labels defined by the MAC model, which pares down the number of LFSes required. I have in mind a "policy model" separate from "security model", where a client would perform two separate "model negotiations" when trying to connect. By allowing a given set of policy labels to augment any arbitrary security model, the number of LFSes required is pared down still more. Who knows how many different approaches will spring up if it doesn't get nipped in the bud.

Clearly, the need for communication about policy can be removed if the use of Labeled NFS is limited to a single administrative domain. There is an easy out. :)

Bryce

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 May 2012 21:34:23 -0500

> Agreed. The piece which is missing is how to communicate about policies. The document already defines how to communicate the other two out of three orthogonal bits.

But we can't define the bit you're asking for because it's bound very
specific to each MAC model.

For example, for SMACK the synchronization in question involves having
semantically meaningful subsets of the SMACK ruleset on each client.
For MLS the synchronization issue involves having semantically meaning
subsets of label name translations.  And so on.  It's not even clear
that we can build one protocol to do this.  Maybe we can, but we
probably don't have enough experience as a WG to do this yet.

What we can do is what this I-D lays out.  That's what we should do.

> I think it's necessary without imposing a must-implement model. Tom suggests the method of agreement is to replicate an entire LFS, instantiating a new one  for each combination of policies (no new…

So, it doesn't actually help to have such a negotiation in NFSv4.  The
reason is that each node (client and server) need to know a priori
whether the peer is expected to have the correct MAC policy -- each
node should refuse to speak to a node not known to have the correct
MAC policy.

The question arises of how to determine whether any given peer has the
correct policy.  This... is to be determined by more policy.

For example, suppose we're using RPCSEC_GSSv3 with Kerberos, but not
IPsec, and that we're not relying on IP addresses or DNS.  This means
that the client host, the client user, and the server, all have
Kerberos principal names and corresponding credentials.  The client
has to decide whether the server's principal name (and realm) imply
that it has the required MAC policy.  The client might do a lookup in
some service (LDAP, perhaps) or in a local file, or perhaps the client
simply knows that all NFS servers in the server's realm by convention
must have the correct MAC policy.

A client might use IPsec information (e.g., from the server's
certificate), or the server's IP address, or hostname.  Of course,
using IP addresses or relying on DNS (but not DNSSEC) isn't exactly
secure, but in some environemtns it's good enough.

Having the server tell the client that the server has some
configuration doesn't help.  The client can't just take the server's
word.  Ditto in the other direction.

> Clearly, the need for communication about policy can be removed if the use of Labeled NFS is limited to a single administrative domain. There is an easy out. :)

Clearly, but it's clear too that there's no need to negotiate policy
in the NFSv4 protocol across administrative domains either.  The
method by which clients and servers determine whether the other has
the right policy subset must be out of band to NFSv4.  Oh, I suppose
the two could exchange attestations from some trusted third party,
along with public key signatures with their certificates, but even so
it's not clear that we don't want a generic protocol for that instead
of doing it in-band to NFSv4, and there may be sites that don't want
such a TTP infrastructure, preferring a scheme that simply has no
possible or reasonable in-band representation in NFSv4.

Nico
--