Subject: [nfsv4] LNFS - a fourth (!) type of server wrt MAC functionality

From: <[email-masked]>
Date: Tue, 17 May 2011 19:17:03 -0400

In working through protocol considerations for LNFS, it has become
apparent (at least to me) that there are actually 4 types of
servers wrt MAC support:

(1) No LNFS support: A client attempt to set an object label results
	in an NFS4ERR_NOTSUPP error. 
(2) Object label only: Server stores and returns object labels,
	supports the label change callback.
(3) Partial MAC support: server contains some MAC functionality,	
	but requires MAC in clients for full MAC functionality
(4) Full MAC support: Server enforces full MAC.  RPCSEC_GSSv3 is
	necessary to pass an explicit subject label to the server;
	the server may be able to infer a client-scoped subject label.

I believe that (1), (2) and (4) are well understood, along with the
protocol mechanisms that need to be specified for them [object labels
+ callback for (2), RPCSEC_GSSv3 subject labels for (4)].

In contrast, the partial MAC support (3) servers are relatively
new to this discussion.  It turns out that a rather limited partial
MAC implementation has value, and that *no* additional protocol support
is needed for these servers (!).  The explanation is as follows ...

Object label only servers (2) must operate in Smart Client Mode (section
7.2 of draft-quigley-...).  An important requirement for that mode is:

   The system requires that all clients in the environment be
   responsible for access control checks.

This implies that external configuration controls must be used to ensure
that only full MAC clients (smart clients) talk to such a server - it
only takes one non-MAC client to break the security perimeter.  That's
a serious requirement; if the server can help keep non-MAC (dumb) clients
out, more network configuration flexibility is possible.  The advantage
of that server check is that the security perimeter can now pass through
the server, provided that server detection of non-MAC clients is robust.

That detection of non-MAC (or untrusted) clients is MAC functionality -
a server that can distinguish MAC  (smart) from non-MAC (dumb) clients is
implicitly assigning a (limited) subject label to every NFS client (e.g.,
"smart" or "dumb"), and using that subject label to enforce a very simple
security policy ("smart" -> full access, "dumb" -> no access).

One example where this is useful in practice is server virtualization
environments where the hypervisors contain full MAC clients, but there
may be clients (probably non-MAC) in the guest VMs.  In this example,
only the hypervisor NFS clients are trusted to enforce the required MAC
controls.  It is reasonable to configure such an environment so that the
hypervisor NFS clients are in an IP address block that cannot be used by
any guest VM.  If this is done, then a partial MAC server can use the IP
address of the NFS client to infer the client subject label ("smart" if
in hypervisor IP address block, "dumb" otherwise) and make the correct
access decision.  Notice that this is robust to the smart-aleck who tries
to use a full MAC NFS client in the VM - that client gets a "dumb" IP
address and hence no access to the server.

I don't see any need for additional protocol functionality for these
partial MAC support servers, but I think their usage with smart clients
and above discussion of the virtualization use case for them should be
captured in the draft.

Q: What are the interesting means aside from IP address block that can
be (are) used to infer subject labels for NFS clients?

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 May 2011 19:07:42 -0500

>        in an NFS4ERR_NOTSUPP error.

But smart clients could still label objects via naming conventions.
This is not an idle thought. This has been implemented.

>        supports the label change callback.

Also, (2) applies no policy.

>        but requires MAC in clients for full MAC functionality

What do you mean?  What policy does such a server apply?  Does such a
server do for determining subject label?  How does such a server
determine object labels?

I suspect that you mean something like a smart server w/o any protocol
extensions nor RPCSEC_GSSv3.  Solaris TX implements that.  Is this
what you mean?

>        the server may be able to infer a client-scoped subject label.

Right, the semantics of a smart server are easy.

> + callback for (2), RPCSEC_GSSv3 subject labels for (4)].

The protocol elements needed for (2) are also needed for (4), but I'm
sure you meant as much.

> is needed for these servers (!).  The explanation is as follows ...

(3) has more value, IMO, than (2), not least because it requires no
protocol changes -- just configuration and conventions.

(3) could benefit from standardizing configuration, at least abstract
configuration schemas, and possibly concrete ones too.

(2) seems predicated on an idea that somehow it's too difficult to
implement labeled security on servers, but easy on clients.  But I
think that's just an assumption built on various assumptions.  We
should explore the rationale for (2) carefully, because why waste the
effort specifying something we don't actually need?

>   responsible for access control checks.

That's also true of (1), though the server could also use share ACLs
to contribute to MAC enforcement.

> and above discussion of the virtualization use case for them should be

I agree, not least, again, because this has been implemented.

> be (are) used to infer subject labels for NFS clients?

- RPCSEC_GSSv1 user principal names.
 - AUTH_SYS identity assertions (seriously, because if you're going to
be relying on IP addresses, hopefully you have a secure network,
preferably via IPsec).
 - IP address + one of the above two.
 - some other OOB mechanism?  (identd, anyone?)

All poor choices, some quite so.

Nico
--

---

From: Stephen Smalley <[email-masked]>
Date: Wed, 18 May 2011 08:40:28 -0400

> effort specifying something we don't actually need?

How many NFS file server appliances are likely to support full MAC in
the near term?  Even if their OS includes a MAC mechanism
implementation, how many of them are likely to allow the end user to
load their own organizational security policy and label definitions onto
the appliance so that the server can in fact enforce that particular MAC
policy?

Or even aside from the appliance model, what if the server OS doesn't
support the same MAC models as the clients, e.g. FreeBSD server and
Linux clients or vice versa?

>  - some other OOB mechanism?  (identd, anyone?)

Network interface can also be a basis, in combination with the IP
address block.

-- 
Stephen Smalley
National Security Agency

---

From: <[email-masked]>
Date: Wed, 18 May 2011 09:03:28 -0400

Nico,

> server do for determining subject label?  How does such a server

See the virtualization "security perimeter" example later in message
where the MAC policy is a very simple all-or-nothing access policy
based on an inferred client subject label (the example uses IP address
block as the means of inference).  IMHO, partial MAC support (3)
requires the object label support in (2).  The elements of the (1)-(4)
list were intended to be increasing functionality in order - I should've
said so in the message.

> effort specifying something we don't actually need?

The basic object label support in (2) is the baseline for building MAC
functionality in the server (i.e., no object labels -> no MAC, we agree
on this).  Beyond that, implementers can make a variety of choices for
partial MAC (3).  Also, see Stephen Smalley's message - I agree with
Stephen that your "we don't actually need" statement about the basic
object label support (in a server implementation that does *nothing*
else for MAC) is wrong.

> protocol changes -- just configuration and conventions.

I also agree with this, and the way to get there is to spec the basic
object label support (2), and describe the opportunities to do partial
MAC to encourage implementers to be creative in helping out MAC clients.
Some of the text about smart servers can imply that there are no options
between the basic object label support and a full MLS/MAC server - that
implication is not good, as it discourages LNFS implementation in servers.

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Tuesday, May 17, 2011 8:08 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [nfsv4] LNFS - a fourth (!) type of server wrt MAC functionality
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 May 2011 11:01:10 -0500

> list were intended to be increasing functionality in order - I should've

I gathered that subject labels were to be derived.

But what about object labels?

> implication is not good, as it discourages LNFS implementation in servers.

(Too many options are also discouraging.  But let's ignore that for now.)

Let's put it another way: for the VM case, I think a strong share ACL
model is just as good as a MAC model -- indeed, a strong share ACL
model _is_ a kind of MAC model, a very basic kind, yes, but a MAC
nonetheless.

If object labels derive from shares and subject labels derive from
{client IP, RPC sec identification/authentication, server interface}
then what you have requires no protocol extensions, and it's feasible
today, and indeed, has been done.

Nico
--

---

From: <[email-masked]>
Date: Wed, 18 May 2011 12:53:26 -0400

Need explicit support so these can be set by clients:

> > IMHO, partial MAC support (3)

Thanks,
--David

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 18 May 2011 12:37:12 -0500

> implication is not good, as it discourages LNFS implementation in servers.

We seem to get dragged down into discussions about whether we
should or should not be considering something, usually along the
lines of whether something is part of the protocol or the security
system. We need to be clear that we are providing a set of changes
for the protocol, but the security systems provide the requirements
for those changes.

While a label aware server may not be very interesting once fully smart
servers become available, it will bridge the gap until then. It can
also help us understand issues that will arise as we see heterogeneous
DOIs interact. Do we need to solve all of those problems now? No.
Should we try to lay the groundwork for solving those issues later?
Sure.

A label aware server is an LFS implementation. When we want to describe
the way it works, we should do so in the context of that LFS. We tend to
mix that description in with the rest of our text. I.e., we tend to mix our
development of LNFS up with LFS.

My point here is that if you want to describe how a label aware server
should act, then you MUST describe the corresponding LFS. 

I'm perfectly fine with doing that in our I-D, as there are no preconceived
notions about what it does, it allows us a sounding
board to test the design. Also, it provides a nice progression for
a server implementor to debug and deploy a system:

1) it adds labels
2) it can add a very simple label check

Using the notion LFS {LFS #, PI #}, we can describe the following:

LFS {0,0} - a label aware server that accepts label changes and
returns the label to clients that ask for it. If the label changes, it
will use a CB to inform any clients which have it open.  The default
label applied to an object is {0, 0}. Both dumb and smart clients
are allowed access.

LFS {0,1} - a label aware server that accepts label changes and
returns the label to clients that ask for it. If the label changes, it
will use a CB to inform any clients which have it open. The
default label applied to an object is {0, 1}. Dumb
clients are not allowed access. 

We see that these definitions are based on a set of requirements
we imposed on LNFS:

1) labels sent/received in the protocol
2) labels persistently stored on the server
3) a means for the server to inform a client that a label on a file it
has open has changed
4) each object always has a label

Further, we see a new requirement, that the server be able to
differentiate between a dumb and a smart client. That necessitates
a change to what LNFS needs to be prepared to do.

While a single bit in EXCHANGE_ID will suffice to let the server
(and client) know smart versus dumb, it is easy enough to
predict some DOI might want to explicitly state which LFS
was being supported, hence EXCHANGE_LABEL.

Indeed, we could envision LFS {0,2} which is LFS {0,1} with the
modification that we only accept smart clients with a particular
label. The details of how the server is modified to get that
configuration are implementation specific.

The proposal is to use the same format for the parameters
for EXCHANGE_LABEL as SETATTR and GETATTR do
in order to simplify things. The client and server will know how
to parse this already. If we used a schema (with LDAP or XML)
then we have added complexity and/or the requirement for
another port to be open across a firewall.

---

From: <[email-masked]>
Date: Wed, 18 May 2011 14:31:52 -0400

Hi.

I agree that the first three requirements are protocol requirements.

I don't agree about the fourth and beyond.  Those seem like properties of a server implementation and an associated LFS implementation, simple or not.  Perhaps this might be fodder for inclusion into a security considerations document, but I'd rather they not be included in the protocol specification document.

The EXCHANGE_LABEL seems like an optimistic thing to add, since we don't actually know of any systems which require such.  I am a little bothered by it because it seems like a step towards a negotiation for DOI between client and server which may or may not be adequate.  We can only imagine what the actual requirements may be and then hope that they are covered by the semantics of this operation.

For example, I could imagine a situation, sort of like one of the SELinux use cases, where SELinux is used to restrict what something like the firefox browser is able to access in the local namespace to a subset of what the user, running the browser, might be able to access with other tools.  I could imagine this being useful on top of a different MAC subsystem that controls what the user can see in the local namespace.  This might imply multiple object labels with different DOIs, which we do have support for.  However, I don't immediately see how EXCHANGE_LABEL would work in this situation.

(Security people, don't get hung up in the example and feel the need to explain why this couldn't or wouldn't happen in current deployments, please.)

The bottom line for is that I'd like to see this specification be kept as simple as possible for NFSv4.2.  If the support was discovered to be not complete enough, with some implementation and deployment experience, then and only then, we could enhance it as appropriate.

	Thanx...

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Wednesday, May 18, 2011 1:37 PM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] LNFS - a fourth (!) type of server wrt MAC functionality

1) it adds labels

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 May 2011 14:47:14 -0500

> I agree that the first three requirements are protocol requirements.

That's in response to Thomas' list, I gather.

> I don't agree about the fourth and beyond.  Those seem like properties of a server implementation and an associated LFS implementation, simple or not.  Perhaps this might be fodder for inclusion in…

Well, objects need labels in a MAC environment.  Whether the server or
filesystem store object labels as such or do something else such that
objects appear to be labeled, is a either an implementation-specific
issue or an LFS-specific issue.

> The EXCHANGE_LABEL seems like an optimistic thing to add, since we don't actually know of any systems which require such.  I am a little bothered by it because it seems like a step towards a negoti…

Agreed.  I don't like it.  At best I think a "list {LFS, DOI}s
supported" operation would do.  But really, how clients and servers
agree on policy will depend.

Preferably policy should signaled primarily by the authentication
mechanisms carrying suitable authorization information -- think of
Kebreros ticket authorization data, or PKIX certificate extensions,
bearing label sets/ranges that the principal is allowed to assert
labels from, or else think of distributed configuration that allows
for local derivation of subject label sets/ranges from their principal
names.  A policy agreement solution at the authentication layer
completely sidesteps the need for an operation in the protocol.  We're
not the first to consider this!  The IPsec/IPsecme WGs have worked on
such a solution for labeled IPsec, for example.

If we do something that's very NFS-specific, then we're failing to do
something that works well with other Internet protocols.  NFS is not
the only Internet protocol (I know, what a newsflash :).

I realize that stepping out of the NFS protocol must seem like a sure
way to achieve nothing.  But I don't think that's necessarily, or even
likely true.  And the alternative risks producing something that
doesn't work well with other protocols -- something that seems to me
like a sure way to ask for trouble in IESG reviews and IETF Last
Calls.

> The bottom line for is that I'd like to see this specification be kept as simple as possible for NFSv4.2.  If the support was discovered to be not complete enough, with some implementation and depl…

So here's all the possible documents I envision for labeled NFS (not
all would be required for some deployments):

a) An NFSv4.2 document describing the protocol extensions for
getting/setting object labels, the new callback, and semantics.
b) RPCSEC_GSSv3.

c) A non-NFS-specific document defining "LFS", "PI", "DOI", IANA
registries, minimal semantics.
d) A non-NFS-specific document setting out an abstract schema for
distributed MAC policy.
e) One or more non-NFS-specific document setting out concrete schemas
and distribution mechanisms for MAC policy.
    - LDAP
    - XML + NFS/HTTP/whatever as the access method
    - Kerberos, PKIX, SAML authz-data

Implementors could produce something with just (a) and (b), so don't
be scared.  I believe (c)..(e) are ultimately necessary for interop,
both amongst NFS implementors and beyond (remember, many NFS
implementors also implement SMB, WebDAV, SFTP, and so on, as well as
IPsec, Kerberos, PKI, etcetera).  To focus on NFS alone would be a
mistake; to focus on NFS first would be fine.

We might even want to spin up a new WG to kick (c)..(e) to, so this WG
doesn't have to worry about them too much.  I recommend this approach.

Nico
--

---

From: <[email-masked]>
Date: Thu, 19 May 2011 14:51:02 -0400

> > The EXCHANGE_LABEL seems like an optimistic thing to add, since we don't
> > actually know of any systems which require such.  I am a little bothered
> > by it because it seems like a step towards a negotiation for DOI between
> > client and server which may or may not be adequate.  We can only imagine
> > what the actual requirements may be and then hope that they are covered
> > by the semantics of this operation.
> 

I'm inclined to agree - in addition to Nico's suggestion for use of
authentication mechanisms for this purpose, I also concur with his comment
in another thread that the policy distribution mechanism ought to be the
place to provide assurance that the policy info was actually distributed:

> Since policy must be distributed in such cases, I don't really see the
> value of adding protocol elements to verify that clients and servers
> have the same policy.  Instead the policy distribution mechanism(s)
> must be robust and distributed.

I believe that MAC policy has to be centrally managed in most cases, and hence
I don't have a problem with an architectural assumption that there is coherent
MAC policy management across the clients and/or servers that implement MAC.

>     - Kerberos, PKIX, SAML authz-data

Two comments:

- The combination of (a) + (c) [object label functionality and label contents] needs to work without requiring (b) [RPCSEC_GSSv3], but with some functional restrictions (e.g., if there are subject labels, they are client-scoped).  I believe that we've agreed to this - RPCSEC_GSSv3 is optional, but there is RPCSEC_GSSv3 functionality (e.g., per-RPC subject label transfer) that will not be duplicated elsewhere.

> doesn't have to worry about them too much.  I recommend this approach.

IMHO, an initial version of (c) that works with NFSv4.2 probably needs to be done here (doesn't have to be NFS-specific, but does have to mesh with the 4.2 doc[s]), and subsequent extensions can be done elsewhere (e.g., initial version does not have to have comprehensive label format coverage, as long as it sets up the IANA registry).

Thanks,
--David

> Sent: Wednesday, May 18, 2011 3:47 PM
> To: Staubach, Peter
> Cc: [email-masked]; Black, David; [email-masked]
> > I don't agree about the fourth and beyond.  Those seem like properties of a server implementation
> and an associated LFS implementation, simple or not.  Perhaps this might be fodder for inclusion into
> a security considerations document, but I'd rather they not be included in the protocol specification
> document.
> 
> > The EXCHANGE_LABEL seems like an optimistic thing to add, since we don't actually know of any
> systems which require such.  I am a little bothered by it because it seems like a step towards a
> negotiation for DOI between client and server which may or may not be adequate.  We can only imagine
> what the actual requirements may be and then hope that they are covered by the semantics of this
> operation.
> 
> > The bottom line for is that I'd like to see this specification be kept as simple as possible for
> NFSv4.2.  If the support was discovered to be not complete enough, with some implementation and
> deployment experience, then and only then, we could enhance it as appropriate.
>

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 19 May 2011 14:05:25 -0500

>> registries, minimal semantics.

DOI should be something we reference from another I-D, no?

> In order to get 4.2 done, we are going to need at least the initial version of (c), as (IMHO), interoperability based solely on opaque labels won't fly in the IETF, so I would modify Nico's suggest…

And we have an initial cut of that document already:

http://tools.ietf.org/html/draft-quigley-label-format-registry-00

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2011 16:08:34 -0500

> MAC policy management across the clients and/or servers that implement MAC.

Agreed.

> - The combination of (a) + (c) [object label functionality and label contents] needs to work without requiring (b) [RPCSEC_GSSv3], but with some functional restrictions (e.g., if there are subject…

NFS on Solaris TX works with neither extensions for object labeling
nor subject labeling in the protocol.  I believe that should be enough
to convince anyone that having only one or the other of object or
subject labeling in the protocol will also work.  Agreed?

That said, I urge implementors to implement RPCSEC_GSSv3.  Not having
it is quite limiting.  And I don't see much rationale for not
implementing it.  On the server side it should be simple enough.

> IMHO, an initial version of (c) that works with NFSv4.2 probably needs to be done here (doesn't have to be NFS-specific, but does have to mesh with the 4.2 doc[s]), and subsequent extensions can be…

Anyone can submit an I-D for this.  And if the NFSv4 WG charter can be
interpreted as covering this work, then such an I-D could be an NFSv4
work item.  Whether it then moves elsewhere, or progresses in this WG
but with input from elsewhere, isn't a terribly important detail.

Nico
--