Subject: [nfsv4] Labeled NFS interop complexity matrix (was Labeled NFS: Per-client subject label functionality)

From: Nico Williams <[email-masked]>
Date: Thu, 23 Jun 2011 21:21:12 -0500

Consider the interop matrix size.  If we have four kinds of clients
and four kinds of servers then we have 16 possible combinations, of
which only one is immediately out of scope.  So fifteen combinations!!
 You'd better remove some of these options, else the task of
addressing their security considerations, code complexity (branch
count, ...), testing, etcetera will be enormous.  Even eleven would be
too many combinations.

If we only had two types of clients (dumb and smart) and three types
of servers, then we'd have to concern ourselves with five
combinations, which is still quite a few, but perhaps tolerable.

Worse, we need to understand the semantics of a highly heterogeneous
deployment, particularly as to clients, meaning that many of these
fifteen or eleven combinations might have to co-exist in actual
deployments, which increases the complexity of the security analysis
and test matrix considerably.

We know we need smart/smart, since that's the ultimate goal.  We also
know we need smart/dumb and dumb/smart combinations for deployment
reasons.  That's three combinations at the bare minimum.  Do we really
need any more?  Why?

I'm still having trouble understanding the need for label-aware but
non-MAC-enforcing servers.  What purpose do they serve?  Why would one
want such a server?

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Fri, 24 Jun 2011 09:56:54 -0400

> non-MAC-enforcing servers.  What purpose do they serve?  Why would one

NFS appliance that doesn't allow loading of label definitions / policy
configurations but needs to support label storage for clients.

NFS server serving a collection of FreeBSD, Solaris, and Linux systems,
which require label storage but each have different security models and
label formats.

NFS server serving RHEL-4, RHEL-5, and RHEL-6 clients, which all use
SELinux and require label storage, but differ in their specific policy
configurations, label spaces (e.g. some labels added, some removed in
each version), and even label format from RHEL-4 to RHEL-5 (enablement
of the optional MLS field).

-- 
Stephen Smalley
National Security Agency

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 24 Jun 2011 15:04:55 +0000

Thanks, Stephen.  We will include these into the requirements document
so we don't forget.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Smalley
> Sent: Friday, June 24, 2011 6:57 AM
> To: Nico Williams
> Cc: [email-masked]
> Subject: Re: [nfsv4] Labeled NFS interop complexity matrix (was Labeled
> NFS: Per-client subject label functionality)
> 
> configurations, label spaces (e.g. some labels added, some removed in each
> version), and even label format from RHEL-4 to RHEL-5 (enablement of the
> optional MLS field).
> 
> --
> Stephen Smalley
> National Security Agency
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: sfaibish <[email-masked]>
Date: Fri, 24 Jun 2011 12:36:04 -0400

> of the optional MLS field).
Very good description of usecases. We might want to include this in the
I-D. Thanks Stephen.

/Sorin

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: <[email-masked]>
Date: Fri, 24 Jun 2011 19:10:08 -0400

Nico,

IMHO, thou doth protest a bit much ...

>  You'd better remove some of these options

Ok, watch carefully ... my hands don't leave the ends of my arms ... ;-).

1) All four cases that use a dumb client can be eliminated because no
labeled NFS functionality is attempted.  That includes the dumb/dumb case
that is "immediately out of scope".

2) The three dumb server cases are simple, as one just looks for the first
failure or two.  The first time the client tries a labeled NFS op, it should
get a not supported error and stop trying; this may happen once for subject
label and once for object label.  That leaves nine cases.

3) The cases where the client tries to do more than the server supports
quickly reduce to other cases after an initial failure or two.  For
example, the client tries RPCSEC_GSSv3, server says "not supported", and
the client either goes away or resorts to object labels only.  The
object-labels-only client with the same server is covered by a different
case in the test matrix. That's another three cases that are simple,
leaving six interesting ones.

So, of these twelve cases, half should exhibit quick failures that either
complete them or reduce them to other cases, leaving six cases that require
serious testing.  In terms of overall effort, I think I've cut the initial
fifteen cases about in half.

> and test matrix considerably.

This is also easier than described.  The security considerations section
breaks down by client vs. server and protocol functionality.

On the server side, we already have to describe the security considerations
around inferring a subject label from configuration as that's needed for dumb
clients and clients that only set object labels.  The server side security
considerations for SET_LABEL should be an incremental addition to that text,
as SET_LABEL effectively lobs an additional piece of config information
across the wire that the server has to be cautioned about trusting (there
will already need to be related cautions about trusting config information,
e.g., a man-in-the middle can pick any IP address he likes).

On the client side, we already have to describe the security considerations
of both subject and object labels, and protecting them from unauthorized
manipulation.  Again, the security considerations for SET_LABEL should be
an incremental addition as it's not introducing any new label concepts.

> non-MAC-enforcing servers.  What purpose do they serve?  Why would one

See Stephen Smalley's explanation for label-aware but non-MAC-enforcing
servers - uses for them can be found in at least Sections 8.2, 8.5 and 8.6
of the draft.  Section 8.4 of the draft describes a use case (Legal hold/
eDiscovery) that can benefit from object-label-only clients (classify
information into data map when generated rather than later).

Thanks,
--David

> From: Nico Williams [mailto:[email-masked]]
> Sent: Thursday, June 23, 2011 10:21 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Labeled NFS interop complexity matrix (was Labeled NFS: Per-client subject label
> functionality)
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Jun 2011 18:54:54 -0500

> IMHO, thou doth protest a bit much ...

Well, let's see!

> Ok, watch carefully ... my hands don't leave the ends of my arms ... ;-).

:)

> that is "immediately out of scope".

We know from experience with Solaris TX that it can be desirable to
have dumb clients accepted at a single label.  Why?  Migration.

So I'm afraid we cannot rule out all dumb client combinations out of hand.

Moreover, even if we rule them out we must at least say something like
"non-dumb servers must reject all accesses from dumb clients".

> label and once for object label.  That leaves nine cases.

Does "labeled NFS op" include RPCSEC_GSSv3 with label assertions?  Or
are you referring to GET/SETATTR of the label attribute?  Or to
SET_LABEL?

But yes, I agree that the dumb server cases all are the same.

> leaving six interesting ones.

I'm not so sure.  The client needs to know whether the server applies
MAC.  Support for RPCSEC_GSSv3 is hardly indicative of that, as RPCSEC
is the wrong layer in which to indicate that.  But MAC is implied, not
explicitly requested.

So I think you'll at least need a filesystem attribute by which to
indicate whether the server stores object labels, stores object labels
*and* evaluates MAC, or neither.  Actually, this has to be
per-filesystem, since there might be public filesystems, of
filesystems whose on-disk layout does not permit storing object
labels.

I think this is what was missing to make the analysis simple enough.
I'll think about it over the weekend.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 24 Jun 2011 20:01:04 -0400

> information into data map when generated rather than later).

As far as I'm concerned, the killer app for Labeled NFS is, and has
always been, about supporting kvm over NFS, which is all about the smart
client + dumb server scenario.
I really don't give a damn about the "smart server" ideas: As was
pointed out on the concall today, the security policies that can be
enforced by putting all the smarts in a glorified disk drive will always
be severely limited. Once the data has been downloaded to the NFS
client's cache, the NFS server has lost control over it.

Ultimately, any security policy that a server is trying to implement
needs to be enforced by the client too, and that has always been the
motto of NFS.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Jun 2011 19:42:56 -0500

> needs to be enforced by the client too, and that has always been the

Ah, for the VM use case, if you trust all the clients equally, then a
server that doesn't apply MAC but stores labels makes sense.  OK, I
get that now.

---

From: <[email-masked]>
Date: Fri, 24 Jun 2011 21:10:05 -0400

> On Fri, Jun 24, 2011 at 6:10 PM,  <[email-masked]> wrote:

[... snip ...] 

> So I'm afraid we cannot rule out all dumb client combinations out of hand.

I agree, but my point is that this does not involve any labeled NFS testing
because the dumb client isn't using any labeled NFS functionality.

> "non-dumb servers must reject all accesses from dumb clients".

We do have to say something, but not that -- it's up to the server to decide
what clients it wants to talk to, including whether a smart or semi-smart
server is willing to infer or assign a subject label to a dumb client (e.g.,
as Solaris TX is doing in the migration case).

> are you referring to GET/SETATTR of the label attribute?  Or to

All of them - each produces a not supported error of some form with a dumb
server.

> MAC.

No it doesn't, at least not via NFS.  The server can support everything in
labeled NFS, including all of RPCSEC_GSSv3 and still apply a MAC policy that
does nothing or is incompatible with the client's MAC policy.

Client assurance that a valid MAC policy is in use by the server is a
configuration validation problem.  Solving it requires knowing not only that
MAC is being enforced by the server, but what MAC policy is being enforced so
that the client can check for validity wrt its own MAC policy.

I strongly suggest *NOT* going there - as discussed previously on this
list, those sorts of policy consistency checks are done via means other
than the NFS protocol via administrative control that span the server and
all the clients.

[... remainder snipped ...]

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------