| Red Hat Linux 7.3: The Official Red Hat Linux Reference Guide | ||
|---|---|---|
| Prev | Chapter 18. Network File System (NFS) | Next |
NFS works well for sharing entire filesystems 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 filesystem 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 filesystems on a server or mounting them on a client. Doing so will minimize NFS security risks and better protect your data and equipment.
NFS controls who can mount an exported filesystem based on the host making the mount request, not the user that will utilize the filesystem. Hosts must be given explicit rights to mount the exported filesystem. Access control is not possible for users, other than file and directory permissions. In other words, when you export a filesystem via NFS to a remote host, you are not only trusting the host you are allowing to mount the filesystem. You are also allowing any user with access to that host to use your filesystem as well. The risks of doing this can be controlled, such as requiring read-only mounts and squashing users to a common user and group ID, but these solutions may prevent the mount from being used in the way originally intended.
Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS filesystem, 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 host access to an NFS share. The scope of the wildcard may encompass systems that you may not know exist and should not be allowed to mount the filesystem.
Once the NFS filesystem is mounted read-write by a remote host, protection for each shared file involves its permissions, and its user and group ID ownership. If two users that share the same user ID value mount the same NFS filesystem, 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.
The default behavior when exporting a filesystem via NFS is to use root squashing. This sets the user ID of anyone utilizing the NFS share as the root user on their local machine to a value of the server's nobody account. You should never turn off root squashing unless multiple users with root access to your server does not bother you.
If you are only allowing users to read files via your NFS share, consider using the all_squash option, which makes every user accessing your exported filesystem to take the user ID of the nobody user.