vdlinden@cs.vu.nl (Frank van der Linden) (12/10/90)
Hello everyone, I started working with X (R4) a couple of days ago, on some Sun Sparcstations. During those days, I have pretty much worked out the basic principles of the system. There is only one thing left that I don't seem to be able to get working properly : the authorization. It seems that there are basically two ways for a server to grant access for a client : - all requests from a certain list of hosts are honored, - all request using a certain key are honored. The first one is easy : just use 'xhost' to add or remove a certain host to the list. The problem with this scheme is, of course, that _everyone_ can start up a window on the servers' screen, provided that they are on a host that is on the list. The second one is the one I'm having trouble with. I tried creating a .Xauthority file with 'xauth'. The file was indeed created, but it didn't seem to work. After 'xauth add my_host:0 . 1234', a 'rsh other_host xterm -display my_host:0' still gave a message saying that the server denied permission. Restarting the server (by logging out & in again - the server is started from my .login file) didn't help. I also tried specifying the serverhost by his full host+domainname, or the internet number. This also didn't work. The other host shared my homedirectory with the one I was working on (and with all the other workstations), so the .Xauthority file was present there. After this, I tried to start the server with '-auth $HOME/.Xauthority'. It had some effect, but too much ... My own clients were also refused connection (to 'unix:0.0'). I tried adding this name to the .Xauthority file, but still no luck. The result in both cases was an endless loop in my login sequence, only stoppable by logging in on the workstation from a terminal and killing the server, which in the end left 2 workstations in a weird keyboard-status... There must be some way to get this working. It seems the only way to get a secure server running (meaning one that doesn't allow other people to log in on my workstation and then running xlock so that my screen is locked with their password...). Any help would by greatly appreciated. Thanks in advance, Frank. -- Frank van der Linden. Internet : vdlinden@fwi.uva.nl or vdlinden@cs.vu.nl ------------------------------------------------------------------------------ 'You can't have everything .... where would you put it ?' --- Steven Wright
schoch@sheba.arc.nasa.gov (Steve Schoch) (12/11/90)
In article <8458@star.cs.vu.nl>, vdlinden@cs.vu.nl (Frank van der Linden) writes: |> The second one is the one I'm having trouble with. I tried creating a |> .Xauthority file with 'xauth'. The file was indeed created, but it didn't seem |> to work. After 'xauth add my_host:0 . 1234', a 'rsh other_host xterm -display |> my_host:0' still gave a message saying that the server denied permission. There are two problems here: The authorization information (the "MAGIC COOKIE" which in your case is 0x1234) is kept by the server. The server does not generate this cookie but reads it from a file ON STARTUP. If you look closely at the xauth program you will notice that it does not connect to the server but only changes your ".Xauthority" file. |> After this, I tried to start the server with '-auth $HOME/.Xauthority'. It |> had some effect, but too much ... My own clients were also refused connection |> (to 'unix:0.0'). I tried adding this name to the .Xauthority file, but still |> no luck. The result in both cases was an endless loop in my login sequence, |> only stoppable by logging in on the workstation from a terminal and killing |> the server, which in the end left 2 workstations in a weird keyboard-status... Aside: When you kill the server you should give it a SIGTERM (kill <pid>), never a SIGKILL (kill -9 <pid>). When the server gets a SIGTERM it should clean up after itself. I'm a little unclear here about the format of the auth file. On my system, I use xdm which generates both the file used with the "-auth" argument and the ".Xauthority" file in your home directory. The .Xauthority file has the following information: DISPLAY TYPE KEY DISPLAY2 TYPE KEY etc. I'm not sure in what format is the information in the file used by the "-auth" argument. Since your server has two types of connections you want two entries in your .Xauthority file: my_host:0 MIT-MAGIC-COOKIE-1 1234 my_host/unix:0 MIT-MAGIC-COOKIE-1 1234 Then you want to start the server with "-auth $HOME/.Xauthority". Clients connection to unix:0 should now work. To bring up an X window from another host, you should do the following (assuming that DISPLAY is set to my_host:0): xauth extract - $DISPLAY | rsh other_host xauth merge - rsh other_host xterm -display $DISPLAY This will copy the information from your .Xauthority file to the other system. Xterm will look at the file and send the key over. Steve
khera@thneed.cs.duke.edu (Vick Khera) (12/11/90)
In article <8458@star.cs.vu.nl> vdlinden@cs.vu.nl (Frank van der Linden) writes:
[stuff about what he did to try using magic cookie authorization.]
There must be some way to get this working. It seems the only way
to get a secure server running (meaning one that doesn't allow
other people to log in on my workstation and then running xlock so
that my screen is locked with their password...).
Any help would by greatly appreciated.
get a later version of xlock, which won't let other people lock your
screen. it will let them blank it, but not lock it with their
password. the latest version is on expo.
here's a note i put together for our users here who are security
consciuos. it shows what needs to be done to run X using
MIT-MAGIC-COOKIE-1 authorization. there is the assumption that your
home directory is physically the same (via NFS) on all machines you
wish to run X applications. if not, you will need a way to duplicate
the magic cookie on the other machine, which is discussed in the xauth
man page. the xrsh script came with the X11R4 distribution in the
contrib section (or maybe i got it from expo.) i mainly use xrsh for
firing up xterms on remote machines.
i figured all of this out by reading the man pages, so the information
is indeed available, though not in any really useful concise form...
until now ;-)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vick Khera, Gradual Student/Systems Guy Department of Computer Science
ARPA: khera@cs.duke.edu Duke University
UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528
---cut here---
Subject: making your X server more secure
Date: Tue, 10 Jul 90 12:26:15 -0400
From: Vick Khera <khera@juliet>
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 need to do
this. the .Xauthority files can be merged using the xauth program. 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 XSun.
2. before you start the X server, be sure to create the .Xauthority file. i
wrote a shell script to do this. it is in ~khera/bin/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 .login file when i am logging into the console. 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 file by hand. you
will have to quit and restart the server.
3. since the "rcmd" command automatically does an xhost +<machine>, there is
a new command "xrsh" which does basically the same thing without adding the
host using xhost. you should replace all calls to rcmd with calls to xrsh
in your .twmrc and .xinitrc (and wherever else it may be).
4. start the X server using startx. things should be secure now. all new X
clients (from R4) understand this authorization scheme, so you should never
need to run xhost again. in fact, xhost should report *no* hosts as being
allowed in.
let me know if you have problems with this if you indeed decide to try it. i
have been using this at work for two weeks and tried it at school yesterday.
i'm only telling you two how to do this now so i can still plaster things on
other people's screens ;-). actually, if it works well for you, i'll make
it generally available.
v.
---cut here---
and here is my .xserverrc:
---cut here---
#!/bin/sh
# for Xsun:
# -ar1 NNN set keyboard repeat delay to NNN milliseconds
# -ar2 NNN set keyboard repeat rate to NNN milliseconds
exec Xsun -ar1 250 -ar2 20 -auth $HOME/.Xauthority
---cut here---
and my newcookie script:
---cut here---
#!/bin/sh
# create new .Xauthority file
PATH=/usr/local/X/bin:/usr/gnu/bin:$PATH
# try some security
auth=$HOME/.Xauthority
#cp /dev/null $auth
# generate a nice long random key
key=`perl -e 'srand; printf int(rand(100000000000000000))'`
# add to auth file. use $key$key to make sure even length.
xauth add ${HOST}/unix:0 . $key$key
xauth add ${HOST}:0 . $key$key
---cut here---
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vick Khera, Gradual Student/Systems Guy Department of Computer Science
ARPA: khera@cs.duke.edu Duke University
UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528