Server-Side NFS Security

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:

Client access: NFS can (and should) be configured so that only certain clients on the network can mount filesystems stored on the server.
User authentication: NFS can (and should) be configured so that users can access and alter only files to which they have been granted access.
Eavesdropping and data spoofing: NFS should (but does not) protect information on the network from eavesdropping and surreptitious modification.

Limiting Client Access: /etc/exports and /etc/dfs/dfstab

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.

/etc/exports

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:

access= machinelist: 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).^[219]
ro: Exports the directory and its contents as read-only to all clients. This option overrides whatever the file permission bits are actually set to.
rw= machinelist: Exports the filesystem read-only to all hosts except those listed, which are allowed read/write access to the filesystem.
root= machinelist: 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.
anon= uid: 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.
secure: 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:

root_squash: Forces requests from UID 0 to be mapped to the anonymous UID. This option is on by default.
squash_uids=0-10,20,25-30: Allows you to specify other UIDs that are mapped to the anonymous UID. Of course, an attacker can still gain access to your system by using non-squashed UIDs.
all_squash: Specifies that all UIDs should be mapped to the anonymous UID. This option does genuinely increase your system’s security, but why not simply export your filesystem read-only?

Some BSD-derived systems offer similar options:

-maproot= userid or -maproot= userid : group : group: Forces requests from UID 0 to be mapped to the given UID and groups.
-mapall= userid or -mapall= userid : group : group: Allows you to specify that all other UIDs be mapped to the given UID and groups.

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.

/usr/etc/exportfs

The /usr/etc/exportfs program reads the /etc/exports file and configures the NFS servers,^[220] which run inside the kernel’s address space. After you make a change to /etc/exports, be sure to type this on the server:

# 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.

Exporting NFS directories under System V: share and dfstab

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.

Example 15-1. An /etc/dfs/dfstab file with some 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.

WebNFS

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:

You need to open your firewall to traffic to your NFS server (normally, port 2049). This can allow someone to execute a denial of service attack against your NFS server from outside your organization.
Opening your NFS port through the firewall may enable someone to guess, steal, or forge file handles such that they can access your other files.
A misconfiguration of your NFS or a bug in the software may open your system to attack via the NFS subsystem.
By opening your NFS port to the outside, you may enable your users to access other NFS partitions from unsecured systems that are susceptible to eavesdropping or hijacking.

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 15.4.1.1 later in this chapter.

Note

Under some old versions of Unix, there was a problem if you exported any of your filesystems to yourself by name, by netgroup, or to localhost. This came about if your RPC portmapper had proxy forwarding enabled (often the default). If proxy forwarding was enabled, an attacker could carefully craft NFS packets and send them to the portmapper, which in turn forwarded them to the NFS server. As the packets came from the portmapper process (which was running as root), they appeared to be coming from a trusted system. This configuration could allow anyone to alter and delete files at will.

We are uncertain which systems may still harbor this vulnerability. Thus, caution is the prudent course of action if you feel the need to make such loopback mounts.

The showmount Command

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:

-a: Lists all of the hosts and which directories they have mounted
-d: Lists only the directories that have been remotely mounted
-e: Lists all of the filesystems that are exported; this option is described in more detail later in this chapter

Tip

The showmount command does not tell you which hosts are actually using your exported filesystems; it shows you only the names of the hosts that have mounted your filesystems since the last reset of the local log file. Because of the design of NFS, someone can use a filesystem without first mounting it.

^[219]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.

^[220]For performance reasons, there is often more than one server process running.

Previous Chapter

Understanding NFS

Next Chapter

Client-Side NFS Security