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 might be able to access the physical devices of the server using the special files of the client device.
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 runsetuid 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 might not match between the server and client, so users on the server might be able to run programs with capabilities that were not intended for them.
The problem exists because the setuid and setgid programs and device-special files should 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 is 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 is also used for any file system that is being mounted for use only by a different host (for example, exported for diskless clients).
Although the file system of a diskless workstation is mounted from a server /exports directory, to the diskless machine, 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 do 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 might want to mount this
directory with the following options of the mount command:
| nosuid | Prevents a user on the server from running the setuid programs of the client |
| nodev | Prevents a user from accessing the server devices using a device-special file of the client. |
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 is exported with read-only permissions and must provide root
access. However, you might want to mount this directory with the
following options of the mount command:
The /export/share directory is 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 /home directory:
| nosuid | Prevents a user on the server from running the setuid programs of the client. |
| nodev | Prevents a user from accessing the server devices using a device-special file of the client. |
Export the /export/dump/Clienthostname directory with read/write permissions and root access. Users on the server do 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 do not have any access to the /export/swap/Clienthostname files.