Diskless workstations must have the ability to create and access device-special files on remote machines to have their /dev directories mounted from a server. Because servers cannot distinguish device-special files intended for a client from those intended for the server, a user on the server may be able to access the server's physical devices using the client's device special files.
For example, the ownership for a tty is automatically set to the user using the tty. If the user IDs are not the same on both the client and server, a nonprivileged user on the server can access a tty that is being used by a different user on the server.
A user who is privileged on a client can create device-special files to match physical devices on the server and have them not require privilege for access. The user can then use an unprivileged account on the server to access the normally protected devices using the new device-special files.
A similar security problem involves the use of setuid and setgid programs on the client and server. Diskless clients must be able to create and execute setuid and setgid programs on the server for normal operation. Again, the server cannot distinguish between those programs intended for the server and those intended for the client.
In addition, the user IDs and group IDs may not match between the server and client, so users on the server may be able to run programs with capabilities that were not intended for them.
The problem is that setuid and setgid programs and device-special files should generally only be usable on the machine that created them.
The solution is to use security options to the mount command that restrict the ability to use these objects. These options can also be used in stanzas in the /etc/filesystems file.
The nosuid option in the mount command prevents the execution of setuid and setgid programs that are accessed via the resulting mounted file system. This option should be used for any file system that is being mounted on a particular host for use only by a different host (for example, exported for diskless clients).
The nodev option in the mount command prevents the opening of devices using device special files that are accessed via the resulting mounted file system. This option should also be used for any file system that is being mounted for use only by a different host (for example, exported for diskless clients).
Although a diskless workstation's file systems are mounted from a server's /exports directory, from the diskless machine's perspective, the file system looks just like the file system on a standalone machine.
The following shows the relationship between server exports, and the diskless workstation mount points:
For more information about the /export directory, see "Understanding the /export Directory".
In general, users on a server should not have any access to the /export directory.
The /export/root directory must be exported with read/write permissions, and the root user on the server must have access. However, you may want to mount this directory with the following options of the mount command:
| nosuid | Prevents a user on the server from running the client's setuid programs. |
| nodev | Prevents a user from accessing the server's devices using a client's device- special file. |
An alternative to mounting the /export/root directory with these options is to avoid giving users running on the server any access to the /export/root directory.
The /export/exec directory should be exported with read-only permissions and must provide root access. However, you may want to mount this directory with the following options of the mount command:
The /export/share directory should be exported with read-only permissions and must provide root access. Because this directory generally contains only data (no executables or devices), you do not need to use the mount security options.
There are several ways to mount a user's /home directory:
| nosuid | Prevents a user on the server from running the client's setuid programs. |
| nodev | Prevents a user from accessing the server's devices using a client's device-special file. |
Export the /export/dump/ClientHostName directory with read/write permissions and root access. Users on the server should not have any access to the /export/dump/ClientHostName files.
Export the /export/swap/ClientHostName file with read/write permissions and root access. No security measures are necessary. Users on the server should not have any access to the /export/swap/ClientHostName files.