The Network File System, or NFS, is service that provides network accessible file systems for client machines. For more information on how NFS works, refer to the chapter titled Network File System (NFS) in the Red Hat Enterprise Linux Reference Guide. For more information about configuring NFS, refer to the Red Hat Enterprise Linux System Administration Guide. The following subsections assume a basic knowledge of NFS.
The version of NFS included in Red Hat Enterprise Linux, NFSv4, no longer requires the portmap service as outlined in Section 5.2 Securing Portmap. NFS traffic now utilizes TCP in all versions, rather than UDP, and requires it when using NFSv4. NFSv4 now includes Kerberos user and group authentication, as part of the RPCSEC_GSS kernel module. Information on portmap is still included, since Red Hat Enterprise Linux supports NFSv2 and NFSv3 which utilize it.
Now that NFSv4 has the ability to pass all information encrypted using Kerberos over a network, it is important that the service be configured correctly if it is behind a firewall or on a segmented network. NFSv2 and NFSv3 still pass data insecurely, and concerns should be taken into consideration. Careful network design in all of these regards can help prevent security breaches.
The NFS server determines which file systems to export and which hosts to export these directories to via the /etc/exports file. Be careful not to add extraneous spaces when editing this file.
For instance, the following line in the /etc/exports file shares the directory /tmp/nfs/ to the host bob.example.com with read/write permissions.
This line in the /etc/exports file, on the other hand, shares the same directory to the host bob.example.com with read-only permissions and shares it to the world with read/write permissions due to a single space character after the hostname.
/tmp/nfs/ bob.example.com (rw)
It is good practice to check any configured NFS shares by using the showmount command to verify what is being shared:
showmount -e <hostname>
By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. In this way, all root-created files are owned by nfsnobody, which prevents uploading of programs with the setuid bit set.
If no_root_squash is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute.