Safely Using the X Window System

The X Window System is a very flexible, full-featured windowing system that gives you the power to run graphical clients from any workstation, anywhere on the Internet and/or to shoot yourself in the foot at the same time (by leaving your terminal open to keyboard "snooping" or allowing someone to "take over" your login session).

The following information comes from various sources, including:

To understand the problem and solution, first read what the author's of SATAN have to say about the vulnerabilities of X. This tutorial mentions the programs xhost and xauth, but doesn't explain their role in X11 and their use.

In short, X11 (release 4 and higher) supports two main methods of access control:

Host-based access control

This method grants access to your X server on a per-host basis. This means that if you grant access to a given computer, any person with an account on that computer, running any X client program, can access your server (i.e., your screen and keyboard). With access control turned off (such as happens when you use the command xhost +) this access extends to any person on any of the several million hosts on the Internet!

Sometimes, either workstation vendors or users will use the xhost + command in the system XSession file, the user's .xsession file, or some other script, to disable access control. Usually this is to make life "easier" for the user. An equally simple, yet more secure way of running X clients, is discussed in a moment.

For more information on host-based access control, see the X Window System Administrator's Guide, section 4.1.

User-level access control with the MIT-MAGIC-COOKIE-1 authorization

This method involves a unique validation token that is known only to the X server and the person who last logged on to a system using this server. This unique token is obtained by X clients when you start them and given to the server. If the token matches the one that the server holds, access is granted. If not, access is disallowed by this means. Since the file that holds this token is not readable by any account but the user who just logged in, only that user can connect to the server.

For more information on MIT-MAGIC-COOKIE-1 authorization, see the X Window System Administrator's Guide, section 4.2.

How xdm implements authorization

User-level access controls with the MIT-MAGIC-COOKIE-1 authorization protocol are normally implemented by using the X Display Manager (xdm), which "controls" X terminals and provides a "login" window on the X terminal's display. If your system does not use xdm by default, you should either find out what mechanism(s) have been provided in your vendor's own window system, or to setup and run xdm on your system.

Configuration of xdm is described in detail in the X Window System Administrator's Guide, chapter 3. The basic steps are:

  1. Make sure the xdm-config file contains these lines:

    DisplayManager._0.authorize: true
    DisplayManager*authorize: false

  2. Shutdown and reboot the system.

When xdm verifies a user's login name and password, it will generate an authentication token (the "MAGIC COOKIE") for this user's session. It makes sure the X server also contains this authentication token and it places a copy in the user's home directory in a file named .Xauthority. The .Xauthority file can be manipulated with the command xauth. For example,

host% xauth list
foobar.cac.washington.edu:0 MIT-MAGIC-COOKIE-1 dbfdbf59f8a2d93c917b5ad70359
blurty.u.washington.edu:0 MIT-MAGIC-COOKIE-1 15827e86fc0cdf0464c1e559cc1c
bloop.u.washington.edu:0 MIT-MAGIC-COOKIE-1 1effca1bb891f6f764cd8293d0c9

The user can thus extract and transfer their authentication token to an account on another system using the xauth and rsh programs (see "man xauth", "man rhosts" and "man rsh" for details). To start a program on remotehost, a command sequence like this would be used:

host% xauth extract - $DISPLAY | rsh remotehost xauth merge -
host% rlogin remotehost
remotehost% xclient -display your.x.server.dns-name:0 &

An easier tool to use is the program xrsh, which is available from ftp://ftp.x.org/contrib/utilities. With this program, the above example becomes simply:

host% xrsh remotehost xclient

Note: See also the CERT Vendor-Initiated Bulletin VB-95:08 for information on vulnerabilities with X Authorization.

Secure Keyboard mode of the xterm client

The xterm client has another mechanism for ensuring that keystrokes cannot be "snooped" by programs that are connected to your X server, called Secure Keyboard mode. This feature of xterm is explained the X Window System Administrator's Guide, section 4.5.

You toggle Secure Keyboard mode with these steps:

  1. Make sure the mouse cursor is in the xterm window
  2. Hold down the <Ctrl> key and press down the Left mouse button
  3. Move the mouse down to select Secure Keyboard from the Main Menu
  4. If Secure Keyboard mode is enabled, the screen will reverse its foreground and background colors; if you don't see this happen, Secure Keyboard mode was not enabled
Note: You should enable Secure Keyboard mode before typing your password, then disable it. You cannot simply leave xterm in Secure Keyboard mode all the time. The reason for this is that Secure Keyboard mode can and does interfere with functioning of the window manager and can prevent you from moving windows or changing window order on your screen.

Details, details...

There are more issues involved with configuration of X terminals, XDM control, etc., that are not covered here. If you are a University of Washington faculty/staff/student, and have any questions or are unclear about anything mentioned here, send email to help@cac.washington.edu.

Back to the Unix System Security Checklist.

since 03/22/96
Dave Dittrich <dittrich@cac.washington.edu>
Last modified: Thu Feb 5 15:33:10 PST 1998