Managing NFS and NIS, 2nd Edition - Mike Eisler [148]
The only clear-cut case where NFS filesystems should be mounted without the nosuid option is when the filesystem is a root partition of a diskless client. Here you have no choice, since diskless operation requires setuid execution and device access.
We've discussed problems with setuid and device nodes from the NFS client's perspective. There is also a server perspective. Solaris and other NFS server implementations have a nosuid option that applies to the exported filesystem:
share -o rw,nosuid /export/home/stuff
This option is highly recommended. Otherwise, malicious or careless users on your NFS clients could create setuid executables and device nodes that would allow a careless or cooperating user logged into the server to commit a security breach, such as gaining superuser access. Once again, the only clear-cut case where NFS filesystems should be exported without the nosuid (and nodev if your system supports it, and decouples nosuid from nodev semantics) option is when the filesystem is a root partition of a diskless client, because there is no choice if diskless operation is desired. You should ensure that any users logged into the diskless NFS server can't access the root partitions, lest the superuser on the diskless client is careless. Let's say the root partitions are all under /export/root. Then you should change the permissions of directory /export/root so that no one but superuser can access:
# chown root /export/root
# chmod 700 /export/root
Unknown user mapping
NFS handles requests that do not have valid credentials in them by mapping them to the anonymous user. There are several cases in which an NFS request has no valid credential structure in it:
The NFS client and server are using a more secure form of RPC like RPC/DH, but the user on the client has not provided the proper authentication information. RPC/DH will be discussed later in this chapter.
The client is a PC running PC/NFS, but the PC user has not supplied a valid username and password. The PC/NFS mechanisms used to establish user credentials are described in Section 10.3.
The client is not a Unix machine and cannot produce Unix-style credentials.
The request was fabricated (not sent by a real NFS client), and is simply missing the credentials structure.
Note that this is somewhat different behavior from Solaris 8 NFS servers. In Solaris 8 the default is that invalid credentials are rejected. The philosophy is that allowing an NFS user with an invalid credential is no different then allowing a user to log in as user nobody if he has forgotten his password. However, there is a way to override the default behavior:
share -o sec=sys:none,rw /export/home/engin
This says to export the filesystem, permitting AUTH_SYS credentials. However if a user's NFS request comes in with invalid credentials or non-AUTH_SYS security, treat and accept the user as anonymous. You can also map all users to anonymous, whether they have valid credentials or not:
share -o sec=none,rw /export/home/engin
By default, the anonymous user is nobody, so unknown users (making the credential-less requests) and superuser can access only files with world permissions set. The anon export option allows a server to change the mapping of anonymous requests. By setting the anonymous user ID in /etc/dfs/dfstab, the unknown user in an anonymous request is mapped to a well-known local user:
share -o rw,anon=100 /export/home/engin
In this example, any request that arrives without user credentials will be executed with UID 100. If /export/home/engin is owned by UID 100, this ensures that unknown users can access the directory once it is mounted. The user ID mapping does not affect the real or effective user ID of the process accessing the NFS-mounted file. The anonymous