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

[Tom Haynes <[e-mail]>]

Hi Eric,

It is the same. 

Section 2.2:

   It is RECOMMENDED to implement common access control methods at the
   storage device filesystem to allow only the metadata server root
   (super user) access to the storage device, and to set the owner of
   all directories holding data files to the root user.  This approach
   provides a practical model to enforce access control and fence off
   cooperative clients, but it can not protect against malicious
   clients; hence it provides a level of security equivalent to
   AUTH_SYS.  It is RECOMMENDED that the communication between the
   metadata server and storage device be secure from eavesdroppers and
   man-in-the-middle protocol tampering.  The security measure could be
   due to physical security (e.g., the servers are co-located in a
   physically secure area), from encrypted communications, or some other
   technique.

(By the way, this contradicts the original text in my first paragraph below
and is why we needed a change.)

And as for why, Section 15.1.1 discusses why RPCSEC_GSS is not
provided in this version of the Flex File Layout Type.

Thanks,
Tom

> On Apr 11, 2018, at 1:52 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 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] <mailto:[e-mail]>> wrote:
> Hi, Tom,
> 
> On Wed, Apr 11, 2018 at 12:38 PM, Tom Haynes <[e-mail] <mailto:[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
>