The server will not accept connections from just anywhere. You don't want everyone to be able to display windows on your screen. Or read what you type -- remember that your keyboard is part of your display!
Too few people seem to realise that allowing access to your display poses a security risk. Someone with access to your display can read and write your screens, read your keystrokes, and read your mouse actions.
Most servers know two ways of authenticating connections to it: the host list mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, the secure shell, that can forward X connections.
Xhost allows access based on hostnames. The server maintains a list of hosts which are allowed to connect to it. It can also disable host checking entirely. Beware: this means no checks are done, so every host may connect!
You can control the server's host list with the xhost program. To use this mechanism in the previous example, do:
light$ xhost +dark.matt.er
This allows all connections from host dark.matt.er. As soon as
your X client has made its connection and displays a window, for safety,
revoke permissions for more connections with:
light$ xhost -dark.matt.er
You can disable host checking with:
light$ xhost +
This disables host access checking and thus allows everyone to connect. You should never do this on a network on which you don't trust all users (such as Internet). You can re-enable host checking with:
light$ xhost -
xhost - by itself does not remove all hosts from the access list (that would be quite useless - you wouldn't be able to connect from anywhere, not even your local host).
Xhost is a very insecure mechanism. It does not distinguish between different users on the remote host. Also, hostnames (addresses actually) can be spoofed. This is bad if you're on an untrusted network (for instance already with dialup PPP access to Internet).
Xauth allows access to anyone who knows the right secret. Such a secret is called an authorization record, or a magic cookie. This authorization scheme is formally called MIT-MAGIC-COOKIE-1.
The cookies for different displays are stored together in
~/.Xauthority. Your ~/.Xauthority must be inaccessible
for group/other users. The xauth program manages these cookies, hence
the nickname xauth for the scheme.
On starting a session, the server reads a cookie from the file that
is indicated by the -auth argument. After that, the server only
allows connections from clients that know the same cookie. When the
cookie in ~/.Xauthority changes, the server will not pick
up the change.
Newer servers can generate cookies on the fly for clients that ask for
it. Cookies are still kept inside the server though; they don't end up
in ~/.Xauthority unless a client puts them there. According to
David Wiggins:
A further wrinkle was added in X11R6.3 that you may be interested in. Via the new SECURITY extension, the X server itself can generate and return new cookies on the fly. Furthermore, the cookies can be designated ``untrusted'' so that applications making connections with such cookies will be restricted in their operation. For example, they won't be able to steal keyboard/mouse input, or window contents, from other trusted clients. There is a new ``generate'' subcommand to xauth to make this facility at least possible to use, if not easy.
Xauth has a clear security advantage over xhost. You can limit access to specific users on specific computers. It does not suffer from spoofed addresses as xhost does. And if you want to, you can still use xhost next to it to allow connections.
If you want to use xauth, you must start the X server with the -auth
authfile argument. If you use the startx script, that's the right place
to do it. Create the authorization record as below in your startx script.
Excerpt from /usr/X11R6/bin/startx:
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Mcookie is a tiny program in the util-linux package,
primary site
ftp://ftp.math.uio.no/pub/linux/. Alternatively, you
can use md5sum to massage some random data (from, for instance,
/dev/urandom or ps -axl) into cookie format:
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
If you can't edit the startx script (because you aren't root), get
your system administrator to set up startx properly, or let him set up
xdm instead. If he can't or won't, you can make a ~/.xserverrc
script. If you have this script, it is run by xinit instead of the real
X server. Then you can start the real X server from this script with the
proper arguments. To do so, have your ~/.xserverrc use the magic
cookie line above to create a cookie and then exec the real X server:
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
If you use xdm to manage your X sessions, you can use
xauth easily. Define the DisplayManager.authDir resource in
/etc/X11/xdm/xdm-config. Xdm will pass the -auth argument
to the X server when it starts. When you then log in under xdm, xdm
puts the cookie in your ~/.Xauthority for you. See xdm(1)
for more information. For instance, my /etc/X11/xdm/xdm-config
has the following line in it:
DisplayManager.authDir: /var/lib/xdm
Now that you have started your X session on the server host
light.uni.verse and have your cookie in ~/.Xauthority, you
will have to transfer the cookie to the client host, dark.matt.er.
The easiest is when your home directories on light and dark are
shared. The ~/.Xauthority files are the same, so the cookie
is transported instantaneously. However, there's a catch: when you put
a cookie for :0 in ~/.Xauthority, dark will think it's a
cookie for itself instead of for light. You must use an explicit host
name when you create the cookie; you can't leave it out. You can install
the same cookie for both :0 and light:0 with:
#!/bin/sh
cookie=`mcookie`
xauth add :0 . $cookie
xauth add "$HOST:0" . $cookie
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
If the home directories aren't shared, you can transport the cookie by means of rsh, the remote shell:
light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -
~/.Xauthority
(xauth nlist :0).
| rsh dark.matt.er).
~/.Xauthority there (xauth nmerge -).
Notice the use of ${HOST}. You need to transport the cookie that is
explicitly associated with the local host. A remote X application would
interpret a display value of :0 as referring to the remote machine,
which is not what you want!
It's possible that rsh doesn't work for you. Besides that, rsh also has a security drawback (spoofed host names again, if I remember correctly). If you can't or don't want to use rsh, you can also transfer the cookie manually, like:
light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Password:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
dark% xfig &
[15332]
dark% logout
light$
See also rsh(1) and xauth(1x) for more information.
It may be possible to piggyback the cookie on the TERM or
DISPLAY variable when you do a telnet to the remote host. This would
go the same way as piggybacking the DISPLAY variable on the TERM
variable. See section 5: Telling the Client. You're on own here from
my point of view, but I'm interested if anyone can confirm or deny this.
An X application on dark.matt.er, such as xfig above, will automatically
look in ~/.Xauthority there for the cookie to authenticate
itself with.
There's a little wrinkle when using localhost:D. X client
applications may translate localhost:D into host/unix:D for
the purpose of cookie retrieval. Effectively, this means that a cookie
for localhost:D in your ~/.Xauthority has no effect.
Authority records are transmitted with no encryption. If you're even worried someone might snoop on your connections, use ssh, the secure shell. It will do X forwarding over encrypted connections. And besides, it's great in other ways too. It's a good structural improvement to your system. Just visit http://www.cs.hut.fi/ssh/, the ssh home page.
Who knows anything else on authentication schemes or encrypting X connections? Maybe kerberos?