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

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

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 <
[e-mail]> wrote:

> 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
>