Read an Excerpt
Chapter 8: Network Security
NFS SecurityFilesystem security has two aspects: controlling access to and operations on files, and limiting exposure of the contents of the files. Controlling access to remote files involves mapping UNIX file operation semantics into the NFS system, so that certain operations are disallowed if the remote user fails to provide the proper credentials. To avoid giving superuser permissions across the network, additional constraints are put in place for access to files by root. Even more stringent NFS security requires proving that the UNIX-style credentials contained in each NFS request are valid; that is, the server must know that the NFS client's request was made by a valid user and not an imposter on the network.
Limiting disclosure of data in a file is more difficult, as it usually involves encrypting the contents of the file. The client application may choose to enforce its own data encryption and store the file on the server in encrypted form. In this case, the client's NFS requests going over the network contain blocks of encrypted data. However, if the file is stored and used in clear text form, NFS requests to read or write the file will contain clear text as well. Sending parts of files over a network is subject to some data exposure concerns. In general, if security would be comprised by any part of a file being disclosed, then the file should not be placed on an NFS-mounted filesystem. You can prevent damage to files by restricting write permissions and enforcing user authentication, but there are few safeguards against someone eavesdropping on your network. NFS has some simple security mechanisms in place today, and the Secure RPC mechanisms described in this chapter ensure that user authentication is made secure as well. "Ibis section presents ways of restricing access based on the user credentials presented in NFS requests, and then looks at validating the credentials themselves using Secure RPC.
NFS RPC Authentication
Every NFS request, including mount requests, contains a set of user credentials with a UID and a list of group IDs (GIDs) to which the UID belongs. NFS credentials are the same as those used for accessing local files, that is, if you belong to five groups, your NFS credentials contain your UID and five GIDs. On the NFS server, these credentials are used to perform the permission checks that are part of UNIX file accesses-verifying write permission to remove a file, or execute permission to search directories. There are three areas in which NFS credentials may not match the user's local credential structure: the user is the superuser, the user is in too many groups, or no credentials were supplied (an "anonymous" request). Mapping of root and anonymous users is covered in the next section.
Problems with "too many" groups depend upon the implementation of NFS used by the client and the server, and may be an issue only if they are different (including different revisions of the same operating system). Every NFS implementation has a limit on the number of groups that ran be passed in a credentials structure for an NFS RPC. Ibis number usually agrees with the maximum number of groups to which a user may belong, but it may be smaller. Typically, the limit on the number of groups is either 8 or 16. If the client's group limit is larger than the server's, and a user is in more groups than the server allows, then the server's attempt to parse and verify the credential structure will fail, yielding error messages like:
RPC: Authentication error
Authentication errors may occur when trying to mount a filesystem, in which case the superuser is in too many groups. Errors may also occur when a particular user tries to access files on the NFS server; these errors result from any NFS RPC operation. Pay particular attention to the group file in a heterogeneous environment, where the Nis-managed group map may be appended to a local file with several entries for common users like root and bin. The only solution is to restrict the number of groups to the smallest value allowed by all systems that are running NFS.
The superuser is not given normal file access permissions to NFS-mounted files. The motivation behind this restriction is that root access should be granted on a per-machine basis. A user who is capable of becoming root on one machine should not necessarily have permission to modify files on a file server. Similarly, a setuid program that assumes root privileges may not function properly or as expected if it is allowed to operate on remote files.
To enforce restrictions on superuser access, the roof s UID is mapped to the anonymous user nobody in the NFS RPC credential structure. The superuser frequently has fewer permissions than a non-privileged user for NFS-mounted filesystems, since nobody's group usually includes no other users. in the password file, nobody has a UID of -2, and the group nogroup also has a GID of -2. On systems that require non-negative user and group ID values, nobody and nogroup use a 16-bit unsigned representation of -2. When an executable that 65534, which is is setuid runs, its effective user ID is root, which gets mapped to nobody. The executable still has permissions on the local system, but it cannot get to remote files unless they have been explicitly exported with root access enabled.
Some implementations of NFS allow the root UID mapping to be defeated by changing the UID used for nobody in the server's kernel. Changing the UID for nobody from -2 to 0 allows the superuser to access all files exported from the server, which may be less restrictive than desired. The mapping may be changed by simply modifying the UD and GID of the nobody user in the server's password file:
Changing nobody's UID affects every filesystem exported from the server, and should be considered as much an invitation for trouble as providing the root password to users that mount filesystems from the server.
Most NFS servers grant root permission on an exported filesystem on a per-host basis using the root=export option. The server exporting a filesystem grants root access to a host or list of hosts by including them in the /etc/exports file:
superuser on hosts bitatron and corvette is given normal root filesystem privileges on the server's /home/work directory. The name of a netgroup may be substituted for a hostname; all of the hosts in the netgroup are granted root access.
Root permissions on a remote filesystem should be extended only when absolutely necessary. While privileged users may find it annoying to have to log into the server owning a filesystem in order to modify something owned by root, this restriction also eliminates many common mistakes. If a system administrator wants to purge /usr/local on one host (to rebuild it, for example), executing rm -rf * will have disastrous consequences if there is an NFS-mounted filesystem with root permission under /usr/local. If /usr/local/bin is NFS mounted, then it is possible to wipe out the server's copy of this directory from a client when root permissions are extended over the network.
The only clear-cut case where root permissions should be extended on an NFS filesystem is for the root and swap partitions of a diskless client, where they are mandatory. One other possible scenario in which root permissions are useful is...