[svlug] Remote X display
sergent at kgb.etla.net
Thu Sep 3 01:56:23 PDT 1998
In message <19980902091034.A306 at requiem.geecs.org>, Seth David Schoen writes:
] Mark Willey writes:
] > Does anyone have some good advice on how to secure X Windows in general? I
] > know my X is not secure as I allow my own host with xhost. But what is a
] > better way? I have never seen what looks like a good solution to this.
] > Xauth? Anybody bored and want to give a hand-holding account of how to
] > set it up?
] If you only use SSH, then almost any imaginable X security concern would be
] dealt with.
] You should perhaps use "Secure Console" whenever you type a password into
] an xterm or xterm clone.
Err, no. If you log in on the console and start X with the default
"startx" script, the server will start up without xauth authentication
and will only use xhost "authentication". The problem here is that I
can log into Mark's machine and start up X clients on his display.
People have great fun with xhost in workstation labs. HP-UX 9
"vuelogin" doesn't start up "with xauth" like newer xdm's do so people
enjoyed doing things like "xclock -geo 1280x1024" or "xset s off" or
many other things to other people's machines in the MSEE aquarium
at Purdue. But there are much worse things you can do like spying on
people's keystrokes and even replacing them with the keystrokes you
want them to type (there's a program that does this by dynamically
remapping the keyboard to all emit the same thing and changing that
every keystroke to the next desired letter).
The easiest way around this is to use xdm to log in since it does this
But you should also be able to do some trickery with your xinit scripts
to create an MIT-MAGIC-COOKIE-1 cookie and store it in your
$HOME/.Xauthority file and let the X server know it should use it to
regulate connection attempts. In case you didn't know, the way this
works is that your server reads (you must tell it where to read it
from) the cookie (just a chunk of bits) from somewhere on startup.
This same cookie has to be written (the server doesn't do it, you do
it beforehand) to $HOME/.Xauthority. When you start up an X client
(i.e. xterm) it reads the cookie from the file and sends it to the
server. Therefore the client is (essentially) authorized to connect
if it can read the Xauthority file, which is mode 0600...
Note that then to allow remote machines to connect you must either
(a) share your home directory with them via NFS (in which case it's
transparent except for setting $DISPLAY)
(b) copy your cookie to the remote machine.
To do (b), either use ssh (which for all intents and purposes does
this for you--it actually puts a different one there and tunnels
the connection and encrypts and/or compresses it), or do something
xauth extract - $DISPLAY | rsh otherhost xauth merge -
You lose some security when your .Xauthority is NFS mounted if people
can sniff on your network. Local xauth files everywhere and ssh is
hard to beat.
It's easier to just use xdm to log in and ssh for remote access I
think and not worry about this. (RAM is cheap.)
I think most of the above can be gleaned eventually from the
manual pages for Xsecurity(1), X(1), Xserver(1), and xauth(1).
echo "unsubscribe svlug" | mail majordomo at svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe
More information about the svlug