Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!rutgers!mcnc!duke!khera From: khera@thneed.cs.duke.edu (Vick Khera) Newsgroups: comp.windows.x Subject: Re: Authorization questions Message-ID: Date: 10 Dec 90 20:39:38 GMT References: <8458@star.cs.vu.nl> Sender: news@duke.cs.duke.edu Organization: Duke University CS Dept., Durham, NC Lines: 122 Nntp-Posting-Host: thneed.cs.duke.edu In-reply-to: vdlinden@cs.vu.nl's message of 10 Dec 90 11:47:36 GMT 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 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 +, 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