Subject: [nfsv4] Labeled NFS: Per-client subject label functionality

From: <[email-masked]>
Date: Thu, 23 Jun 2011 21:29:53 -0400

>From the call minutes:

> David provided this taxonomy:

> Dumb - can't spell Label
> Label aware - passes/stores object labels, calls back label changes on open files
> Semi-smart - Implicit or explicit subject label for the client. Could set once. 
> Fully-smart - Subject label per compound - i.e., per users or process on the client
>
[... snip ....]
>
> We had consensus in the room for David to provide a high overview of
> how a semi-smart implementation could work, i.e., do we need an op,
> to the WG alias. There we will drive towards consensus.

This discussion of what the server does can be is confusing, so I'm going to
phrase this in terms of protocol functionality, starting with reminders about
subject and object labels:

- Object labels are for entities that are accessed (e.g., files, directories).
- Subject labels are for entities that perform access:
	o Per-Client subject labels are for NFS clients
	o Fine-Grain subject labels are for users, processes, or whatever.

For now I want to assume that the two subject label options are mutually exclusive.
While subject labels don't require object label support, our labeled NFS use cases
generally require object label support.

With that foundation, here are the four interesting (IMHO) options for label
functionality in the NFS protocol:

1) No labels (e.g., Dumb server): No label functionality on the wire.
2) Object labels (e.g., Label-aware server): Object label functionality on the
	wire, no subject labels.
3) Per-Client subject labels (e.g., Semi-smart server): Client has a single
	label, which can be passed on the wire by the client.
4) Fine-Grain subject labels (e.g., Fully-smart server): RPCSEC_GSSv3 is used
	on the wire to pass per-COMPOUND subject labels.

The current Labeled NFS draft specifies 1 (obviously), 2 and 4.  This message is
about whether 3 (Per-Client subject labels) should have explicit protocol support
for NFS clients that don't use RPCSEC_GSSv3 to pass Fine-Grain subject labels.

The baseline is that servers that enforce MAC policy are often capable of inferring
a subject label for a client that doesn't pass subject labels. A simple example is:

- Configuration setup: All the clients that should access this server are in
	IP address block X.Y.Z.* (e.g., via static IP addresses or careful
	configuration of DHCP).
- MAC Policy: The server only permits access to clients in that IP address block.

That was way too fast because you didn't see the inferred labels :-), but they're
in there, really ... :

- Server Label inference: If client is in X.Y.Z.* address block,
	Then Client subject label = "Good".
	Else Client subject label = "Bad"
- Server MAC Policy enforcement:
	Subject label = "Good" -> full access
	Subject label = "Bad" -> no access

Far more complex client subject label inference is possible, as has been described
on this list in the past, and the subject labels can be input into significantly
more complex MAC policies.  The protocol support question is whether inference is
"good enough" for Per-Client subject labels, or whether we should enable clients
to explicitly pass a per-client subject label.

The ability for clients to pass per-client subject labels may simplify otherwise
complex configuration of label inference, and allows more direct verification that
the client is operating at the level intended (label says what should happen, one
can check that the label the client believes it sent matches the label that the
server is using for the client).

The security aspects of this are somewhat subtle, as the server can't trust a
client-generated subject label without additional assurances, otherwise any client
can supply any label it wants.  The assurances and corresponding levels of server
trust in client-generated labels (both subject and object labels) are the
responsibility of the security administrator(s) for the site (this is how labeled
NFS works).   The server's security policy can do whatever it wants with client
subject labels (they're an input to policy decisions).

The implementation proposal is to add an optional operation (e.g., SET_LABEL)
between EXCHANGE_ID and the first CREATE_SESSION that provides the client's
subject label.  I think this has to be an operation because the client doesn't
have a handle that it can use for SETATTR at this early stage.  The server
implementation is that *if* SET_LABEL is supported, then the client's subject
label becomes the 6th element of the server's client record (see 18.35.4 in
RFC 5661).  SET_LABEL would not be allowed at any other time; functionality
beyond setting the client label once after EXCHANGE_ID should use RPCSEC_GSSv3.

The following cases should be rare and hence need simple, robust responses:
- If SET_LABEL results in an error, the server destroys the client record.
	The client's first CREATE_SESSION will fail, and the client has to
	start over with another EXCHANGE_ID.
- If the client wants to change its label, it has to start over with
	another EXCHANGE_ID to create a new client record on the server.
- If server needs to change or revoke the client label, it invalidates the
	client record and client ID.  This looks like a server restart to
	the client.
- If SET_LABEL has been used, any attempt by the same client to pass a
	subject label via RPCSEC_GSSv3 is an error.

SET_LABEL might also be a useful place to pass a default object label (i.e.,
the label to use for objects created by this client for which the client does
not set an explicit object label).  That might be helpful in relaxing requirements
for clients to explicitly set object on all created objects.  If this was done,
it would extend the server's client record to a 7-tuple.

So the question to the WG is:

	Is a one-time SET_LABEL operation useful enough for Per-Client
	subject labels (by comparison to server inference of Per-Client
	subject labels) to be included in the Labeled NFS work?

The meaning of "one-time" is "between EXCHANGE_ID and the first CREATE_SESSION".

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: Thu, 23 Jun 2011 21:10:35 -0500

>> Fully-smart - Subject label per compound - i.e., per users or process on the client

For the last two, the subject label *always* has to be determined by
the server on a per-compound basis.  This can be *cached* so that most
of the time there's no additional computation.  if RPCSEC_GSSv* is
used then the server can cache the label with the RPCSEC_GSS context
handle.  If RPCSEC_GSS is not used it gets trickier.

Note that it's also possible to have several levels of label awareness
on the client side.  We need a taxonomy for that too.

>        o Fine-Grain subject labels are for users, processes, or whatever.

Fine-grained subject labels are always going to be for executing
entities.  Every OS that matters has processes and even threads, and
all have at least per-process credentials, sometimes also per-thread
credentials.  It is possible to phrase this in a technology neutral
manner, something like "... of the executing entity".

> For now I want to assume that the two subject label options are mutually exclusive.

For now...  But note that they are not mutually exclusive.  A server
could do per-client subject labels for RPCSEC_GSSv1/2 clients, and
per-process for v3 clients.

> generally require object label support.

MAC requires labels on objects and subjects both, at all times.  You
might have implicit object labels (e.g., all objects in a given file
system are at the same label).

> 1) No labels (e.g., Dumb server): No label functionality on the wire.

Note that clients can still label objects using naming conventions.

> 2) Object labels (e.g., Label-aware server): Object label functionality on the

This requires that smart clients know to enforce MAC all on their own.

>        label, which can be passed on the wire by the client.

I don't see why the client should determine its whole-client label in
any use case.

>        on the wire to pass per-COMPOUND subject labels.

In both, (3) and (4) the server has to apply policy, both to make
access decisions, and to decide what label a subject is at.  It's OK
to take into account assertions from the client, but the server has to
have local policy (even if it is to say that all client assertions are
accepted, except that this isn't useful for any kind of smart server).

> for NFS clients that don't use RPCSEC_GSSv3 to pass Fine-Grain subject labels.

I disagree.  For (3) the server should use configuration.  If you want
dumbish, you get dumbish.

Nico
--

---

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

Nico,

Extracting selected pieces ...

> per-process for v3 clients.

We may be in semi-violent agreement.  By mutually exclusive, I meant that a single
client's interaction with a server uses either per-client subject labels or fine-grain
subject labels, but not both at the same time for a single client ID.  I agree
that a server should be able to use per-client subject labels with some clients and
fine-grain subject labels with other clients.

> accepted, except that this isn't useful for any kind of smart server).

I agree that local policy is necessary - the question around (3) is whether it's
additionally useful for a client to be able to pass a client-scoped assertion in
the form of a label in addition to whatever the server may use as implicit
assertions (e.g., client's IP address).

Your opinion is that it is not useful, and client subject label inference

> dumbish, you get dumbish.

Thanks for answering the question.

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Thursday, June 23, 2011 10:11 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [nfsv4] Labeled NFS: Per-client subject label functionality
>

---

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

Thanks for the thread of discussion (seems familiar).

We have two documents that seemed to have merged:
draft-quigley-nfsv4-labeled-03.txt
draft-quigley-nfsv4-sec-label-requirements-03.txt

I would like to keep those two documents.  The requirements
document should be targeted as Informational RFC and the
working group should fold this discussion (and others like it)
into the requirements document with the various use cases
and any other history need to effectively close on this
topic.  The requirements document should move forward within the
IETF ahead of the NFSv4.2 work.

The "labeled" document then should be completed for the
protocol modifications only; when appropriate it can
be included into the NFSv4.2 I-D.

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, June 24, 2011 7:39 AM
> To: [email-masked]
> Cc: [email-masked]
> We may be in semi-violent agreement.  By mutually exclusive, I meant that
> a single client's interaction with a server uses either per-client subject
> labels or fine-grain subject labels, but not both at the same time for a
> single client ID.  I agree that a server should be able to use per-client
> subject labels with some clients and fine-grain subject labels with other
> clients.
> 
> I agree that local policy is necessary - the question around (3) is
> whether it's additionally useful for a client to be able to pass a client-
> scoped assertion in the form of a label in addition to whatever the server
> may use as implicit assertions (e.g., client's IP address).
> 
> > >> Label aware - passes/stores object labels, calls back label changes
> > >> on open files Semi-smart - Implicit or explicit subject label for the
> client. Could set once.
> > >> We had consensus in the room for David to provide a high overview
> > >> of how a semi-smart implementation could work, i.e., do we need an
> > >> op, to the WG alias. There we will drive towards consensus.
> > >
> > > This discussion of what the server does can be is confusing, so I'm
> > > going to phrase this in terms of protocol functionality, starting
> > > with reminders about subject and object labels:
> > >
> > > While subject labels don't require object label support, our labeled
> > > NFS use cases generally require object label support.
> >
> > > With that foundation, here are the four interesting (IMHO) options
> > > for label functionality in the NFS protocol:
> > >
> > > The current Labeled NFS draft specifies 1 (obviously), 2 and 4.
> > > This message is about whether 3 (Per-Client subject labels) should
> > > have explicit protocol support for NFS clients that don't use
> RPCSEC_GSSv3 to pass Fine-Grain subject labels.
> >
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: sfaibish <[email-masked]>
Date: Fri, 24 Jun 2011 11:17:53 -0400

On Thu, 23 Jun 2011 21:29:53 -0400, <[email-masked]> wrote:

> going to
This SET_LABEL case is going also to solve the root access problem I
guess. If so we should include it in the I-D.

/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 11:41:10 -0400

> guess. If so we should include it in the I-D.

Yes, SET_LABEL will solve that problem when RPCSEC_GSSv3 is not used.

SET_LABEL occurs before any client I/O and hence allows the server to
make an access control decision before any I/O occurs.  If the client's
SET_LABEL is not acceptable to the server, the client will fail to connect
because the client's first CREATE_SESSION will fail.

Thanks,
--David

> From: sfaibish [mailto:[email-masked]]
> Sent: Friday, June 24, 2011 11:18 AM
> To: Black, David; [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Jun 2011 11:03:35 -0500

> from configuration suffices:

Hmmm, no, my opinion is that it's not useful to add extensions for
non-RPCSEC_GSSv3 clients.

It's basically necessary for the client to tell the server about
fine-grained subject labeling (we could have fine-grained GSS
credentials, but that'd be really hard to pull off, so I'm not even
proposing it).

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 24 Jun 2011 11:05:22 -0500

> Yes, SET_LABEL will solve that problem when RPCSEC_GSSv3 is not used.

I still haven't seen a good definition of the "root access problem". I.e., it isn't
mentioned in the LNFS document.

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 24 Jun 2011 11:14:46 -0500

> non-RPCSEC_GSSv3 clients.

Do we know whether in today's environments, if when we have Smart
clients talking to Dumb servers, if RPCSEC_GSSv[1|2] is always being
used?

I.e., are we going to be mandating an approach that is currently
not deployed at sites?

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 24 Jun 2011 16:26:42 +0000

Let's put a place holder in the requirements I-D for this one to ensure
the results are captured.

Spencer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Friday, June 24, 2011 9:05 AM
To: <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Labeled NFS: Per-client subject label functionality

On Jun 24, 2011, at 10:41 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
--David

---

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

> That was way too fast because you didn't see the inferred labels :-), but they're

I accept that they're in there, but that I'm probably not authorized 
to see them :-).

>	client record and client ID.  This looks like a server restart to

One thing that happens on server restart is client reclaim of opens.  Clearly, 
the access decision made on the reclaim has to use the new label.  If you don't 
have access with that new label, no reclaim for that file.  But are there 
other issues?  If I can access it with the new label, am I OK? Can information 
Leak between the original open and the reclaim?  Or are we always OK if both 
labels can access the file?  Does this just look like a new open from  security 
point of view?

The protocol now goes to some effort (at least in delineating "edge conditions")
to assure that the client that he may infer that the file did not (for example) 
change while it was opened with deny=write (and that open includes the original open,
the reclaim, and everything in between.

Is here an issue here, that needs to be addressed?  Are there more edge 
conditions in store?   I guess that since this isn't a server restart but 
only looks like one, the client will get NOGRACE.  Unless this label change
Happens within the grace period after server bringup. Ouch!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 23, 2011 9:30 PM
To: [email-masked]
Subject: [nfsv4] Labeled NFS: Per-client subject label functionality

[... snip ....]

Thanks,
--David

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Jun 2011 13:14:45 -0500

> I.e., are we going to be mandating an approach that is currently

You know full well that most people still use AUTH_SYS.  Remember,
RPCSEC_GSSv3 is also intended to replace AUTH_SYS.  We could have an
option to not use *any* security mechanisms other than the "privileged
ports" one.

SET_LABEL is a band-aid, and if it's particularly intended for the
single-label client case then it is singularly pointless -- the server
should just know the client's label in that case.

And as for SET_LABEL for fine-grained subject labeling, well, that's
just an argument that RPCSEC_GSSv3 is too hard -- an argument that I
thought we had disposed of.

Here's the thing: if you want anything better than dumb clients then
you must deploy new code.  Deployment is what's hard here.  An
in-between mode will only mean *two* deployments, not one.  Why are we
taking a position that will require additional expense by the
customers?

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 24 Jun 2011 13:34:21 -0500

On Jun 24, 2011, at 1:14 PM, Nico Williams wrote:

> 
> You know full well that most people still use AUTH_SYS.

I know full well in most corporate settings that this applies.

I am clueless about settings which employ MLS, iTar, etc.

I am not trying to ask a leading question here.

>  Remember,
> RPCSEC_GSSv3 is also intended to replace AUTH_SYS.

I don't think this comes across strongly enough in the RPCSEC_GSSv3
draft. I.e, I just re-read the Security Considerations and I didn't see
how. It does state that it can be used, but I am not connecting the
dots between seeing AUTH_SYS and knowing it is using
RPCSEC_GSSv3.

As an individual, if all security flavors *can* use RPCSEC_GSSv3,
then I would say the subject label always has to be presented in that
manner.

NFSv2, NFSv3, and NFSv4.x < 2, will all access server objects
without setting an explicit subject label. I.e., there is no method
to explicitly set it in the protocol. If all security flavors can leverage
RPCSEC_GSSv3, then these protocols would be able to
present a subject label, even though the protocols do not support
labels.

That sounds interesting.

---

From: <[email-masked]>
Date: Fri, 24 Jun 2011 14:33:58 -0400

> taking a position that will require additional expense by the

That's a strawman demolition exercise, IMHO.  My stated intent for
SET_LABEL is that it's used once by the client to set its subject label,
period.

While I wouldn't use all of Nico's words above, I definitely agree that
fine-grain subject labels (any finer grain than per-client) should use
RPCSEC_GSSv3.

Thanks,
--David

> Sent: Friday, June 24, 2011 2:15 PM
> To: Thomas Haynes
> Cc: Black, David; [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Jun 2011 13:58:45 -0500

> I am clueless about settings which employ MLS, iTar, etc.

Hmmm, I don't know.  I would imagine that if you want MLS, chances are
you also want *real* security, not a "secure bit".  Labels on the wire
without cryptographic security is no better than a "secure bit".

> I am not trying to ask a leading question here.

Sorry I thought that :(

> dots between seeing AUTH_SYS and knowing it is using

AUTH_SYS includes identity assertions, just like AUTH_SYS, only using
name@domain instead of UIDs and GIDs.

I put that there specifically to solve problems that AUTH_SYS can but
RPCSEC_GSSv1/2 cannot.

We should probably add text calling this out specifically.

> then I would say the subject label always has to be presented in that

It'd be trivial to define either a non-cryptographic GSS mechanism to
replace AUTH_SYS with, or to add an option for the same to
RPCSEC_GSSv3.

> present a subject label, even though the protocols do not support

Exactly!  That's my point.  We have an abstraction for security in
NFS: it's the RPCSEC layer.

If RPCSEC (any flavor) is no longer suitable, then sure, SET_LABEL and
many other new operations (or one big one) would be the Right Answer
(tm).

It's this half-way thing we're considering that gives me the

> That sounds interesting.

I think so too :)

Nico
--

---

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

Dave,

>From a design perspective, the fact that the M in MAC stands for Mandatory helps ;-).

> have access with that new label, no reclaim for that file.

Yes.

> But are there other issues?  If I can access it with the new label, am I OK?

Yes.

> Can information Leak between the original open and the reclaim?
> Or are we always OK if both labels can access the file?

The latter - every reclaim under the new client ID has to be checked against the
new subject label for that new client ID.  If that check succeeds, the client still
has access to the file.

> Does this just look like a new open from security point of view?

That works, and is a good starting point. This sort of label revocation should
be a rare event, and the "Right now, I mean it!" aspect of revocation may make
disruptive side effects acceptable.

> Happens within the grace period after server bringup. Ouch!

I would leave the issue of whether to allow grace after revocation to server
implementers.  The simplest approach is that client subject label revocation
is never grace-ful.

The security requirement is that all access via the new client ID be checked
against the new subject label for that client ID.

Thanks,
--David

> From: Noveck, David
> Sent: Friday, June 24, 2011 1:31 PM
> Subject: RE: Labeled NFS: Per-client subject label functionality
>

---

From: Rick Macklem <[email-masked]>
Date: Fri, 24 Jun 2011 16:21:43 -0400 (EDT)

> replace AUTH_SYS with, or to add an option for the same to
Btw, I think that a trivial authentication flavour that simply
provides a "user name" in clear text like:
AUTH_NAME
  [email-masked]

would be useful. I think a lot of sites are comfortable with
providing their "on the wire" security via mechanisms like ipsec/vpn's.
When they do that, it would be nice if they could move away from
POSIX style uid, gids without implementing Kerberos.

If such a flavour was done, it sounds like it should be able to
carry subject labels as well as a user name.
(ps: No, I'm not volunteering to write this up. If it were written
 up, I would probably implement it for FreeBSD.)

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 Jun 2011 17:31:37 -0500

>> >> RPCSEC_GSSv3 is also intended to replace AUTH_SYS.
...
>> I put that there specifically to solve problems that AUTH_SYS can but
...
> POSIX style uid, gids without implementing Kerberos.

RPCSEC_GSSv3 *can* do that, since it allows the client to make
assertions about the process' credentials in the form of usernames,
group names, privileges in effect, label, ...  If all you want is an
assertion of just a username and a label, well, it can do that as
specified.  Well, could, if we added the option to not use a GSS mech
or if we added a no-op GSS mech.