[svlug] Remote X display

[Jonathan Sergent]

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
for you.

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
like this:

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).


--jss.

--
echo "unsubscribe svlug" | mail majordomo at svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe