Using X Window
Last revision August 6, 2004
| Table of Contents: |
X Window authentication and security
Most X servers provide a way to keep unwanted client programs from opening windows on the display. You don't want other people to be able to randomly open windows on your workstation. In particular, you want to prevent hackers using other computers on the network from running a spy client that will access your display and secretly let the hacker see what you are typing, including any passwords you may type. Such spy programs have been distributed in the hacker community.
X-terminals and X server software running on Macintosh or PC computers may have specific mechanisms for controlling access. Often, you can turn on an option that prompts you to authorize every X client program that is attempting to connect to your X server. If you get such a prompt when you don't expect it, say No.
For X displays attached to Unix workstations (that is, the workstation console display), or for remote X servers connecting via the XDMCP protocol, the most common methods of access control are either host based, or account based, using the MIT-MAGIC-COOKIE protocol.
Finally, you can use an ssh X Window tunnel to make a secure connection between the computer with the X Window server program (your PC or Mac, for example), and the computer running the X client programs (pangea, for example). This tunnel encrypts all traffic and guarantees that only the client programs that you run can use the display.
Host based access control
For host based access control, you can permit all clients from a particular host, or none, to have access to your display while you are logged in. Unfortunately, this form of access control does not allow you to selectively list client programs or user accounts that can have access to the display. It either allows all users and programs from a specific computer to have access, or none.
It is better to use the account based MIT-MAGIC-COOKIE form of access control, or an ssh tunnel, if those are available. But if host based access is the only available method, you should be sure to prohibit access from all computers except the ones where you are running X client programs. Often, host based control defaults to letting any program on any computer access your X window server.
The X server stores the list of allowed hosts while it is running. Some window managers allow you to modify this list using a special menu item. Otherwise, the Unix xhost command can modify the list when run from a computer that has control of the display. This would be the case if you were logged into the graphics console of a Unix workstation, or if your X terminal has started an XDMCP session with the Unix workstation.
With no options or arguments, the xhost command shows you which computer hosts currently have access to the display. Plus (+) or minus (-) options, followed by a computer name, allow you to grant or deny access to specific computer hosts. With no computer name following, the plus and minus options apply to all computers on the network. Appropriate xhost commands can be included in your .xsession or equivalent X startup script. Examples:
xhost -
Prohibit access from any computer on the network, unless it is specifically given
access via an xhost + command. You should first add the controlling
computer (the one where you run the xhost command) to the list of
allowed computers, for example, xhost +pangea. Then you can run xhost
- to prohibit all other computers not in the allowed list from accessing
the display. If you don't explicitly allow the controlling computer first, then
even it will not be allowed access and you won't even be able to issue additional
xhost commands. It is a good idea to run the sequence of xhost commands
shown above in your startup script to set initial access to the controlling computer
only. Then you can issue additional xhost commands to permit access
to other hosts where you generally run X client programs.
xhost +
Turns off access controls. That is, X client programs on any
computer on the network are allowed to access the local display. Never
issue this command. This is an open invitation to hackers to try to spy on or
disrupt your X sessions. Unfortunately, some X window server programs start up
in this state, where they allow access by anyone. So you need to take positive
steps to limit access.
xhost +banach.stanford.edu
Allow X client programs running on banach.stanford.edu to have access
to your display. You might issue this command just before running an X client
program on banach.
xhost -nana.stanford.edu
Explicitly prohibit client programs on nana.stanford.edu to have
access to my display. You might run this command after you have started X clients
from nana, in order to prevent further unauthorized clients on nana
from accessing your display.
The host based access method controlled by the xhost command either allows all users on a particular host to connect X client applications to your display, or none. On a multi-user system this leaves you open to pranks or deliberate interference by other users. For this reason, the account based control method described below is preferred.
In a situation where the X server only supports host based access, one strategy for using it is to issue the appropriate xhost command, allowing access from a particular host only, just before you run the X client you want from that host, and then to deny access again. For example, if you are logged into an X session on the console of a workstation called fuego, and you want to display a load monitor for pangea on my display, you might use the following commands to temporarily grant access to your display from pangea X clients only long enough to run the needed xload command on pangea.
xhost +pangea
ssh pangea xload -display fuego:0 &
xhost -pangea
Account based access control via MIT-MAGIC-COOKIE
An obvious improvement over host based access control would be to have a system that could recognize when an X client is started by you, regardless of which host it is running on, and only allow those clients to display on your X login session. The MIT-MAGIC-COOKIE protocol is an attempt to implement such a system. This protocol is supported by all modern built-in X servers on Unix workstations. For remote X terminals and PCs/Macs running X server software, it depends upon cooperation between the X software program on the remote terminal or PC, and the Unix process (usually xdm) that implements the XDMCP protocol. Again, this should not be a problem for modern systems.
When an X session is started via login on the Unix console or via XDMCP, the X server generates a random string of bytes, called an authorization record or cookie, which is stored in the file .Xauthority in the user's home directory. The permissions on this file are set so that only the user's account can read it. When X clients start, they automatically attempt to read the .Xauthority file and supply the information therein to the X server as their cookie to get access. Only X clients that you start will have access to the correct .Xauthority file to get the correct information to be allowed access to your X login session display.
Of course, you would like your accounts on other computers to have access to that same .Xauthority file so they, too, can run X client programs that display in your X login session. This can be done transparently if your home directory is shared from a central server by a set of computers. Or, you can propagate that .Xauthority file yourself to your accounts on other computers. To do this, use the xauth command to extract the authorization record from the home machine to which your X server is connected; move that record to the remote machine (for example, with scp, or ftp; and then run xauth again on the remote machine to merge the authorization record into your .Xauthority file on that machine. See the online manual entry for xauth for an example of a single command that does all three steps in an rsh pipeline, and for details on command options. After you have copied the authorization record to the remote computer, you can run X clients from that computer to display on your current X login session.
This MIT-MAGIC-COOKIE protocol is not foolproof. For example, in the case of a remote X server connected to a Unix machine via XDMCP, someone with the ability to run a sniffer program on a computer attached to your local network may be able to capture the network packets between the host computer and your X display and decode the cookie. He could then use it to run X client programs that access your display. This is an extremely unlikely scenario in a normal workplace environment, however.
If an X server supports both the host based access control managed by the xhost command and the MIT-MAGIC-COOKIE account based authorization system, the less restrictive one may be applied by default. eXodus for the Macintosh is such a server. That is, the server may automatically add the current login host (or even any host) to the list of allowed hosts for X clients, thus bypassing the account based authorization requirements. It is a good idea to run the xhost command to see what host based access is in effect. To force the account based access to be used, you may have to disallow all host based access, using the xhost - command described above.
ssh X Window tunnels
The host based and magic cookie access controls described above are built-in to the X Window protocol and are easy to use and fairly effective if your X display has a controlling computer and all your client programs will run on that computer. You will have a controlling computer if you login to the directly attached graphics console of that computer or if you start an XDMCP session from that computer to your X terminal.
If you want to run client programs from multiple computers, or use an X terminal in a rootless mode where individual client programs can open windows, but there is no X session from a controlling computer, then the host based and magic cookie access methods either fail to work or are very cumbersome to use. In this case, there is a much better alternative: use the ssh program with an X Window tunnel. This is not a part of the X Window protocol, but has been designed to work with it.
Normally, X client programs on each remote computer make a direct connection to your display, and thus have to be listed in the host access list or supply the correct magic cookie to work. Ssh X tunnels trick the client programs into thinking that they are displaying directly on an attached console, where they always have permission to run, even under the most restrictive settings, and trick the X display into thinking that the client program is running locally and has the proper magic cookie. Then ssh makes a network tunnel to transfer the actual X Window commands and data between the client computer and X display server.
Because you must supply your password on each remote computer to start up the tunnel with ssh, and because your password and all the X Window commands and data are encrypted before they are sent on the network, ssh tunnels provide a very high level of security and privacy.