Because NFS allows users on a network to access files stored on the server, NFS has significant security implications for the server. These implications fall into three broad categories:
NFS can (and should) be configured so that only certain clients on the network can mount filesystems stored on the server.
NFS can (and should) be configured so that users can access and alter only files to which they have been granted access.
NFS should (but does not) protect information on the network from eavesdropping and surreptitious modification.
The NFS server can be configured so that only certain hosts are allowed to mount filesystems on the server. This is a very important step in maintaining server security: if an unauthorized host is denied the ability to mount a filesystem, then unauthorized users on that host should not be able to access the server's files. This configuration is controlled by settings in a file. Depending on the version of Unix/Linux/etc. that you are using, the specific file structure and usage is different. Systems with a BSD heritage use /etc/exports, and systems with a System V heritage use /etc/dfs/dfstab.
Many versions of Unix, including Sun's SunOS, HP's HP-UX, SGI's IRIX, and Linux use the /etc/exports file to designate which clients can mount the server's filesystem and what access those clients can be given. Each line in the /etc/exports file generally has the form:
directory -options [,more options]
For example, a sample /etc/exports file might look like this:
/ -access=math,root=prose.domain.edu /usr -ro /usr/spool/mail -access=math
The directory may be any directory or filesystem on your server. In the example, exported directories are /, /usr, and /usr/spool/mail.
The options allow you to specify a variety of security-related and performance-related options for each entry. These include:
Grants access to this filesystem only to the hosts or netgroups (see Chapter 12) specified in machinelist. The names of hosts and netgroups are listed and separated by colons (e.g., host1:host2:group3). A maximum of 10 hosts or group names can be listed in some older systems (check your documentation).
 There was an old bug in NFS that caused a filesystem to be exported to the world if an exports line exceeded 256 characters after name alias expansion. Use showmount -e to verify when finished.
Exports the directory and its contents as read-only to all clients. This option overrides whatever the file permission bits are actually set to.
Exports the filesystem read-only to all hosts except those listed, which are allowed read/write access to the filesystem.
Normally, NFS changes the user ID for requests issued by the superuser on remote machines from 0 (root) to -2 (nobody). Specifying a list of hosts gives the superuser on these remote machines superuser access on the server.
Specifies which user ID to use on NFS requests that are not accompanied by a user ID; this might happen on a DOS client. The number specified is used for both the UID and the GID of anonymous requests. A value of -2 is the nobody user. A value of -1 usually disallows access.
Specifies that NFS should use Sun's Secure RPC (AUTH_DES) authentication system, instead of AUTH_UNIX. See Chapter 13 for more information.
You should understand that NFS maintains options on a per-filesystem basis, not on a per-directory basis. If you put two directories in the /etc/exports file that actually reside on the same filesystem, they will use the same options (usually the options used in the last export listed).
Sun's documentation of anon states that, "If a request comes from an unknown user, use the given UID as the effective user ID." This statement is very misleading; in fact, NFS by default honors "unknown" user IDs?that is, UIDs that are not in the server's /etc/passwd file?in the same way that it honors "known" UIDs because the NFS server does not ever read the contents of the /etc/passwd file. The anon option actually specifies which UID to use for NFS requests that are not accompanied by authentication credentials.
NFS Exports Under Linux and BSD
The Linux NFS server offers several additional options that can be placed in the /etc/exports file and provide some limited security improvements:
Some BSD-derived systems offer similar options:
Let's look at the example /etc/exports file again:
/ -access=math,root=prose.domain.edu /usr -ro /usr/spool/mail -access=math
This example allows anybody in the group math or on the machine math to mount the root directory of the server, but only the root user on machine prose.domain.edu has superuser access to these files. The /usr filesystem is exported read-only to every machine that can get RPC packets to and from this server (usually a bad idea?this may be a wider audience than the local network). And the /usr/spool/mail directory is exported to any host in the math netgroup.
The /usr/etc/exportfs program reads the /etc/exports file and configures the NFS servers, which run inside the kernel's address space. After you make a change to /etc/exports, be sure to type this on the server:
 For performance reasons, there is often more than one server process running.
# exportfs -a
You can also use the exportfs command to temporarily change the options on a filesystem. Because different versions of the command have slightly different syntax, you should consult your documentation.
Versions of NFS that are present on System V-derived systems (including Solaris) have dispensed with the /etc/exports file and have instead adopted a more general mechanism for dealing with many kinds of distributed filesystems in a uniform manner. These systems use a command named share to extend access for a filesystem to a remote machine, and the command unshare to revoke access.
The share command has the syntax:
share [ -F FSType ] [ -o specific_options ] [ -d description ] [ pathname ]
in which FSType should be nfs for NFS filesystems, and specific_options are basically the same as those documented earlier for the /etc/exportfs file. The optional argument description is meant to be a human-readable description of the filesystem that is being shared.
When a system using this mechanism boots, its network initialization scripts execute the shell script /etc/dfs/dfstab. This file contains a list of share commands. Example 15-1 illustrates such a file with some security problems.
# Place share(1M) commands here for automatic execution # upon entering init state 3. # # This configuration is not secure. # share -F nfs -o rw=red:blue:green /cpg share -F nfs -o rw=clients -d "spool" /var/spool share -F nfs /tftpboot share -F nfs -o ro /usr/lib/X11/ncd share -F nfs -o ro /usr/openwin
This file gives the computers red, blue, and green access to the /cpg filesystem; it also gives all of the computers in the clients netgroup access to /var/spool. All computers on the network are given read/write access to the /tftpboot directory; and all computers on the network are given read-only access to the directories /usr/lib/X11/ncd and /usr/openwin.
One extension to the NFS Version 3 protocol made by Sun engineers, and proposed to be included in NFS 4, is the addition of WebNFS. This is the capability in which an NFS server exports a single NFS partition for access via web servers, Java applications, and other network services but does not expose the mount protocol to the outside.
Basically, the idea is that a system can be set up with a single partition marked as "public" in the /etc/dfs/sharetab file. An appropriately equipped web browser, when presented with a URL of the form nfs://server/filename, then contacts the server and returns the designated item. Because there is only one "public" partition, there is no need to mount the disk or otherwise transfer information to find the file. In theory, this should be a safe way to provide a file because the mount server can be hidden behind a firewall, and the disk can be exported read-only.
We recommend that you do not use this protocol unless you thoroughly understand the potential risks. Not the least among these are the following:
Quite frankly, the whole idea strikes us as another instance of "Wouldn't it be cool to . . . ?" rather than "Do we introduce new risks if we . . . ?"
Do you see the security hole in the above configuration? It's explained in detail in Section 220.127.116.11 later in this chapter.
You can use the Unix command showmount (typically located in /usr/sbin or /usr/etc and present in most flavors of Unix) to list all of the clients that have probably mounted directories from your server. This command has the form:
/usr/etc/showmount [options] [host]
The options are:
Lists all of the hosts and which directories they have mounted
Lists only the directories that have been remotely mounted
Lists all of the filesystems that are exported; this option is described in more detail later in this chapter