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

[Brian Weis <[e-mail]>]

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.

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.

(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).”

(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.

(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?

(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.

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?

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".