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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Eric,

On Thu, May 25, 2017 at 9:49 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, May 25, 2017 at 9:19 PM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, Eric,
>>
>> On Tue, May 23, 2017 at 9:30 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>> 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/stat
>>> ement/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.
>>
>>
>> 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.
>>
>>
> 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.
>

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