Subject: [nfsv4] [LNFS] Meeting Minutes 04/14/11

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 14:33:43 -0500

Attendees:
---------------

Tom Haynes (NetApp)
Dave Quigley (davequigley.com)
Dan Walsh (RedHat)
Jarrett Lu (Oracle)
Sorin Faibish (EMC)
Peter Staubach (EMC)
Trond Myklebust (NetApp)
Kathleen Moriarty (EMC)
David Black (EMC)
Nico Williams (cryptonector.com)

(Note, the line was choppy at first and it was pretty windy here.
So if I missed your participation, please send me an email and
I'll add you to the list.)

Agenda
-----------

+ IETF Note Well Agreement

+ Use Cases

Kathleen presented the ITAR and Legal Hold use cases (see 
http://www.ietf.org/mail-archive/web/nfsv4/current/msg09349.html)

The consensus was that the current proposal is sufficient to support
these use cases.

We had a discussion about what goes in the label? Do we need
separate ones for Sensitivity and Criticality?

David Q pointed out that the current design allows anything to
go in the labels.

A major point also was that the security system decides on what
to use.

Sorin presented the Red Hat use cases (see
http://www.ietf.org/mail-archive/web/nfsv4/current/msg09347.html).

On list, Trond added another at http://www.ietf.org/mail-archive/web/nfsv4/current/msg09357.html

Again, the consensus was that the proposed implementation 
was sufficient to support these use cases.

A key point is that all we are proposing is a transport mechanism
to provide labels for the object and then via RPCSEC_GSSv3, the
subject. The use cases might require more work in the security
system, but at our level, what we provide will work.

We then discussed the size of the label, i.e. given

      struct sec_label_attr_info = {
        labelformat_spec4   slai_lfs;
        opaque              slai_data<>;
      };

what is the upper limit on slai_data?

We did agree that we do not want a limit imposed at the XDR level.

The limit will be imposed by the LFS being used. The implication
here is that if a particular implementation specifies a maximum
size of X, then the client knows it can safely send a label of size
X to the server.

Nico mentioned that an implementation might not want to
set a maximum limit. Everyone else disagreed.

A point lost in the conversation was error handling for labels.
We probably want a specific error to state something was
wrong with the format of the label. I.e., server says max it
will store is X, client provides X+1.

+ Dependency of LNFS on RPCSEC_GSSv3

We finally discussed whether LNFS could mandate that RPCSEC_GSSv3
was required or optional.

Nico presented a nice overview of the scenarios:

Smart client, Dumb Server - no need, existing state of most implementations
Dumb client, Smart Server - no need, rules for the subject are inferred
Smart client, Smart Server - a requirement. And this is the interesting case we want to develop.

Also lost in the conversation was David B's desire to discuss
how the label for the subject was inferred. Dave Q did
mention this was discussed in on of the drafts.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 14:40:58 -0500

> set a maximum limit. Everyone else disagreed.

I said something different: that it'd be OK with me that we say that
LFS specifications SHOULD specify a maximum label size instead of MUST
because I could imagine a labeling scheme where all labels are
manually configured and that in such schemes it'd be fine to leave max
label size to the administrator rather than the label spec.  It's
really not a big deal.

> will store is X, client provides X+1.

We can't have LFS-specific error codes unless we specify error code
allocation rules for this.  But EINVAL is almost certainly good enough
for the set-object-label operation -- what else can it mean but that
the label is invalid?  The reasons that the label is invalid will vary
by label type and DOI.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 14:54:47 -0500

> label size to the administrator rather than the label spec.  It's

Ahh, a point I meant to bring up in the meeting, is it the administrator
setting up a max size or the author of the LFS specification?

I understood the point about having a fixed number of labels,
but I didn't understand why we would want to hand over control of
such a key configuration item to an admin.

The spec might specify that the max is 1k, but the site might
define at most a 400 byte max label.

> the label is invalid?  The reasons that the label is invalid will vary

I wanted a generic way to state that there was something wrong with
the mechanics of the label versus either the content or the enclosing
operation.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 15:47:38 -0500

> setting up a max size or the author of the LFS specification?

David B. wants it to be the LFS.  I want it to be the LFS if it
specifies one, else the admin.  But this is really not much to argue
over.  I'll gladly settle for David's proposal.

> define at most a 400 byte max label.

David's counter-argument would be that if the client can create new
labels then it's critical that the server not reject labels whose
length is within spec.  I agree with David on that.

> the mechanics of the label versus either the content or the enclosing

But what else could EINVAL possibly mean?  It's not like the
set-object-label operation takes many inputs: just the current FH
(implied, and clearly valid if the PUTFH or other such op that set it
succeeded) and the label.  EINVAL here can only possibly mean that
there's a problem with the label.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 15:58:48 -0500

> over.  I'll gladly settle for David's proposal.

I'll take that as settled.

> length is within spec.  I agree with David on that.

 Good, I think we all agree.

> there's a problem with the label.

But it could be combined with other attributes being set.

I'm willing to let this drop, I only have a preference, not a strong
requirement.

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 16:09:44 -0500

> But it could be combined with other attributes being set.

Oh, because label is an attribute...  Right!  Well...  Arguably
attributes whose values the server validates ought to have separate
error indications -- not separate error codes, mind you, but an error
code per-failed attribute.  The current SETATTR does that, sort of, by
sending a bitmask of attributes that were set in the result -- not
great in the case of labels, since the client can't know if the label
was not set because the server doesn't do labels or because there was
something wrong with the label.

Is that right?  If so, do we need a new flavor of SETATTR?

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 16:38:50 -0500

> Is that right?  If so, do we need a new flavor of SETATTR?

From 5661:

5.2.  RECOMMENDED Attributes

   These attributes are understood well enough to warrant support in the
   NFSv4.1 protocol.  However, they may not be supported on all clients
   and servers.  A client may ask for any of these attributes to be
   returned by setting a bit in the GETATTR request but must handle the
   case where the server does not return them.  A client MAY ask for the
   set of attributes the server supports and SHOULD NOT request
   attributes the server does not support.  A server should be tolerant
   of requests for unsupported attributes and simply not return them
   rather than considering the request an error.  It is expected that
   servers will support all attributes they comfortably can and only
   fail to support attributes that are difficult to support in their
   operating environments.  A server should provide attributes whenever
   they don't have to "tell lies" to the client.  For example, a file
   modification time should be either an accurate time or should not be
   supported by the server.  At times this will be difficult for
   clients, but a client is better positioned to decide whether and how
   to fabricate or construct an attribute or whether to do without the
   attribute.

So if the client sets the FATTR4_SEC_LABEL bit in the SETATTR request, then if
the server does not support LNFS, it will return NFS4_OKAY and that bit will be off
in the returned bitmask.

If there was an issue with some attribute other than the label, then a partial bitmask
will be returned. It may be the case that the FATTR4_SEC_LABEL bit is set or not.

If there is an issue with it, then it will be off in the result bitmask.

To make things easier, we might define that a compound with PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}
always succeeds if the server supports LNFS. The specific LFS would be responsible for
the contents of that object label.

---

From: sfaibish <[email-masked]>
Date: Thu, 14 Apr 2011 17:53:49 -0400

On Thu, 14 Apr 2011 15:33:43 -0400, Thomas Haynes <[email-masked]>  
wrote:

> On list, Trond added another at  
> http://www.ietf.org/mail-archive/web/nfsv4/current/msg09357.html
>
We agreed also that there is no need for an additional document/draft to
extend this case. I also proposed to include some text in the RPCSEC_GSSv3
mentioniong LNFS for this last case. Also if I am not mistaking we agreed
that for the first 2 use of RPCSEC_GSSv2 should be enough and only for the
last case v3 SHOULD be used. I might mis-spelled so Nico please correct me.

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

-- 
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: Nico Williams <[email-masked]>
Date: Thu, 14 Apr 2011 17:25:29 -0500

On Thu, Apr 14, 2011 at 4:38 PM, Thomas Haynes <[email-masked]> wrote:
> From 5661:
>
>
> So if the client sets the FATTR4_SEC_LABEL bit in the SETATTR request, then
> if the server does not support LNFS, it will return NFS4_OKAY and that bit will
> be off in the returned bitmask.

And the client can determine if the server supports LNFS by checking
the label attr in supported_attrs?  OK, then we probably don't need a
new error code.  But we might want or need a new error code to use
instead of NFS4ERR_ACCESS for the server to indicate denied by MAC
policy.

Nico
--

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 17:51:04 -0500

On Apr 14, 2011, at 4:53 PM, sfaibish wrote:

> On Thu, 14 Apr 2011 15:33:43 -0400, Thomas Haynes <[email-masked]> wrote:
>> 

I did forget that Sorin mentioned the multiple tenancy issue as well. I.e., we don't
want Ford and Chevy to rent space somewhere on the cloud and be able to spy
on each other's data.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 14 Apr 2011 19:13:55 -0400

> the server does not support LNFS, it will return NFS4_OKAY and that bit will be off

Actually I think that you're correct for GETATTR, but that the part
about the NFS4_OKAY return is not true for SETATTR.  (From the SETATTR
text: "If the server does not support an attribute as requested by the
client, the server SHOULD return NFS4ERR_ATTRNOTSUPP.")

(But that's a nitpick, I don't think it affects the argument.)

--b.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 14 Apr 2011 18:16:39 -0500

> (But that's a nitpick, I don't think it affects the argument.)

Agreed and thanks for pointing this out. It was bugging me a bit when I wrote
this, but not enough to track it down fully.

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 15 Apr 2011 09:48:09 -0500

> instead of NFS4ERR_ACCESS for the server to indicate denied by MAC

Does returning NFS4ERR_ACCESS (for DAC) or NFS4ERR_MAC_ACCESS
(for MAC) provide a confirmation to a malicious client that the object
exists?

---

From: sfaibish <[email-masked]>
Date: Fri, 15 Apr 2011 11:01:55 -0400

> (for MAC) provide a confirmation to a malicious client that the object
Moreover, does it provide confirmation for a malicious user/application
operating on the client? I assume that the client reinforce MAC on behalf
of the user but what if the user try to access directly not via the
client using the credentials?

-- 
Best Regards

Sorin Faibish

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

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 10:32:29 -0500

> (for MAC) provide a confirmation to a malicious client that the object

Yes, but that is only a reason for the server not to return the new
error, not a reason to not define it.  I know, that sounds weird, but
bear with me :)

The principle is that it should be possible to send detailed error
information for debugging purposes, yet also to send minimal error
information outside debugging scenarios.  It should also be possible
to choose to always send detailed error information -- the
convenience/security trade-off needs to be in the hands of the
sysadmin if minimal errors result in extreme inconvenience, though
hopefully extreme inconvenience will not happen.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 10:44:24 -0500

On Fri, Apr 15, 2011 at 10:01 AM, sfaibish <[email-masked]> wrote:
> On Fri, 15 Apr 2011 10:48:09 -0400, Thomas Haynes <[email-masked]> wrote:

The user should have no "direct" access -- only access via systems
that enforce MAC.

In a smart client / dumb server environment, security will depend on
the network (either physical security or using IPsec), which is the
great weakness of the smart client / dumb server combo.  If network
security is not airtight then the user might be able to side-step MAC,
but a NFS4ERR_MAC_ACCESS error code isn't going to help them do that
-- they'll side-step MAC whether they get a detailed error or not.

Similarly for a dumb client / smart server environment.

As for a smart client / smart server environment, the user should not
be able to skip MAC without compromising the client.  How, then, does
a NFS4ERR_MAC_ACCESS error code help the user attack the system?  For
that matter, how does a NFS4ERR_MAC_ACCESS error code help a
compromised smart client attack the a smart server?  A malicious smart
client should just be able to assert whichever label will get it
access that the server will accept (and the server will impose
restrictions on what labels a given {client host principal, user
principal} can assert) -- distinguishing between a DAC and MAC form of
EACCES will at most speed up the client's search for an appropriate
label to assert, and since the client will know that this is a MAC
environment, and will be able to locally evaluate DAC (i.e., read
objects' ACLs), it really gets no information from distinguishing the
two possible access failures.

Quite aside from that, see my reply to Tom.  We should allow for
detailed error codes even if production servers wouldn't use them,
because they can help debug problems.

Nico
--