SECURING X HOSTS WITH XHOST AND XAUTH

Because X interacts with your keyboard, mouse, and screen, leaving an X server unrestricted is a dangerous thing to do. Not only can it allow someone to pop up windows on your screen, but someone could run an "invisible" application that could capture keystrokes and mouse movement, or even silently observe the victim's entire display. You can use two built-in methods for locking down your X server: xhost and xauth.

Xhost

Xhost gives you hostname/IP-based control of who can connect to your X server. The syntax is extremely simple. To allow HOST2 to use HOST1 as a display, you need to make sure that HOST1's X server is running and issue the following command on HOST1 (from an X terminal window, for example):

 bash% xhost +HOST2

If you want to explicitly deny access to HOST2, try this:

 bash% xhost -HOST2

Fortunately, xhost denies all by default. You can use xhost to add specific hosts to your "allowed" list. You can also allow access on a global basis (disabling access control) by simply running xhost + . This is not recommended, as anyone with unfiltered network access to your machine will be able to run applications on your X server. xhost - will re-enable access control, allowing access only to the hosts in your "allowed" list. To see the machines that are currently allowed to use your X server, run xhost without any options.

Note	`xhost` commands only deny future access; they do not terminate current connections.

Xhost isn't a terribly secure method of access control, however, because it doesn't require a user -based password or token authentication, and there's no encryption. All you're really doing is allowing anyone on a particular system to access your X server. It's the same reason that IP-based access control on firewalls isn't a good solution for a Virtual Private Network (VPN); you're relying solely on hostnames or IP addresses to trust identity rather than asking the user at a particular IP address for identification. As we will see in the upcoming chapters, hostnames and IP addresses can be forged. For users familiar with TCP wrappers and rservices (rsh, rlogin, and so on), it's like putting all your faith in hosts.allow, hosts.deny, and hosts.equiv files to protect your X sessions.

Note	Using `xhost +` will override any and all of the security measures discussed in the next few sections. You should hardly ever run this command without specifying a hostname.

Xauth

Xauth is not actually an access control program, but rather a front end to the Xauthority file that the X server can use for security. Xauth allows you to add, remove, list, merge, and extract X authorization entries. X authorization entries consist of the X server hostname and display number, an authorization protocol, and secret data. X servers should have their Xauthority entries generated on server startup (xdm does this), and clients wishing to use the X server need to have these authorization entries in their local Xauthority file to gain access to the server. X authorization supports several different protocols. Only two are within the scope of this book:

MIT-MAGIC-COOKIE-1 This is the most popular protocol because it's the easiest to use and doesn't require using xdm (which we'll talk about shortly). The secret is simply a 128-bit key that can be copied from the server's Xauthority file to the client's Xauthority file using xauth. When the server challenges the client, the secret is sent in clear text.
XDM-AUTHORIZATION-1 Similar to the preceding protocol but uses Data Encryption Standard (DES) so that the secret isn't passed in clear text over the network. Here, the secret consists of a 56-bit encryption key and a 64-bit authenticator. When a client connects, the server will challenge it to provide a 192-bit data packet (consisting of date, time, and identification information) that has been encrypted with the shared secret. If the client has the correct encryption key and the server can decrypt and interpret the information, the client is granted access.

Note	In this discussion, xauth keys, xauth cookies, and Xauthority entries are synonymous.

The concept is rather simple. After starting up an X server, you'll need to generate an Xauthority entry depending on what type of protocol you're using. If you're using xdm, an entry will be generated automatically. Many systems will automatically generate an entry when you manually start an X server as well. Let's take a look at how to generate an Xauthority entry manually so we can see the actual commands that are used in the process. We'll use MIT-MAGIC-COOKIE-1 as an example.

On the X server box, start up an xterm . Type in the following commands:

 jdoe@HOST1$ xauth xauth: creating new authority file /home/jdoe/.Xauthority Using authority file /home/jdoe/.Xauthority xauth>  generate myxserver:0 .  authorization id is 41 xauth> list HOST1:0 MIT-MAGIC-COOKIE-1 121812483b0b3f19367c1541062b472b xauth>

Note

The period at the end of the generate command is where you would normally specify the authentication protocol you want xauth to use. It uses the MIT-MAGIC-COOKIE-1 protocol when you use only a period. Generating entries for other protocols usually requires extra data that needs to be provided at the end of the command. It generally can't be done by hand and is instead done by an external program or script.

You now have an authorization entry (that shouldn't be readable by anyone else on the system) for your X server. Now let's say you want to run graphical applications from HOST2 on your X server. You'll have to tell HOST2 about the key. You can do this by manually adding to your ~/.Xauthority file on HOST2 and copying and pasting the entry from above.

 jdoe@HOST2$ xauth add HOST1:0 MIT-MAGIC-COOKIE-1 \ 121812483b0b3f19367c1541062b472b

Or, you can automate the process a bit more. From myxserver, try this:

 jdoe@HOST1$ xauth extract - $DISPLAY  ssh HOST2 "xauth merge --"

The xauth extract command retrieves the key for the host named in $DISPLAY and sends it to standard output. We pipe that output through to HOST2 over SSH and feed it to the command xauth merge . This effectively transfers HOST1's xauth key to HOST2's Xauthority file. You can confirm this by running xauth list on HOST2 and examining the HOST1 entry. HOST2 can now freely send X clients to HOST1's X server because HOST1 only accepts clients with the correct xauth key.

Note

The previous command assumes that your DISPLAY variable has the fully qualified hostname or address. Keep in mind that DISPLAY variables can refer to other address families than "Inet" addresses. If your DISPLAY variable is set to :0 and you run that command, you might find that the entry in remotebox's Xauthority file refers to myxserver by a name known only to it (a name not in DNS), or worse , by a different address family (like a local Unix domain socket instead of TCP/IP). It's best to specify a complete, unambiguous address when setting the DISPLAY variable (such as 192.168.1.50:0).

Transferring Xauthority entries from server to client is similar no matter what authorization protocol you use. Some of the more advanced protocols include SUN-DES-1, which uses Sun's Secure RPC system, and MIT-KERBEROS-5, which uses secure Kerberos user authentication. These authorization methods are much more secure, but they are also much more complicated to set up initially. See the man pages on xauth, xdm, and Xsecurity for more details.