| < Day Day Up > |
|
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” app that could capture keyboard strokes and mouse movement. You can use two built-in methods for locking down your X server: xhost and xauth.
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):
HOST1% xhost +HOST2
If you want to deny access to HOST2 explicitly, try this:
HOST1% xhost -HOST2
Access is denied to 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 | The xhost - commands deny only future access; they do not terminate current connections. |
Xhost was not initially designed with a premium emphasis on security, specifically in regard to the client-to-server and server-to-client communication schema. This is most notable in the lack of encryption in addition to the fact that it does not require token-based authentication. It’s the same reason that IP-based access control on firewalls isn’t a good solution for a Virtual Private Network (VPN); you are relying solely on hostnames or IP addresses to trust identity. As we have seen and will see in other 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.
Tip | 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 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 easiest to use. 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@myxserver$ 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 myxserver: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 “remotebox” on your X server. You’ll have to tell remotebox about the key. You can do this by manually adding to your ~/.Xauthority file on remotebox and copying and pasting the entry from above.
jdoe@remotebox$ xauth add myxserver:0 MIT-MAGIC-COOKIE-1 \ 121812483b0b3f19367c1541062b472b
Or, you can automate the process a bit more. From myxserver, try this:
jdoe@myxserver$ xauth extract - $DISPLAY | rsh remotebox "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 remotebox using rsh and feed it to the command xauth merge. This effectively transfers myxserver’s xauth key to remotebox’s Xauthority file. You can confirm this by running xauth list on remotebox. Remotebox can now use myxserver’s X server freely because it knows myxserver’s xauth key. Only hosts that know the xauth key can use the X server.
Tip | The previous command assumes that your DISPLAY variable has the fully qualified hostname or address. Keep in mind that DISPLAY variables can refer to address families other 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 (such as 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.
| < Day Day Up > |
|