Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-flex-files-15

[Thomas Haynes <[e-mail]>]

Hi Brian,

Thanks for the review - comments inline..

> On Jan 12, 2018, at 10:45 AM, Brian Weis <[e-mail]> wrote:
> 
> Reviewer: Brian Weis
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These comments
> were written primarily for the benefit of the security area directors. Document
> editors and WG chairs should treat these comments just like any other last call
> comments.
> 
> This document defines the Parallel Network File System (pNFS), which allows a
> storage system to store the metadata for files onto a metadata server, and data
> of that file onto a separate storage device. The document focuses on the
> interaction between the two types of servers, and the requirements of clients
> using a pNFS system.
> 
> The document describes two models by which the metadata server and file storage
> server can communicate. One is a “tight coupling model”, in which the two types
> of servers directly communicate. In this model the metadata server can ensure
> that file access control state is synchronized between the two servers, and I
> believe that level of access control is equivalent to NFS v4.x today. From a
> security considerations perspective, this is perhaps best summarized in Section
> 2.2:
> 
>  “With tightly coupled storage devices, the metadata server sets the
>   user and group owners, mode bits, and ACL of the data file to be the
>   same as the metadata file.  And the client must authenticate with the
>   storage device and go through the same authorization process it would
>   go through via the metadata server.”
> 
> The other model is a “loose coupling model”, in which the client is
> authenticated and authorized by the metadata server, and is given access to the
> file server through the use credentials. However, there is no direct
> communications between the metadata server and the file server. The metadata
> server does not seem to provide a fine grained access control to files on the
> file server, but instead relies upon the client to enforce a less granular
> level of access control.

[1] No, there is still direct communication between the metadata server and the file server.

The difference is that it is via a storage protocol, in this case NFS.

The access control is enforced by the metadata server. The client only get access
to the file if it can get a layout. The layout can either provide read/write access
or only read access.

The metadata server can revoke that access at any point, so it is not
correct to say that it depends on the client to enforce a less granular level
of access control.

> 
> The Security Considerations section is well-written and helpful. I do have some
> suggestions for improving it,  and also some questions.
> 
> (1) Section 2.2: should the “recommended” in the Note be RECOMMENDED?
> Restricting access control to just superuser have access to the storage device
> seems like a valuable advice.

sure

> 
> (2) Section 2.2: The NOTE probably should provide guidance regarding protecting
> the network connections between the metadata server and the file server. For
> example, something like: “Communications between the metadata server and file
> server need to secured. If there is not adequate physical security (i.e., the
> servers are not co-located in a physically secure area), their communications
> MUST be protected for confidentiality (e.g., using TLS or IPsec).”

No, the MUST is too strong here. We can recommend procedures, we can not REQUIRE them.

I am fine with:

Communications between the metadata server and file
server SHOULD be secured. If there is not adequate physical security (i.e., the
servers are not co-located in a physically secure area), their communications
SHOULD be protected for confidentiality (e.g., using TLS or IPsec).”

> 
> (3) From the description of synthetic uids/gids in Section 2.2, I believe that
> the full range of file permissions (e.g., owner r/w/x)  is honored in the
> tightly coupled model, but are restricted in the loosely coupled model to
> “owner r/w”, “group r”. If that is correct, I think the security considerations
> should explicitly mention that the effect of access permissions is reduced on
> the file server files.

[2] I think the confusion here is that the files on storage device are not
in the file hierarchy as seen on the metadata server.

On a file by file basis on the storage device, we are giving the client either
write modification access, read access, or no access at all. The client cannot
remove the file (it would need to know the parent directory FH and the
name of the file - neither of which it has).  It can effectively remove the content
if it has write permission (but nothing would prevent this in a tightly
coupled model). 




> 
> (4) Section 2.2. In this phrase “it may be assigned some random synthetic
> uid/gid to deny access”, would a better word for “random” be “unused” or
> “unpredictable”? Also what is the security value intended by the use of a
> “random” value for synthetic uids/gids?
> 

In an earlier review (by Linda Dunbar), that phrase was changed:


  On the storage device, it may be assigned some random synthetic uid/
  gid to deny access:

  -rw-r-----    1 19452   28418    1697 Dec  4 11:31 data_ompha.c

  When the file is opened on a client and accessed, it will try to get a
  layout for the data file. Since the layout knows nothing
  about the user (and does not care), whether the user loghyr or
  garbo opens the file does not matter.  The client has to present
  an uid of 19452 to get write permission. If it presents any other
  value for the uid, then it must give a gid of 28418 to get read
  access.

  Further, if the metadata server decides to fence the file, it may
  change the uid and gid as such:

  -rw-r-----    1 19453   28419    1697 Dec  4 11:31 data_ompha.c


What we could suggest would be something along the lines of:

  On the storage device, it may be assigned some unpredictable
  synthetic uid/gid to deny access.
  …
  Further, if the metadata server decides to fence the file, it
  should change the uid and/or gid such that these values
  neither match earlier values for that file nor match
  a predictable change based on an earlier fencing.

Ugh, not sure I like the words.

uid[N+1] != uid[N-1] && uid[N+1]  != change(uid[N-1] -> uid[N]).

I.e., do not set to recent old values (might fence back to an uid
an older client already has) and do not use a fixed increment.


> (5) In the “loose coupling model” file access actually enforced by the client,
> which presumably can be manipulated by an evil user. This is clearly stated n
> Section 2.2: “ The client is thus solely responsible for enforcing file
> permissions in a loosely coupled model.”  Also, Section 2.2.1 mentions “a
> SETATTR would be sent to the storage device to set the owner and group of the
> data file”, and since here is no control protocol between the metadata server
> and the file server so I assume it is sent by the client.

It is subtle, but this goes back to the fact (see [1]) that “no control protocol” does not
imply “no communication between the metadata server and the storage
device”.  I.e., the MDS does the SETATTR.

Also, I notice you are using the phrase “file server”, which probably impacts
your view in your point 3 (see my [2]) - the term we use is storage
device. There is no requirement that this device serve up data files
as if they were in a filesystem. The storage device is limited in the operations
that it can respond to from the client based on the information it is
presented with.

For example, the exports on the storage device can be configured such
that the metadata server is the only one which can mount the exports.
And since the metadata server only hands out File Handles to the
clients, they would not be able to walk the namespace of the storage
device.


> 
> Put another way, it seems as if any client that has credentials allowing it to
> access to the file server can access any file on the file system if it is
> chooses to do so (e.g.., if it is a malicious client). Is that correct?

As with any NFS filesystem which uses an AUTH_SYS security model,
each of the file handle, uid, and gid can be forged to gain access.

In other words, this is nothing new.

The security model for NFSv4.2 (and based on that, NFSv4.0 and NFSv4.1):

[RFC7862]
17.  Security Considerations

   NFSv4.2 has all of the security concerns present in NFSv4.1 (see
   Section 21 of [RFC5661]), as well as those present in the server-side
   copy (see Section 4.9) and in Labeled NFS (see Section 9.6).

Which leads us to [RFC5661]:

2.2.1.1.1.2.  Security Mechanisms for NFSv4.1

   RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide
   security services.  Therefore, NFSv4.1 clients and servers MUST
   support the Kerberos V5 security mechanism.

   The use of RPCSEC_GSS requires selection of mechanism, quality of
   protection (QOP), and service (authentication, integrity, privacy).
   For the mandated security mechanisms, NFSv4.1 specifies that a QOP of
   zero is used, leaving it up to the mechanism or the mechanism's
   configuration to map QOP zero to an appropriate level of protection.
   Each mandated mechanism specifies a minimum set of cryptographic
   algorithms for implementing integrity and privacy.  NFSv4.1 clients
   and servers MUST be implemented on operating environments that comply
   with the REQUIRED cryptographic algorithms of each REQUIRED
   mechanism.

2.2.1.1.1.2.1.  Kerberos V5

   The Kerberos V5 GSS-API mechanism as described in [5] MUST be
   implemented with the RPCSEC_GSS services as specified in the
   following table:

To paraphrase it, NFSv4.x clients and servers MUST support
the Kerberos V5 security mechanism, but installations are not
required to use Kerberos.

I.e., this:

mount -o vers=4.2,sec=sys server:/ /mnt

means that any malicious user can use any client which can connect
to the server to do whatever they want.

In other words, this is not a reduction of the actual security from NFSv4.x.


> 
> Unless I’m mistaken, this is a serious reduction of actual security from NFS
> 4.x, and also from the tight coupling model. This should be clearly stated in
> the security considerations section, so that protocol adopters and users
> understand the additional risks of the loose coupling model. For this  reason,
> I've marked the review with "Has Issues" rather than "Has Nits".
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4