Managing NFS and NIS, 2nd Edition - Mike Eisler [147]
Most implementations of NFS allow the root UID mapping to be defeated. Some do this by letting you change the UID used for nobody in the server's kernel. Others do this by letting you specify the UID for the anonymous user at the time you export the filesystem. For example, in this line in /etc/dfs/dfstab:
share -o ro,anon=0 /export/home/stuff
Changing the UID for nobody from 60001 to 0 allows the superuser to access all files exported from the server, which may be less restrictive than desired.
Most NFS servers let you 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/dfs/dfstab file:
share -o rw,root=bitatron:corvette /export/home/work
The superuser on hosts bitatron and corvette is given normal root filesystem privileges on the server's /export/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.
One 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 for cross-server mounted filesystems. Assuming that only the system administration staff is given superuser privileges on the file servers, extending these permissions across NFS mounts may make software distribution and maintenance a little easier. Again, the pitfalls await, but hopefully the community with networked root permissions is small and experienced enough to use these sharp instruments safely.
On the client side, you may want to protect the NFS client from foreign setuid executables of unknown origin. NFS-mounted setuid executables should not be trusted unless you control superuser access to the server from which they are mounted. If security on the NFS server is compromised, it's possible for the attacker to create setuid executables which will be found — and executed — by users who NFS mount the filesystem. The setuid process will have root permission on the host on which it is running, which means it can damage files on the local host. Execution of NFS-mounted setuid executables can be disabled with the nosuid mount option. This option may be specified as a suboption to the -o command-line flag, the automounter map entry, or in the /etc/vfstab entry:
automounter auto_local entry:
bin -ro,nosuid toolbox:/usr/local/bin
vfstab entry:
toolbox:/usr/local/bin - /usr/local/bin nfs - no ro,nosuid
A bonus is that on many systems, such as Solaris, the nosuid option also disables access to block and character device nodes (if not, check your system's documentation for a nodev option). NFS is a file access protocol and it doesn't allow remote device access. However it allows device nodes to be stored on file servers, and they are interpreted by the NFS client's operating system. So here is another problem with mounting without nosuid. Suppose under your NFS client's /dev directory you have a device node with permissions restricted to root or a select group of users. The device node might be protecting a sensitive resource, like an unmounted disk partition containing, say, personal information of every employee. Let's say the major device number is 100, and