Re: [nfsv4] New wording of Security Section for Flex Files

[Thomas Haynes <[e-mail]>]

> On Jul 27, 2017, at 7:23 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Jul 25, 2017 at 01:07:02AM +0000, Thomas Haynes wrote:
>> I hope the following addresses the issues brought up by Ben and Olga;
> 
> I think it does, thanks.  A couple notes inline.
> 
>> First paragraph of Section 15 is replaced by:
>> 
>>   The pNFS extension partitions the NFSv4.1+ file system protocol into
>>   two parts, the control path and the data path (storage protocol).
>>   The control path contains all the new operations described by this
>>   extension; all existing NFSv4 security mechanisms and features apply
>>   to the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]).  The
>>   combination of components in a pNFS system is required to preserve
>>   the security properties of NFSv4.1+ with respect to an entity
>>   accessing data via a client, including security countermeasures to
>>   defend against threats that NFSv4.1+ provides defenses for in
>>   environments where these threats are considered significant.
>> 
>> Replace Section 15.1 with:
>> 
>>   RPCSEC_GSS version 3 (RPCSEC_GSSv3) [RFC7861] could be used to
>>   authorize the client to the storage device on behalf of the metadata
>>   server.  This would require that each of the metadata server, storage
>>   device, and client would have to implement RPCSEC_GSSv3.  The second
>>   requirement does not match the intent of the loosely coupled model
>>   that the storage device need not be modified.  (Note that this does
>>   not preclude the use of RPCSEC_GSSv3 in a loosely coupled model.)
>> 
>>   Under this coupling model, the principal used to authenticate the
>>   metadata file is different than that used to authenticate the data
>>   file.  For the metadata server, the RPC credentials would be
>>   generated by the same source as the client.  For RPC credentials to
> 
> "by the same source as" feels like a slightly awkward phrasing that leaves
> me wondering if I don't quite properly understand the intended sentiment.


I think anything here will be “slightly awkward”.

For the metadata server, the RPC credentials are generated and
verified as in the non-pNFS case.

A little better, but still reads a bit off.

> Isn't it basically required that the client has RPC credentials to talk
> to the metadata server in order to do anything?

Yes


> 
>>   the data on the storage device, the metadata server would be
>>   responsible for their generation.  Such "credentials" SHOULD be
>>   limited to just the data file be accessed.  Using Kerberos V5 GSS-API
>>   [RFC4121], some possible approaches would be:
>> 
>>   o  a dedicated/throwaway client principal name akin to the synthetic
>>      uid/gid schemes.
>> 
>>   o  authorization data in the ticket.
>> 
>>   o  an out-of-band scheme between the client and metadata server.
> 
> Now I feel like I should have spent more time to carefully word the listing
> in my original email :)
> Though I think this text is fine to convey the needed information, at least.
> 
> 
>>   [[AI15: Editorial Note: I have *SHOULD* and not *MUST* because there
>>   might be some limit on the number of outstanding credentials due to
>>   either the number of files or the number of client.  Feel free to
>>   correct me.  --TH]]
> 
> I can think of schemes where there are no limits, but I am not prepared
> to guarantee that all schemes one might want to use would be free of limits.
> So the SHOULD seems fine to me.

Thanks, I’ll remove the AI15.

> 
> Semi-relatedly, I forget exactly how much trust/coupling there is supposed
> to be between the data and metadata servers/operators in this scheme.

The trust is that for the exported part of the name space, the metadata server
has full super user rights.

Note that if the storage device is used for other purposes, the metadata
server should not have super user rights.

> In particular, if the metadata server is sufficiently trusted that it can
> have a copy of the data server's kerberos credentials (the nfs/ keytab),
> then there is quite a lot of flexibility, since the metadata server can
> literally construct an arbitrary ticket and encrypt it to "itself" (i.e.,
> the data server's keytab).  But I don't know whether it's appropriate
> to mention this example in the document or not.

This could be an out-of-band solution. 

I really want to balance providing enough context of how the system
can be secured against being too specific. I.e., have the hand waving
be plausible.

> 
>>   Depending on the implementation details, fencing would then be
>>   controlled either by expiring the credential or by modifying the
> 
> Kerberos doesn't have a revocation (expiry prior to the original expiry)
> story at all.  But since we are talking about RPCSEC_GSS, this text
> is fine, since other GSS mechanisms might allow it :)

I think the lack of upper case use of RFC 2119 words covers it here.

> 
> -Ben
> 
>>   synthetic uid or gid on the data file.  I.e., if the credentials are
>>   at a finer granularity than the synthetic ids, it might be possible
>>   to also fence just one client from the file.
>> 
>> Replace 15.1.2 with:
>> 
>>   With tight coupling, the principal used to access the metadata file
>>   is exactly the same as used to access the data file.  The storage
>>   device can use the control protocol to validate any RPC credentials.
>>   As a result there are no security issues related to using RPCSEC_GSS
>>   with a tightly coupled system.  For example, if Kerberos V5 GSS-API
>>   [RFC4121] is used as the security mechanism, then the storage device
>>   could use a control protocol to validate the RPC credentials to the
>>   metadata server.
>> 
>