2. Overview of NFS Security

2.1. Port Monitoring

Many NFS servers will require that the client send its NFS requests from UDP or TCP source ports with values < 1024. The theory is that binding to ports < 1024 is a privileged operation on the client, and so the client is enforcing file access permissions on its end. The theory breaks down because:

• On many operating systems, there are no constraints on what port what user can bind to.
• Just because the client host enforces the privilege on binding to ports < 1024 does not necessarily mean that a non-privileged user cannot gain access to the port binding privilege. For example with a single-user desk-top host running a UNIX operating system, the user may have knowledge of the root user password. And even if he does not have that knowledge, with physical access to the desk-top machine, root privileges are trivially acquired.

In some rare cases, when the system administrator can be certain that the clients are trusted and under control (in particular, protected from physical attack), relying of trusted ports MAY be a reliable form of security.

In most cases, the use of privileged ports and port monitoring for security is at best an inconvenience to the attacker and SHOULD NOT be depended on.

To maximize interoperability:

• NFS clients SHOULD attempt to bind to ports < 1024. In some cases, if they fail to bind (because either the user does not have the privilege to do so, or there is no free port < 1024), the NFS client MAY wish to attempt the NFS operation over a port >= 1024.
• NFS servers that implement port monitoring SHOULD provide a method to turn it off.
• Whether port monitoring is enabled or not, NFS servers SHOULD NOT reject NFS requests to the NULL procedure (procedure number 0). See subsection 2.3.1, "NULL procedure" for a complete explanation.

2.1.1. MOUNT Protocol

The port monitoring issues and recommendations apply to the MOUNT protocol as well.

2.2. RPC Security Flavors

The NFS server checks permissions by taking the credentials from the RPC security information in each remote request. Each flavor packages credentials differently.

2.2.1. AUTH_SYS

Using the AUTH_SYS flavor of authentication, the server gets the client's effective user identifier, effective group identifier and supplemental group identifiers on each call, and uses them to check access. Using user identifiers and group identifiers implies that the client and server either share the same identifier name space or do local user and group identifier mapping.

For those sites that do not implement a consistent user identifier and group identifier space, NFS implementations must agree on the mapping of user and group identifiers between NFS clients and servers.

2.2.2. AUTH_DH and AUTH_KERB4

The AUTH_DH and AUTH_KERB4 styles of security are based on a network-wide name. They provide greater security through the use of DES encryption and public keys in the case of AUTH_DH, and DES encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4 case. Again, the server and client must agree on the identity of a particular name on the network, but the name to identity mapping is more operating system independent than the user identifier and group identifier mapping in AUTH_SYS. Also, because the authentication parameters are encrypted, a malicious user must know another user's network password or private key to masquerade as that user. Similarly, the server returns a verifier that is also encrypted so that masquerading as a server requires knowing a network password.

2.2.3. RPCSEC_GSS

The RPCSEC_GSS style of security is based on a security-mechanism- specific principal name. GSS-API mechanisms provide security through the use of cryptography. The cryptographic protections are used in the construction of the credential on calls, and in the verifiers on replies. Optionally, cryptographic protections will be in the body of the calls and replies.

Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS does not imply that the NFS protocol is limited to using those five flavors.

2.3. Authentication for NFS Procedures

2.3.1. NULL Procedure

The NULL procedure is typically used by NFS clients to determine if an NFS server is operating and responding to requests (in other words, to "ping" the NFS server). Some NFS servers require that a client using the NULL procedure:

• send the request from TCP or UDP port < 1024. There does not seem to be any value in this because the NULL procedure is of very low overhead and certainly no more overhead than the cost of processing a NULL procedure and returning an authentication error. Moreover, by sending back an authentication error, the server has confirmed the information that the client was interested in: is the server operating?
• be authenticated with a flavor stronger than AUTH_SYS. This is a problem because the RPCSEC_GSS protocol uses NULL for control messages.

NFS servers SHOULD:

• accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in addition to other RPC security flavors, and
• NOT require that the source port be < 1024 on a NULL procedure ping.

2.3.2. NFS Procedures Used at Mount Time

Certain NFS procedures are used at the time the NFS client mounts a file system from the server. Some NFS server implementations will not require authentication for these NFS procedures. For NFS protocol Version 2, these procedures are GETATTR and STATFS. For Version 3, the procedure is FSINFO.

The reason for not requiring authentication is described as follows. When the NFS client mounts a NFS server's file system, the identity of the caller on the client is typically an administrative entity (in UNIX operating systems, this is usually the "root" user). It is often the case that, for unattended operation in concert with an automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS credentials for the administrative entity associated with an automounter are not available. If so, the NFS client will use AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a file system. While an attacker could exploit this implementation artifact, the exposure is limited to gaining the attributes of a file or a file system's characteristics. This OPTIONAL trade off favors the opportunity for improved ease of use.

2.4. Binding Security Flavors to Exports

NFS servers MAY export file systems with specific security flavors bound to the export. In the event a client uses a security flavor that is not the one of the flavors the file system was exported with, NFS server implementations MAY:

• reject the request with an error (either an NFS error or an RPC level authentication error), or
• allow the request, but map the user's credentials to a user other than the one the client intended. Typically the user that is the result of this mapping is a user with limited access on the system, such as user "nobody" on UNIX systems.

If a client uses AUTH_NONE, the server's options are the same as the above, except that AUTH_NONE carries with it no user identity. In order to allow the request, on many operating systems the server will assign a user identity. Typically this assignment will be a user with limited access on the system, such as user "nobody" on UNIX systems.

2.5. Anonymous Mapping

The following passage is excerpted verbatim from RFC 1813, section 4.4 "Permission Issues" (except that "may" has been changed to "MAY"):

In most operating systems, a particular user (on UNIX, the uid 0) has access to all files, no matter what permission and ownership they have. This superuser permission MAY not be allowed on the server, since anyone who can become superuser on their client could gain access to all remote files. A UNIX server by default maps uid 0 to a distinguished value (UID_NOBODY), as well as mapping the groups list, before doing its access checking. A server implementation MAY provide a mechanism to change this mapping. This works except for NFS version 3 protocol root file systems (required for diskless NFS version 3 protocol client support), where superuser access cannot be avoided. Export options are used, on the server, to restrict the set of clients allowed superuser access.

The issues identified as applying to NFS protocol Version 3 in the above passage also apply to Version 2.

2.6. Host-based Access Control

In some NFS server implementations, a host-based access control method is used whereby file systems can be exported to lists of clients. File systems may also be exported for read-only or read- write access. Several of these implementations will check access only at mount time, during the request for the file handle via the MOUNT protocol handshake. The lack of authorization checking during subsequent NFS requests has the following consequences:

• NFS servers are not able to repudiate access to the file system by an NFS client after the client has mounted the file system.
• An attacker can circumvent the MOUNT server's access control to gain access to a file system that the attacker is not authorized for. The circumvention is accomplished by either stealing a file handle (usually by snooping the network traffic between an legitimate client and server) or guessing a file handle. For this attack to succeed, the attacker must still be able impersonate a user's credentials, which is simple for AUTH_SYS, but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.
• WebNFS clients that use the public file handle lookup [RFC2054] will not go through the MOUNT protocol to acquire initial file handle of the NFS file system. Enforcing access control via the MOUNT protocol is going to be a little use. Granted, some WebNFS server implementations cope with this by limiting the use of the public file handle to file systems exported to every client on the Internet.

Thus, NFS server implementations SHOULD check the client's authorization on each NFS request.

2.7. Security Flavor Negotiation

Any application protocol that supports multiple styles of security will have the issue of negotiating the security method to be used. NFS Version 2 had no support for security flavor negotiation. It was up to the client to guess, or depend on prior knowledge. Often the prior knowledge would be available in the form of security options specified in a directory service used for the purpose of automounting.

The MOUNT Version 3 protocol, associated with NFS Version 3, solves the problem by having the response to the MNT procedure include a list of flavors in the MNT procedure. Note that because some NFS servers will export file systems to specific lists of clients, with different access (read-only versus read-write), and with different security flavors, it is possible a client might get back multiple security flavors in the list returned in the MNT response. The use of one flavor instead of another might imply read-only instead of read- write access, or perhaps some other degradation of access. For this reason, a NFS client SHOULD use the first flavor in the list that it supports, on the assumption that the best access is provided by the first flavor. NFS servers that support the ability to export file systems with multiple security flavors SHOULD either present the best accessing flavor first to the client, or leave the order under the control of the system administrator.

2.8. Registering Flavors

When one develops a new RPC security flavor, iana@iana.org MUST be contacted to get a unique flavor assignment. To simplify NFS client and server administration, having a simple ASCII string name for the flavor is useful. Currently, the following assignments exist:

      flavor       string name

      AUTH_NONE    none
      AUTH_SYS     sys
      AUTH_DH      dh
      AUTH_KERB4   krb4

A string name for a new flavor SHOULD be assigned. String name assignments can be registered by contacting iana@iana.org.