[Chapter 20] 20.2 Server-Side NFS Security

20.2 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 only access and alter 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.

20.2.1 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 the unauthorized users on that host will not be able to access the server's files.

20.2.1.1 /etc/exports

Many versions of UNIX , including Sun's SunOS, HP's HP-UX, and SGI 's IRIX operating systems use the /etc/exports file to designate which clients can mount the server's filesystem and what access those clients are to 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 options for each directory. These include:

access=machinelist: Grants access to this filesystem only to the hosts or netgroups[8] specified in machinelist . The names of hosts and netgroups are listed and separated by colons (e.g., host1:host2:group3) . A maximum of ten hosts or group names can be listed in some older systems (check your documentation).[9]

[8] See the discussion of RPC and netgroups in Chapter 19.

[9] 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.
ro: Exports the directory and its contents as read-only to all clients. This options 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 what user ID to use on NFS requests that are not accompanied by a user ID, such as might happen from 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 19, RPC, NIS, NIS+, and Kerberos ) for more information.

You should understand that NFS maintains options on a per-filesystem basis, not 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.

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.

20.2.1.2 /usr/etc/exportfs

The /usr/etc/exportfs program reads the /etc/exports file and configures the NFS server, which runs 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.

20.2.1.3 Exporting NFS directories under System V: share and dfstab

Versions of NFS that are present on System V systems (including Solaris 2.x) 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 called 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]

where FSType should be nfs for NFS filesystems, and specific_options are the same as those documented with the /etc/exportfs file earlier. 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. For example:

Example 20.1: An /etc/dfs/dfstab file With Some Problems

#       place share(1M) commands here for automatic execution
#       on 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.

Do you see the security hole in the above configuration? It's explained in detail in Section 20.4, "Improving NFS Security " later in this chapter.

NOTE: Do not export your filesystems back to your own machine if your RPC portmapper has proxy forwarding enabled (the default in many vendor versions). You should not export your partitions to the local host, either by name or to the alias localhost , and you should not export to any netgroups of which your host is a member. If proxy forwarding is enabled, an attacker can carefully craft NFS packets and send them to the portmapper , which in turn forwards them to the NFS server. As the packets come from the portmapper process (which is running as root), they appear to be coming from a trusted system. This configuration can allow anyone to alter and delete files at will.

20.2.2 The showmount Command

You can use the UNIX command /usr/etc/showmount 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.

NOTE: 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 , you can use a filesystem without first mounting it.

The Linux NFS server offers a sophisticated set of options that can be placed in the /etc/exports file. While these options seem to increase security, they actually don't.

The options are:

secure: This option requires that incoming NFS requests come from an IP port less than 1024, one of the "secure" ports. This requirement prevents an attacker from sending requests directly to your NFS server unless the attacker has obtained superuser access. (Of course, if the attacker has obtained root access, this option does not help.) This option is equivalent to NFS port monitoring under other versions of UNIX (e.g., nfs_portmon under SunOS).
root_squash: Forces requests from UID 0 to be mapped to the anonymous UID . Unfortunately, this option does not protect other UIDS .
no_root_squash: Turns off root squashing. Even less secure.
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 UID s.
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?