Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Hi Tom.

This text is clear, but I fear it doesn't answer the question I asked in my
discuss: how does the security here compare to ordinary NFS and why.

-Ekr


On Wed, Apr 11, 2018 at 11:08 AM, Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Tom,
>
> On Wed, Apr 11, 2018 at 12:38 PM, Tom Haynes <[e-mail]> wrote:
>
>> So actually, after thinking about, the discussion about securing the
>> namespace on
>> the storage device is wrong.
>>
>> The current text is:
>>
>>
>>    The combination of file handle, synthetic uid, and gid in the layout
>>    are the way that the metadata server enforces access control to the
>>    data server.  The directory namespace on the storage device SHOULD
>>    only be accessible to the metadata server and not the clients.  In
>>    that case, the client only has access to file handles of file objects
>>    and not directory objects.  Thus, given a file handle in a layout, it
>>    is not possible to guess the parent directory file handle.  Further,
>>    as the data file permissions only allow the given synthetic uid read/
>>    write permission and the given synthetic gid read permission, knowing
>>    the synthetic ids of one file does not necessarily allow access to
>>    any other data file on the storage device.
>>
>>    The metadata server can also deny access at any time by fencing the
>>    data file, which means changing the synthetic ids.  In turn, that
>>    forces the client to return its current layout and get a new layout
>>    if it wants to continue IO to the data file.
>>
>>    If the configuration of the storage device is such that clients can
>>    access the directory namespace, then the access control degrades to
>>    that of a typical NFS server with exports with a security flavor of
>>    AUTH_SYS.  Any client which is allowed access can forge credentials
>>    to access any data file.  The caveat is that the rogue client might
>>    have no knowledge of the data file's type or position in the metadata
>>    directory namespace.
>>
>> My replacement would be:
>>
>>    The combination of file handle, synthetic uid, and gid in the layout
>>    are the way that the metadata server enforces access control to the
>>    data server.  The client only has access to file handles of file
>>    objects and not directory objects.  Thus, given a file handle in a
>>    layout, it is not possible to guess the parent directory file handle.
>>    Further, as the data file permissions only allow the given synthetic
>>    uid read/write permission and the given synthetic gid read
>>    permission, knowing the synthetic ids of one file does not
>>    necessarily allow access to any other data file on the storage
>>    device.
>>
>>    The metadata server can also deny access at any time by fencing the
>>    data file, which means changing the synthetic ids.  In turn, that
>>    forces the client to return its current layout and get a new layout
>>    if it wants to continue IO to the data file.
>>
>
> Thanks for proposing new text here.
>
> Spencer (S) as shepherd and WG co-chair, does this look like something
> that would come as a surprise to the working group?
>
> Spencer (D) as AD
>