Thanks in advance for your help.
-- Raja
sa...@cig.mot.com
And a related question... whenever I try to specify anything other than
'+' on the xhost line, it comes back with an X error message. (Sorry, I
should have made better note, but it's something like 'invalid
parameter'.)
Where should I look for something wrong? (BTW, this is Linux 1.1.61,
XFree 3.1.)
--
Ed Haymore | Duct tape is like the Force. It has a light side
e...@byu.edu | and a dark side, and it holds the universe together.
RS> Can someone tell me how xauth is used and example of
RS> Xauthority file. I am trying to avoid using xhost +
RS> command to display X applications executed on my
Here's my stock tutorial on using Xauthority. If your machines don't
share the same home directory, you will need to make sure that the
xauth entries (or the entire file, if you only have one X session
running) are copied from the display host to the remote application host.
Author: Vivek Khera <kh...@cs.duke.edu> -*- text -*-
Subject: making your X server more secure
Originally Written: Tue, 10 Jul 90 12:26:15 -0400
Time-stamp: "05 Aug 94, 16:15:58"
Here's how I have made my X sessions more secure than just the xhost
way. It is mostly transparent, and doesn't allow arbitrary users to
plaster windows on my screen, or to snoop at my keyboard. Even people
who log into the machine I'm working on can't connect to the server.
This whole scheme is based on the MIT-MAGIC-COOKIE scheme, where each
client must present to the server a magic cookie to prove that it is
allowed to connect. The cookie is kept in a file in your home
directory (.Xauthority) which only you are allowed to read. The
server reads this file when it starts up, so if you change the cookie
file, you will have to restart the server to make it read the new
information. Normally you don't want to do this. The .Xauthority
files can be merged using the xauth program, so if you need access to
another server which is Xauth-secured, just add its cookies to your
.Xauthority file. See the man page for some more details.
Here is how to make yourself "secure":
1. Create a .xserverrc file similar to mine in your home directory.
The important part is to pass the "-auth $HOME/.Xauthority" option to
the X server on the last line. Here is what my .xserverrc file looks
like:
--cut here--
#!/bin/sh
# generate a new magic cookie at this time.
newcookie -md5
exec X -auth ${HOME}/.Xauthority
--cut here--
2. Before you start the X server, be sure to create the .Xauthority
file. I wrote a shell script to do this, called newcookie. You must
create a new .Xauthority file when you switch machines, as the name of
the machine the server is on is part of the authority mechanism. This
is how it knows which cookie to send to which server it is connecting
to. I run newcookie from my .xserverrc file when I start X. If you
run newcookie after you start the X server, you are hosed unless you
can remember the random number it generated and recreate the
.Xauthority file by hand; otherwise you will have to quit and restart
the server.
Here is my newcookie program. If you have a program that generates
md5 signatures, you can use it to generate a strong random number by
passing the -md5 flag. If you have md4, just edit the script to use
it instead of md5. If you don't have md4 or md5, then it assumes you
have perl to generate random numbers. If you don't have perl, then
write your own program to generate a long random number with an even
number of hexadecimal digits in it, and then run "xauth add" like in
my program. Note that md4 and md5 generate values that are an even
number of digits long already. An implementation of md5 can be found
in Internet RFC 1321. Note that the options I pass to pstat for
generating a large random string may not work on your system. Check
it by hand to make sure it generates lots of data.
--cut here--
#!/bin/sh
# create new .Xauthority file
# try some security
auth=$HOME/.Xauthority
#cp /dev/null $auth
# generate a nice long random key
if [ "$1" = "-md5" ]; then
# use a random noise source and get a strong checksum of it.
# this is probably a stronger random number than the other method.
key=`pstat -fv | md5`
else
# quick and dirty. can probably be recreated if time can be guessed.
key=`perl -e 'srand; printf int(rand(100000000000000000))'`
# use $key$key to make sure even length.
key=$key$key
fi
# add to auth file.
xauth add ${HOST}/unix:0 . $key
xauth add ${HOST}:0 . $key
--cut here--
3. Make sure any program you run does not do an xhost +<machine>
command. This will destroy any security you might gain by using
xauth. Notably, the rcmd script does this.
4. Start the X server using startx. Things should be secure now. All
new X clients (from R4 and later) understand this authorization
scheme, so you should never need to run xhost again. (Unless you are
using the standard Ultrix libraries -- but then you get what you
deserve.) In fact, xhost should report *no* hosts as being allowed
in like this:
[thneed]% xhost
access control enabled, only authorized clients can connect
[thneed]%
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh...@kciLink.com Rockville, MD +1-301-309-0969
PGP/RIPEM/MIME spoken here http://www.kciLink.com/home/khera/
Actually, please post. I've been trying to figure out
the same thing.
Thanks!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Daniel Benbenisty Systems Administration
d...@hsc.hac.com Hughes Space & Com.
The use of xauth is not so difficult as it seems on the first glance.
The system relys on a private user-specific key that the X server reads upon
startup ( "-auth" -Option).
Now each time a x-client is started the client looks for a .Xauthority
file in the users home directory. From this file it takes the key which is
compared to the one read by the server. Only when the keys match access is
allowed to the client.
The file .Xauthority is created with the xclient xauth. Of course this file
must be !very! private to you. No one else must have access to this file !
Using xauth you can
create new keys, list old etc. The listing of this file might look like:
bliss:0 MIT-MAGIC-COOKIE-1 81352fc745f44250940b82e8d7820a00
bliss/unix:0 MIT-MAGIC-COOKIE-1 81352fc745f44250940b82e8d7820a00
where bliss is the name of the display (actually the name of a workstation)
MIT-M... is the name of the authority protocol (SUN-DES-1, MIT-KERBEROS ... are
other protocols) and the rest is the key itself.
The key may consist of any hex string that is of even length.
I use a script that creates random keys upon startup of X11. So each time X is
started (we dont use xdm) a new .Xauthority file is created. The advandtage is
that the user doesn't have to create a file on his own, he does't even have to
know about the existance of this mechanism.
Hope it helped
Rainer
The solutions posted so far assume you are not running xdm; it makes life much
simpler if you do run xdm, because xdm deals with all the tiresome business of
generating magic cookies.
The advice we give our users on X security in an xdm environment can be
obtained by anonymous ftp from ftp.ulcc.ac.uk:X_security (text version) or
X_security.ps.Z (compressed postscript).
Regards,
Bob
-------------------------------------------------------------------------------
+ Bob Vickers, University of London Computer Centre
+ E-mail: R.Vi...@ulcc.ac.uk
+ Phone: +44 171-405 8400 ext 386 (in UK: 0171-405 8400 ext 386)
+ WWW: http://www.ulcc.ac.uk/staff/Bob+Vickers
Apologies for the wasted bandwidth.