	Department of Engineering

University of Cambridge > Engineering Department > computing help

X Security

Introduction
Terminology
MIT-MAGIC-COOKIE-1
Host Access control
Server-specific hints
What CUED users should do
Credits and further reading

1. Introduction

X provides you with enormously powerful tools, but if not set up properly it can also make you very vulnerable to attack by less scrupulous members of the international network community. There are some simple precautions you can take to protect yourself, but unfortunately many X servers come out of the box with all the security switches in the 'off' position: it is up to you to turn them on. This document explains how to protect yourself. The last section gives specific information about some of the commoner X servers.

Other relevant man pages are xhost, xauth, and xdm.

2. Terminology

It is important to understand the terms 'server' and 'client' when discussing X security. You can think of the server as being the terminal you are sitting at; there will be a keyboard, a mouse, a screen and some associated hardware and software. The server could be a workstation, an X-terminal or a PC running (for example) Vista eXceed.

The X clients are programs that make use of the X server, for example xterm, xclock and emacs. They identify the server by means of the $DISPLAY environment variable, or the -display command-line argument.

It is the server that polices security, by deciding which clients are allowed to connect to it. There are two mechanisms you are likely to come across: MIT- MAGIC-COOKIE-1 and Host Access.

In addition to the server and client is the machine I will refer to as the local host; this is the computer that runs xdm (the program that logs you in) and is responsible for managing your collection of windows. If your X server is a workstation then it will be that; if your server is an X-terminal then it will be some other computer. It is the computer that presents a window inviting you to login. Your server documentation will refer to XDMCP; this is the protocol used to communicate with xdm.

3. MIT-MAGIC-COOKIE-1

3.1 Overview

This is the most secure mechanism, and generally to be recommended. The X server has a 'cookie' which is like a temporary password. Only clients who know the password are allowed to access the server.

The cookie is generated by xdm and stored in your home directory in the file .Xauthority. This file is maintained by the xauth program.

There are three stages to setting up magic cookie authorisation:

Enabling security on the X server.
Ensuring xdm generates the magic cookie on the local host.
Copying the magic cookie to other computers on which you wish to run clients.

3.2 Enabling security on the X server

Note: you needn't worry about this section if you only work on the CUED Teaching System. Go straight to section 6

Many X servers by default perform no checks at all on which clients are allowed to connect. The details of reconfiguration depend on your server, but usually what you have to do is enable host access control but supply an empty list of allowable hosts. Sometimes it is necessary to include at least one host in the list; use something safe (e.g. the name of the server).

Some servers allow you to use the xhost command on the local host to adjust the configuration. The Bourne/Korn shell commands

  xhost -
  for h in `xhost | tail +2` ; do xhost -$h; done

will enable security and remove all entries from the access list. They can conveniently be included in your .xsession file, or whatever the equivalent is for your particular local host; both are needed. Unfortunately they do not work for PCs running Vista eXceed.

See section 5 for server-specific information.

3.3 Ensuring xdm generates the magic cookie on the local host

xdm needs to be configured correctly in order to generate magic cookies; this is the responsibility of whoever administers the local host. He or she should ensure that the xdm resource 'DisplayManager*authorize' is set to 'true'. This has already been done on the Teaching System.

Once xdm is configured correctly, every time you login it will insert the magic cookie into your file ~/.Xauthority on the local host. You can check this by typing

  xauth list

and verifying there is an entry for your current display.

3.4 Copying the magic cookie to client computers

You are now able to run X clients on the local host, but often you will want to run X clients on other computers too. Before you can do so you need to ensure the magic cookie is copied to ~/.Xauthority on the remote computer; clients will find it there and present it to the server for validation.

If your home directory is shared with the remote machine by NFS then no copying is needed and clients can be started without further ado. But in the more general case it must be transferred.

If the remote machine trusts the local one (type "man hosts.equiv" for details about this), you can use

  xauth extract - $DISPLAY | remsh remhost  xauth merge -

to extract the magic cookie from the local .Xauthority and incorporate it in the remote one.

If xauth is not found on the remote machine then try the full path name (/usr/bin/X11/xauth, perhaps). If remsh isn't found on the local machine, try rsh.

Once the magic cookie has been copied you can start the X client on the remote machine. Either start it with remsh, rsh, xon or use rlogin to login and then start it. Unless you're using xon you must ensure that the DISPLAY environment variable is set correctly.

4. Host Access control

This is sometimes simpler to use, but only provides very limited security. It is useful in situations where your X clients run on single-user workstations, or on machines where all the other users can be trusted. Also some old X servers do not support magic cookie authorisation, so you have no choice.

It works by you configuring your server to allow X connections from ALL users on a specified list of machines. The configuration can be done by

a setup menu on an X terminal
the access setup option program in Vista eXceed (Xconfig/W)
the xhost command

For example

  xhost +zx81.rummidge.ac.uk

allows any user on the zx81 machine to run an X client connecting to your X server.

The xhost command without any parameters lists the current access list. If it reports

  access control disabled, clients can connect from any host

then security is disabled and you are asking for serious trouble.

        xhost -

will make you safe (for the current session).

We don't recommend using xhost to authorise the CUED machines.

5. Server-specific hints

5.1 NCD X-terminals

NCD X-terminals are normally configured by the system manager at your local site. He or she should edit the configuration file to include the lines

xserver-access-control-enabled = on
xserver-access-control-enabled-default = on
xserver-access-control-list = {}
exec-access-control-enabled = true
exec-access-control-list = {}
config-access-control-enabled = true
config-access-control-list = {}

These values can also be set on the Access Control section of the Setup menu, but they will be lost when the terminal is rebooted.

5.2 Pericom X-terminals

(a)  Select 'Set X parameters'.

(b)  Toggle 'Host access control' to 'Enabled'.

(c)  Set 'Initial access host' to the numeric Internet address of your terminal
     (if you don't know it look in /etc/hosts).

(d)  Set 'Retain X settings on recycle' to 'No'.

(e)  Select 'Save/restore configuration parameters'.

(f)  Select 'Save current changes to NVRAM'.

5.3 Silicon Graphics Workstations

(a)  Create file /etc/X0.hosts containing single character '-'

(b)  Check for lines 'xhost +' in /usr/lib/X11/xdm/Xsession-remote,
     /usr/lib/X11/xdm/Xsession and /usr/lib/X11/xdm/Xsession.dt ; replace them
     with 'xhost -'. Repeat this whenever you upgrade the operating system.

(c)  Change /usr/lib/X11/xdm/xdm-config so that 'DisplayManager*authorize' is
     set to 'true'.

5.4 PCs running Vista eXceed

The following recipe works on version 3.3.2:

(a)  Click on XConfig program and select 'Access' option.

(b)  Select 'Edit'. You are now editing a configuration file (access.src),
     which should include detailed instructions. Insert a line containing

       /SECURITY

     and make sure there are no lines containing

       /ACCESS

(c)  Save the file, exit from the editor and then select 'Compile'.

If using version 3.0.1 of Vista eXceed the format of the file access.src is different; it is simply a list of hosts which are allowed access. Unfortunately you are not allowed to create an empty list, so you have to include one safe host. The safest one is the IP name of your PC; this must correspond with the name in the hosts file, which you can see by selecting 'Communication' in the XConfig/W window and then 'Edit hosts file'. After changing the access rules (either version) you need to logoff and login again in order for them to take effect.

6. What CUED users should do

First, remove all xhost calls from all setup files that you may have (.xsession, .profile, .twmrc etc).

Get whoever looks after the machine to check that the system configuration files enable the Xauthority mechanism (see earlier sections)

If you're using Xwin see the X-Win32 configuration page.

If you have the same directory on all the machines you use (in particular, if you only use the Teaching System) then all you have to do to use remote X clients is to set the DISPLAY on the remote machine or use xon. See the Frequently Asked Questions for details.

However, if you use distinct systems then you have to get the per-session information put in .Xauthority at the start of each session from the local machine to the remote one, so that programs run remotely can pick up the per-session "password". The Teaching System's xon program has an option that supports this, (e.g. "xon remote-host -passxauth xclock") as long as your .rhosts on the distant machine is ok (see below).

If this doesn't work, or you're not on the Teaching System, you may have to try copying the whole file over, or transfering only the relevant information by doing

xauth extract - $DISPLAY | remsh remote-host xauth merge -

at the start of each session. This line might fail for at least 3 reasons

remshd: Login incorrect or Permission Denied - You're not set up to run programs remotely. In your home directory on the remote machine create a file called .rhosts. On the first line of this file put the full name of the local machine, a space, and your uid. Then try the xauth command line again. If it still fails, type chmod a+x ~ ; chmod a+r ~/.rhosts on the remote machine in case the system can't access the file.
xauth not found - try
... remsh remote-host /usr/bin/X11/xauth ...
instead.
No error message, but still no X access allowed - try `hostname`:0 instead of $DISPLAY in the above command line. If that fails, type "xauth list" and see how you machine is named there. Try using that name instead of `hostname` in the line above.

If you can't get in touch with the system manager, mail Tim Love (tpl@eng.cam.ac.uk) giving the machine name, machine type, operating system name and version.

Credits and further reading

unix-support@ucs.cam.ac.uk provide a useful document on Remote access to Unix machines.
The CIAC document on Securing X Windowsis worth a read.

The original of this document was produced by

Bob Vickers (Systems Group, ULCC)
UNIVERSITY OF LONDON COMPUTER CENTRE
20 Guilford Street
London  WC1N 1DZ
Tel:  +44 171-405 8400

The localisation was done by Tim Love (CUED)

| computing help |