9.4. Securing NFS
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.
9.4.1. Host Access
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.
9.4.2. File Permissions
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.
