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
- 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:
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,
- Make sure the xdm-config file contains these lines:
- Shutdown and reboot the system.
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
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
You toggle Secure Keyboard mode with these steps:
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.
- Make sure the mouse cursor is in the xterm window
- Hold down the <Ctrl> key and press down the Left mouse
- Move the mouse down to select Secure Keyboard from the Main
- 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
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
Back to the Unix System Security
Dave Dittrich <email@example.com>
Last modified: Thu Feb 5 15:33:10 PST 1998