Originally posted by: Ulf Troppens

I was recently involved in some customer engagements and briefings related to secure data access and NFSv4. There seems to be some general misconception that NFSv4 deployments provide much more secure data access than NFSv3 deployments. Here are a few facts which I feel worth to clarify and share:

1. The weakness of machine based authentication

The traditional Unix security model is also referred as machine based or server based authentication. The root user authorizes a user to login on a server by creating a user account which includes a user name and a password. The user information can be stored locally (e.g., /etc/passwd, /etc/shadow) or in a central directory service (e.g., LDAP). During the login process the user authenticates itself via his user name and password.

Other services and servers trust that this authentication is not compromised. Traditional NFS supports this security model by controlling access to NFS exports on the machine level. Once an NFS client mounts an NFS export, all users on that client can access the NFS export.

There are still POSIX mode bits or ACLs which are evaluated by the NFS server to grant or deny access to files and directories which are accessed via NFS. However, the NFS server trusts the NFS client that the user is correctly authenticated on the client machine.

A bad minded root user of an NFS client can gain unauthorized access to the data stored on the NFS server by logging in on the NFS client as another user and than accessing data on NFS exports which are authorized for that other user.

The NFS server also trusts the network. A bad minded attacker can attach a machine to the network which spoofs the IP address of an authorized NFS client and create some user accounts on that machine. Traditional NFS represents users and groups via UIDs and GIDs. The NFS server trusts UIDs and GIDs of incoming NFS requests. The attacker can gain unauthorized access to the files stored on the NFS server, because the server fully trusts the NFS client.

2. Session based authentication with Kerberos

The MIT Kerberos project developed a solution for the above security issues by introducing the concept of session based authentication. There is a central entity in Kerberos (the Kerberos Domain Controller, KDC) which enables end-to-end identification, authentication and authorization services. All participating users, machines and services need to trust the KDC but nobody else. Therefore the KDC needs to be well protected.

Users authenticate to the KDC using a Kerberos user name and a Kerberos password. The authentication of machines and services can be automated via certificates (Kerberos keytab file). Once a user is authenticated to a Kerberos domain, he can use kerberized services. A user who wants to use a kerberized service needs to get a session ticket from the KDC and to send this ticket to the service. The service validates the session ticket to authenticate incoming service requests. In a well integrated and configured environment the existence of Kerberos is nearly not noticed by end-users.

3. Kerberos is key for secure data access and not NFSv4

Kerberized NFS is one example for kerberized services. NFS server, NFS client and user accounts need to be configured with Kerberos to provide secure data access via NFS. Kerberized NFS typically provides three security levels: (1) identification and authentication of users to prevent tampering of UIDs and GIDs as explained above, (2) signing of NFS traffic to prevent the tampering of data, (3) encryption of NFS traffic to ensure the privacy of data.

There are three major Kerberos implementations available: MIT Kerberos, Heimdal Kerberos and Microsoft Active Directory. If you are using Microsoft Active Directory you are knowingly or unknowingly already using Kerberos. NFSv3 and NFSv4 can be integrated with all three Kerberos implementations. You are lucky, if you already have Kerberos running in your data center. Otherwise the introduction and operation of Kerberos will be the bigger piece of work than the migration from NFSv3 to NFSv4.

It is worth to notice that kerberized NFSv3 and kerberized NFSv4 provide nearly the same level of data security.  The only security advantage of kerberized NFSv4 is support for more granular access control via NFSv4 ACLs instead of the NFSv3 POSIX mod bits. Of course NFSv4 has a lot of other advantages over NFSv3, but this is outside the scope of this security discussion.

4. Optional vs. Mandatory Kerberos support

Both, NFSv3 and NFSv4 support Kerberos with the difference that kerberized NFS is an optional protocol feature of NFSv3 and a mandatory protocol feature of NFSv4. An NFSv3 implementation (NFSv3 server or NFSv3 client) may or may not support Kerberos. An NFSv4 implementation (NFSv4 server or NFSv4 client) must support Kerberos. However, an administrator of a Kerberos capable NFS implementation (=some NFSv3 implementations and all NFSv4 implementations) can choose whether Kerberos is enabled or not.

Conclusion

Traditional NFS is insecure because it inherits the insecure machine based authentication from Unix. Kerberized NFS is secure because it inherits the session based authentication from Kerberos. Kerberized NFSv3 provides nearly the same level of data security as kerberized NFSv4. For data security, its Kerberos that makes the difference and not the NFS protocol version as such.

Thanks to Sandeep Ramesh Patil for reviewing an early draft of this posting and his suggestions for improvements.

More details on Kerberos

Kerberos: The Network Authentication Protocol
http://web.mit.edu/kerberos/

Designing an Authentication System: A Dialogue in Four Scenes
http://web.mit.edu/kerberos/www/dialogue.html

Explain like I’m 5: Kerberos
http://www.roguelynn.com/words/explain-like-im-5-kerberos/