4 Common Desktop Environment

This chapter discusses CDE (Common Desktop Environment) features that improve the security of a workstation.

4.1 External Access to Your Display

When you log in to a workstation and create a session, the CDE login program sets the initial controls on access to the workstation. Any client that has access to the workstation display has full access to all events and resources of the X server, including the following:

The ability to capture events such as keyboard and mouse events that include passwords or confidential information, even if it is not echoed when typed.

The ability to send simulated events, including keystrokes, to windows on the display. For instance, a malicious user could send synthetic keystrokes to a terminal emulator window forming commands that would be executed under the UID of the logged in user.

The ability to capture a snapshot of any part of the screen by setting the background pixmap of a window to None.

The ability to display windows on the screen that masquerade as known programs (trojan horses).

4.2 Controlling Network Access to Your Workstation

Controlling access to your workstation display is the key to creating a secure workstation environment. Access is controlled by the following mechanisms:

Host Access: Any client on a host in the host access control list is allowed access to the X server. This is most useful in an environment where everyone trusts everyone, or where each host has only one user. The list of authorized hosts is controlled by the xhost command. The CDE login program by default starts the session with an empty host access list and uses the more secure access mechanisms. You can add hosts to the host access control list by putting xhost commands in your .dtprofile. See the xhost(1X) reference page for more information.
MIT-MAGIC-COOKIE-1: The CDE login program creates a 128-bit cookie when it starts the X server. A client is only allowed to connect if it presents the same cookie with the connection setup request. The cookie is chosen so that it is hard to guess, but it is transmitted on the network without encryption, so that it is susceptible to snooping. This is most useful where multiple users use the same machine, but network snooping is not an issue.
XDM-AUTHORIZATION-1: This is similar to MIT-MAGIC-COOKIE-1, except that the cookie data is encrypted using DES along with a time stamp to prevent snooping. This may not be available in all countries.

See the XSecurity(1X) reference page for more information about access control mechanisms.

Remember that hosts that are authorized to access your workstation display can read from it, write to it, and copy from it at any time. Restricting access is the only way to prevent users from taking a snapshot of the contents of your workstation display.

4.2.1 Host Access Control List

The X server maintains a host access control list to decide whether to allow connections from clients on a particular host. When a session is started, the host access control list is initialized from the file called /etc/Xn.hosts, where n is the display number. The host access control list is reinitialized for each session even if the server is not restarted. For example, X0.hosts is the initial list of hosts that are authorized to connect to display 0, which is usually the default display.

Each line of the /etc/Xn.hosts file is the name of a host, optionally preceded by the name of its address family. Adding a host to the host access control list enables any client running on that host to access the server.

The xhost utility can be used to add or remove hosts from the host access control list. See the xhost(1X) reference page for more details.

Allowing remote systems to access your account on a workstation is a security concern. Check with your security administrator before authorizing additional hosts to use your workstation display.

4.2.2 Authorization Data

For the MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1 mechanisms, the data needed by the server to generate the authorization information is the same as the data needed by the clients. The login program stores the authorization data in a file. The default is $HOME/.Xauthority.

This is particularly useful in an environment where the users' home directories are exported by NFS. Once you log in on a workstation, your authorization data is available to authorize connections from any host that has his home directory is mounted.

4.2.3 Using the X Authority File Utility

The xauth program allows you to run client applications on other hosts that do not share the home directory. You use the xauth program to edit and display the authorization information used to connect to the X server. You usually use this program to extract authorization records from one machine and merge them in on another (as is the case when using remote logins or granting access to other users). Note that this program does not contact the X server.

Using the X authority file utility is the recommended method of securing your workstation. For more information, see the xauth(1X) reference page and the X Window System Environment manual.

4.3 Protecting Screen Information

Any client given access to the display can access all the resources of the display, including all windows. If you display sensitive information on the screen, be careful about what hosts, if any, are enabled in the host access list. If a host is enabled, any user who can log in to that host has full access to the display resources.

By default, the $HOME/.Xauthority file is protected so that it is owned by the login user and is readable only by the login user. If you use an authorization mechanism that stores data in the $HOME/.Xauthority file and your home directory is exported with NFS, the workstation security is only as good as the NFS file security.

Normally when a window is created with a background pixmap resource set to the special value of None, the initial contents of the window are set to whatever is on the screen within the bounds of the window when it is first mapped. To prevent other clients from capturing snapshots of the screen using this feature, there is an optional command line parameter to the X server that disables it. To set the parameter, add the +sec_objectreuse option to the X server command line in the /var/dt/Xservers file.

4.4 Blocking Keyboard and Mouse Information

By default, dtterm and xterm windows ignore synthetic keyboard and mouse events sent by other clients. This security feature prevents unauthorized users from sending potentially destructive commands to your workstation when it is idle.

The ability of a dtterm window to block information sent from another host is set by a resource called allowSendEvents. If it is necessary to allow all dtterm or xterm windows to accept synthetic events, the resource can be set in a $HOME/.Xdefaults file.

The following example shows a line in the .Xdefaults file that sets the allowSendEvents resource to true, allowing other clients to send keyboard or mouse information to any window that you create:

     dtterm*allowSendEvents:  true

If it is only necessary to enable synthetic events for specific terminal windows for some specific purpose, it is better to set the allowSendEvents resource with the -xrm command line option. For example:

     % xterm -xrm "*allowSendEvents: true"

Alternatively, the special terminal emulator can be started with a different resource name and the $HOME/.Xdefaults can set the resource only for terminal emulators run with the special name. For example, if the $HOME/.Xdefaults file contains this line:

     foo*allowSendEvents: true

The synthetic events are allowed only by terminal emulators that are run as follows:

     % /usr/dt/bin/dtterm -name foo

Other applications may or may not accept synthetic keyboard and mouse events.

4.5 Pausing Your Workstation

In a CDE environment, you can pause your current session. This locks your workstation without ending your session. Your screen is cleared, and the system displays the screen saver. You can resume your session any time without re-creating your screen environment.

To put your current session on hold, click on the Padlock on the dashboard. Your screen is cleared and the Continue Session box is displayed. To continue your session, type your password then and press Return. Once your password is verified, your session resumes.

CDE provides a Screen Lock feature that automatically pauses your session after a period of inactivity. The Screen Lock feature is disabled by default and works with or without enhanced security enabled. The Screen Lock Start Lock (inactivity) time period can be set from 1 to 120 minutes with the default being 30 minutes.

Compaq recommends that you enable the Screen Lock feature and set the Start Lock time at a maximum of 10 minutes.

4.6 Workstation Physical Security

Workstations present security problems because they are typically found in ordinary offices, rather than the more easily protected environment of the computer room.

It is possible for someone who gains access to a workstation, to get superuser status on that system, and consequently on other systems. One method is to boot the system into single user mode.

If your office has a locking door, lock the door when you are away from your system.

You must also protect your removable media, such as tape cartridges and floppy disks by locking up all floppy disks and tape cartridges when they are not in use.

Some workstations allow a console password to be set. When a console password is in use, only a default boot can be done without a password. Check your hardware and firmware documentation for more information about console passwords.