NFS works well for sharing entire file systems with a large number of known hosts in a largely transparent manner. Many users accessing files over an NFS mount may not be aware that the file system they are using is not local to their system. However, with ease of use comes a variety of potential security problems.
The following points should be considered when exporting NFS file systems on a server or mounting them on a client. Doing so will minimize NFS security risks and better protect data on the server.
NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than file and directory permissions. In other words, once a file system is exported via NFS, any user on any remote host connected to the NFS server can access the shared data. To limit the potential risks, administrators can only allow read-only access or squashing users to a common user and groupid. But these solutions may prevent the NFS share from being used in the way it was originally intended.
Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS file system, the system associated with a particular hostname or fully qualified domain name can be pointed to an unauthorized machine. At this point, the unauthorized machine is the system permitted to mount the NFS share, since no username or password information is exchanged to provide additional security for the NFS mount. The same risks hold true to compromised NIS servers, if NIS netgroups are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this kind of attack is more difficult.
Wildcards should be used sparingly when granting exporting NFS shares as the scope of the wildcard may encompass more systems than intended.
For more information on securing NFS, refer to the chapter titled Server Security in the Red Hat Linux Security Guide.
Once the NFS file system is mounted read-write by a remote host, the only protection each shared file has is its permissions. If two users that share the same userid value mount the same NFS file system, they will be able to modify each others files. Additionally, anyone logged in as root on the client system can use the su - command to become a user who could access particular files via the NFS share. For more on NFS and userid conflicts, refer to the chapter titled Managing Accounts and Groups in the Red Hat Linux System Administration Primer.
The default behavior when exporting a file system via NFS is to use root squashing. This sets the userid of anyone accessing the NFS share as the root user on their local machine to a value of the server's nobody account. Never turn off root squashing.
If exporting an NFS share read-only, consider using the all_squash option, which makes every user accessing the exported file system take the userid of the nobody user.