X security and using xhost + and xhost +localhost to allow kppp to be run by a user


Subject: X security and using xhost + and xhost +localhost to allow kppp to be run by a user
From: Josh Smith (irilyth@infersys.com)
Date: Sun May 07 2000 - 09:08:01 MDT


p> Can anyone give a good detailed explanation or overview of the X security
p> issues here?

I'm sure there are some good detailed explanations on the net, or in
O'Reilly books. I've learned what I know slowly over the years, so I don't
have a good reference for a comprehensive guide. Here's a quick summary,
though...

There are at least two ways to do X security: MIT-MAGIC-COOKIE and xhost. In
the first, which is more secure, the X server starts up with a "cookie" in
its memory, and writes a copy of the cookie to your .Xauthority file. When
you launch an X app, it reads the cookie from your .Xauthority file, and
uses that to authenticate itself to the X server. If the cookie presented by
the X app matches the cookie in the X server, the server lets the app access
your display.

The xhost method uses hostnames to control security, and turns off the
cookie method entirely. If you do 'xhost +myhost.mydomain.sub', then the X
server will only give access to applications that are connecting from that
hostname. If you do 'xhost +', it will give access to *any* application from
*any* host -- that's why it's so dangerous.

If no one but you can log in to your system, then 'xhost +localhost' isn't
too awful, but it's still more dangerous than the cookie method. The best
way to let another user access your X display is to give them access to your
cookie. In the case of root, this is pretty simple, since root can actually
read your .Xauthority file directly. The $XAUTHORITY environment variable
controls where at least some apps look for a .Xauthority file, so if you log
in as root, and do

  export XAUTHORITY=/home/yourname/.Xauthority

(replacing everything to the right of the equals with the path to the
.Xauthority file in your home directory), that should let you run at least
some apps. If that doesn't work, you can try

  export HOME=/home/yourname

to set $HOME for root to your home directory, though that may have other
side effects. (I do it all the time, and it seems ok, but be careful). Or,
you can do

  cp /home/yourname/.Xauthority ~/.Xauthority

to copy your current .Xauthority file into root's normal home directory.

A more sophisticated way is to use xauth, which allows you to extract and
copy cookies around. You can use this if, for example, you want to run an X
application on some other system, displaying on your X server, and you don't
want to do 'xhost +thatotherhost' (perhaps that other host is a system used
by many other people). As yourself on your machine, do

  xauth list

to find out exactly what the display name of your key is. If there are
multiple keys in the list, it's probably the one corresponding to your
hostname followed by ":0". Then extract that key into a file with

  xauth extract tmp.xauth displayname

where "display name" is the name of the display that you found with the
'xauth list' command. That extracts the key from your .Xauthority file into
a file called "tmp.xauth" (you can call it whatever you want). Next, you
need to run this command to merge the key into your other account's
.Xauthority file (whether root on your own system or another user on your
system or your account on another system):

  xauth merge tmp.xauth

If you're on another system, you'll need to copy the tmp.xauth file to the
other system, of course.

One final note: If you want to run an X app on another system and display it
back on your system, the best way is to do it with SSH, which includes the
capability to forward X11 connections securely through the SSH connection.
And it's a snap: Once you've fired up X on your system, just ssh to the
remote system, and voila! It should automatically set up X11 forwarding,
unless your SSH client or the SSH server is configured not to allow this
(possible, but unlikely), or unless you see a warning about host keys
changing or other problems. On the remotehost, do 'echo $DISPLAY' to see
what's going on: It should say something like "remotehost:10.0", where
"remotehost" is the name of the system you've logged in *to*. This is a
pseudo-display that your SSH client is listening to, so when an X app tries
to display to it, the SSH client catches it, sends the connection back down
the encrypted SSH connection, and then hands it off to your local X server.
The encrypting and decrypting process may add a little overhead, but the
whole connection is secure from snoopers and other evildoers.

There's more info about all this stuff out there on the net, but hopefully
this will help folks get started. Good luck!

                                      -Josh (irilyth@infersys.com)



This archive was generated by hypermail 2a24 : Sun May 07 2000 - 09:07:48 MDT