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

[Thomas Haynes <[e-mail]>]

Hi Eric,

You are asking good questions, they illustrate how the community is too close to
the problem.

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.

Thanks,
Tom


> On Apr 10, 2018, at 5:53 PM, Eric Rescorla <[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>) 
>> 
> 
>