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

[Tom Haynes <[e-mail]>]

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.


> On Apr 11, 2018, at 7:14 AM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Dear Authors,
> 
> On Tue, Apr 10, 2018 at 11:20 PM, Thomas Haynes <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Eric,
> 
> You are asking good questions, they illustrate how the community is too close to
> the problem.
> 
> That can happen with NFSv4, through no fault of that community! 
> 
> In the fourth paragraph of Section 15, there is the recommended case:
>   
>    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 context, the client has no access to the storage device’s namespace,
> and as such, cannot easily do a READDIR or LOOKUP for traversing.
> It can snoop the file handles going to the storage device, but unlike a
> normal server, the credentials can change underneath the client. I.e.,
> they are not controlled by an app, but by the metadata server.
> 
> If we allow access to the directory namespace, as suggested by paragraph 5:
> 
> 
> 
>    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.
> 
> then we “degrade” the security back to that faced by a normal server.
> 
> The point isn’t that flex file is more secure, but that by taking care of
> how exports are managed on the storage devices, admins can do a bit
> better than awful.
> 
> Hope this explains it.
> 
> When I see authors explaining something about existing text (in any document), I usually think that it would be helpful to propose text that would provide the same insights to future readers. At a minimum, that's what Eric would be looking at, in considering his ballot position, rather than email threads that other readers wouldn't have access to.
> 
> Do you folks know what such proposed text would look like?
> 
> And thanks to all involved, in moving this conversation forward.
> 
> Spencer (D)
>  
> Thanks,
> Tom
> 
> 
>> On Apr 10, 2018, at 5:53 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> On Tue, Apr 10, 2018 at 5:02 PM, Tom Haynes <[e-mail] <mailto:[e-mail]>> wrote:
>> No, it does not have better security than typical NFS, it has the same security.
>> 
>> OK, then I'm confused about "degrades to"  Can you help me with that?
>> 
>> 
>> The synthetic IDs control access to the files and the metadata server can
>> modify them to fence off a rogue client*, but in the end, the security of any
>> AUTH_SYS approach is limited.
>> 
>> * By rogue client I do not mean malicious, I mean one which had established
>> a connection with the metadata server, was handed a layout, and then when
>> the layout was recalled, took over 91s to return that layout. It is probable that
>> there is a network partition between the client and the metadata server and
>> it is unknown if there is one between the client and the storage device. The
>> fencing act causes the client to become aware that it needs to once again
>> reach out to the metadata server.
>> 
>> The security aspect of this version of the flex file layout type is to be as secure
>> as any other NFS in a data center environment.
>> 
>> The goal of the next version of the flex file layout type is to be as secure
>> as any other NFS in the WAN. I.e., kerberized connections.
>> 
>> 
>>> On Apr 10, 2018, at 4:25 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Not entirely. I'm inferring from the following text that this draft is
>>> supposed to have somewhat better security than typical NFS, but it's
>>> not really clear.
>>> 
>>> 
>>>    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.
>>> 
>>> On Tue, Apr 10, 2018 at 11:43 AM, Spencer Dawkins at IETF <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi, Eric,
>>> 
>>> On Mon, Apr 2, 2018 at 2:56 PM, Tom Haynes <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi Eric,
>>> 
>>> Kathleen has removed her “discuss” from this document (the new version was pushed,
>>> which satisfied her need for the SecDir review.
>>> 
>>> Could you please revisit your position on this draft?
>>> 
>>> I'm just following up on this one - could you take a look at whether -17 addresses your Discuss position?
>>> 
>>> Thanks,
>>> 
>>> Spencer
>>> 
>>> (diff from telechat version is https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt <https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt>)