Subject: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-xattrs-05: (with DISCUSS)

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 19:30:51 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-nfsv4-xattrs-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-xattrs/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

      Since xattrs are application data, security issues are exactly
the
      same as those relating to the storing of file data and named
      attributes.  These are all various sorts of application data and
      the fact that the means of reference is slightly different in
each
      case should not be considered security-relevant.  As such, the
      additions to the NFS protocol for supporting extended attributes
      do not alter the security considerations of the NFSv4.2 protocol
      [RFC7862].

This seems inadequate. The issue is that if machine A writes some
extended attribute which is security relevant (i.e., this file is
only readable under certain conditions) and then machine B doesn't
know about the attribute, then you have a security problem on B
because it will not enforce it. It seems like FreeBSD uses extended
attributes for this purpose, so this isn't just theoretical.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 May 2017 08:19:59 -0500

Hi, Eric,

> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-xattrs/

I haven't seen a response from the authors on this Discuss, so, at the risk
of talking out of my hat, I THINK the answer is going to be that

   - either machine B keeps enforcing the incredibly lame access rights
   it's already enforcing (all users are part of the "nfs" group, so share the
   same access rights anyway, or whatever), or
   - machine B isn't enforcing anything now, so wouldn't be enforcing
   anything anyway.

So, at a minimum, this extension would Do No Harm during periods of partial
deployment.

My advice is to wait for a response from a smarter Spencer (S), or another
person who knows more about NFSv4 than I do, who will either confirm what
I'm saying or tell you what I should have said instead, but if it's worth
having a speculative discussion on the call today, I'm always up for that,
of course.

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 May 2017 21:49:30 +0800

On Thu, May 25, 2017 at 9:19 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> I haven't seen a response from the authors on this Discuss, so, at the
> risk of talking out of my hat, I THINK the answer is going to be that
>
I think that's right.

>
>    -
>
> So, at a minimum, this extension would Do No Harm during periods of
> partial deployment.
>

This, I don't agree with, because once this capability exists, people come
to rely on it.

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 May 2017 10:08:33 -0400

Hi, Eric,

> This, I don't agree with, because once this capability exists, people come

The nice people in NFSv4 understand expectations about NFS much better than
I do, so I'll let them take it from here.

The NFSv4 working group has been talking about my question to them about
the best way to signal that an extension is supported, and I didn't see
that they've converged (or at least, they haven't said they've converged).
I suspect that this Discuss position will be useful input to that
discussion, although it's not talking about exactly the same issues.

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 May 2017 10:35:53 -0400

Dear -xattrs- folk,

We did chat about this Discuss on the call, and Eric said (in the jabber
room) that if the issue he raised is accurate, at a minimum, the document
needs to provide a warning about the exposure, in order to clear the
Discuss.

Actual technical solutions that mitigate the exposure are, of course,
appreciated, if it's possible to provide a solution.

Thanks,

Spencer (D).

On Thu, May 25, 2017 at 10:08 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

>> This, I don't agree with, because once this capability exists, people
>> come to rely on it.
>>
>
> The nice people in NFSv4 understand expectations about NFS much better
> than I do, so I'll let them take it from here.
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 May 2017 10:29:59 -0500

> needs to provide a warning about the exposure, in order to clear the

No, i think it has to provide, at a minimum, a MUST NOT (see below).

The alternative is to add proper support for system xattrs.  I discuss
both below.

> appreciated, if it's possible to provide a solution.

A better way to deal with this would be to have a way to flag some
xattrs as being system xattrs, and more importantly, to indicate whether
the client and server support whatever the system xattr's semantics are.

If a client doesn't support some system xattr, the server might provide
more limited access to the file that has that xattr.  If a server
doesn't support some system xattr, the client might fail the operation
to set it.  It all depends on the particular system xattr's semantics.

E.g., a system xattr denoting append-only or read-only can be enforced
by the server, but setting it when the server doesn't support it means
that other clients might not enforce it either.

An xattr that denotes privileges to be gained on exec (a la set-uid),
probably requires extra permission to set -- if the server doesn't know
this, then other clients must not grant those extra privileges on exec!

Alternatively, you could just say that at this time NFSv4 simply does
not support system xattrs, and that no xattrs with names in a system
namespace must be trusted by clients.  This is where the MUST NOT comes
in: the spec would say "clients MUST NOT accord special system semantics
to xattrs" (with some wordsmithing around "system" xattrs).  Then you
could add the flagging feature later.  But you'll have to distinguish
system xattrs set pre- and post-addition of the flagging feature.

Nico
--

---

From: "Marc Eshel" <[email-masked]>
Date: Thu, 25 May 2017 09:11:53 -0700

We had a lot of discussions in the WG about the security implications and 
we decided to stay a way of defining different types of xattr. This is 
user only xattr for the applications to use and it should be handled as an 
extension to the data in the file without any meaning for the protocol. If 
it is not clear enough we can fix the text and add a warning. 
Marc.

From:   Nico Williams <[email-masked]>
To:     Spencer Dawkins at IETF <[email-masked]>
Cc:     Eric Rescorla <[email-masked]>, [email-masked], 
The IESG <[email-masked]>, NFSv4 <[email-masked]>, [email-masked]
Date:   05/25/2017 08:30 AM
Subject:        Re: [nfsv4] Eric Rescorla's Discuss on 
draft-ietf-nfsv4-xattrs-05: (with DISCUSS)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 May 2017 13:22:47 -0500

> it is not clear enough we can fix the text and add a warning. 

That's fair, but the point is that the security considerations should be
very explicit as to this.  MUST/MUST NOT language is called for.