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

From: <[email-masked]>
Date: Tue, 5 Jul 2011 17:05:09 -0400

In response to my original posting on this topic, I've seen a lot of discussion, but
no support for adding SET_LABEL to Labeled NFS.  That suggests that this operation is
not needed, at least not for the initial version of Labeled NFS.

OTOH, we do need to make sure that the use of configuration-based information (e.g.,
IP address, VLAN tag) to infer a subject label is explained.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Thursday, June 23, 2011 9:30 PM
> To: [email-masked]
> Cc: Black, David
> Subject: Labeled NFS: Per-client subject label functionality
> 
> 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: Thomas Haynes <[email-masked]>
Date: Wed, 6 Jul 2011 10:52:32 -0500

Can someone summarize what we did decide on the mailing list?

On Jul 5, 2011, at 4:05 PM, <[email-masked]> <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Wed, 6 Jul 2011 14:53:25 -0400

> Can someone summarize what we did decide on the mailing list

Ok Tom, now you owe me at least one adult beverage :-).

Two areas of client label functionality:
1) Object labels: Set them (attribute), receive label change call backs
2) Subject labels: Assert via RPCSEC_GSSv3

These two areas of client functionality are independent - each can be
used by a client that does not use the other, although in practice a
client that is asserting subject labels will probably also use object labels.

Two areas of server label functionality:
1) Object labels: Store and return labels, send label change callbacks
2) Subject labels: Receive RPCSEC_GSSv3 label assertions

These areas are independent in the protocol specification, but interact because
full MAC policy enforcement by a server requires both subject and object labels.
This results in two types of servers:

A) Label-aware servers.  Implement object label functionality, do not
	support RPCSEC_GSSv3 label assertions, or ignore subject labels
	if asserted via RPCSEC_GSSv3.
B) Policy-enforcing servers.  Enforce some form of MAC policy.  May or may
	not implement RPCSEC_GSSv3.  May or may not implement object label
	support, but will probably implement object label support in practice.

Note that some simple forms of MAC policy do not require object labels for
files and directories (e.g., a policy that only NFS clients in a specific
IP address block are allowed to access a specific exported FS).

An important security function of policy-enforcing servers is subject label
inference when working with clients that do not provide RPCSEC_GSSv3 subject
labels (e.g., in the simple example, clients in the IP address block get one
subject label, clients outside it get a different label, and only the first
label authorizes filesystem access).  This has to be discussed as part of
the security considerations.

Thanks,
--David

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 6 Jul 2011 13:59:14 -0500

> Ok Tom, now you owe me at least one adult beverage :-).

I'll give you two, because another question would be, what changes
are necessary to the proposal?

My take is none, other than your request that we call out subject label
inference in a little more detail.

Agreed?

---

From: sfaibish <[email-masked]>
Date: Wed, 06 Jul 2011 15:41:57 -0400

So you dropped the SET_LABEL. Do we have enough language to explain how
to use IP screening or similar to address the root problem? Just
checking as I was not convinced there was a final decision that
SET_LABEL idea is removed. I send my support in favor of adding
SET_LABEL unless somebody convinces me that the root problem can
be solved by other means especially in the usecase of virtualization.

/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: Wed, 6 Jul 2011 17:23:34 -0400

> > the security considerations.

We don't have that language yet, so it will need to be added.  Nico sent an email
a while back listing a whole bunch of things that Trusted Solaris can use to
infer subject labels for single-level clients.

Thanks,
--David

> From: sfaibish [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2011 3:42 PM
> To: Black, David; [email-masked]
> Cc: [email-masked]
> Subject: Re: [nfsv4] Label functionality
>

---

From: <[email-masked]>
Date: Wed, 6 Jul 2011 17:27:31 -0400

> inference in a little more detail.

I think that's the only technical matter that needs attention.

I think it would also be good to take a step back, and discard the notions of
smart/semi-smart/dumb servers and/or clients in favor of structuring the
discussion in functional terms with a primary focus on the areas of protocol
functionality.  I've taken a first step in that direction in the summary below.

Thanks,
--David

> From: Thomas Haynes [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2011 2:59 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: Label functionality
> 
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jul 2011 16:35:55 -0500

> functionality.  I've taken a first step in that direction in the summary below.

+1.

You've already done this, but to summarize it's a question of support
for object labels, subject labels, and MAC enforcement, and this
applies to clients and servers -- a 2x3 matrix.

Nico
--

---

From: sfaibish <[email-masked]>
Date: Wed, 06 Jul 2011 19:59:37 -0400

If I may be brutal than usual I would prefer to have a protocol that
will define the labels using the SET_LABEL rather than counting on
implementation optimizations (using IP masking or similar) around
who can have access and who cannot access a labeled object for
semi-smart servers. This will allow to address in a consistent way
the LNFS implementations at the expense of a little more complexity
and work for us (I mean Tom mostly) in 4.2. But if this will endanger
LNFS not making the 4.2 I will give up. But I would very much be sure
that whatever makes 4.2 will support all the virtualizatuion usecases.

/Sorin

-- 
Best Regards

Sorin Faibish

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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 06 Jul 2011 20:23:07 -0400

> that whatever makes 4.2 will support all the virtualizatuion usecases.

Why? The reason why it was dropped is because nobody was able to find a
killer application for it, and I see nothing in the above paragraph that
addresses that lack of purpose.

We can add SET_LABEL to the protocol later if we do find a use for it.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: "Sorin Faibish" <[email-masked]>
Date: Wed, 06 Jul 2011 21:16:40 -0400

> addresses that lack of purpose.
Let's discuss this tomorrow during the LNFS meeting.

/Sorin

>> > functionality.  I've taken a first step in that direction in the  
>> summary
>> > below.
>> >
>> > Thanks,
>> > --David
>> >
>> >
>> >> > client that is asserting subject labels will probably also use  
>> object
>> >> labels.
>> >> >
>> >> > An important security function of policy-enforcing servers is  
>> subject
>> >> label
>> >> > inference when working with clients that do not provide  
>> RPCSEC_GSSv3
>> >> subject
>> >> > labels (e.g., in the simple example, clients in the IP address  
>> block
>> >> get one
>> >> > subject label, clients outside it get a different label, and only  
>> the
>> >> first

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]