------------------------------------------------------------------------------ Index X Security Methods What a user with access to your display can do! Passing $DISPLAY and Xauthorization to a remote hosts Tutorial on setting up Xauthority when using "startx" ------------------------------------------------------------------------------ X Security methods The X Window System has a security system to prevent any tom, dick, and harry from using your current display. You obviously know that you have to either add a "-display host:0" or set the "DISPLAY" environment variable to open a window on a screen. What you also need is permission to open the window. X11R4 provided the means for host and passwd authorization. NOTE: that allowing access to your display by others is DANGEROUS See the report at the end of this document. METHOD 1: Authority by host. (Old method - See the xhost man page) xhost This command turns the X authority system on/off for Xserver program. It will also allow users to disable/enable authorization checking from a particular machine. IE: a user can allow anyone on a particular host (often a private workstation) to use his/her display without authorization. By default this command has full authorization enabled, no host in its `authorized' host list Example: prompt>> xhost access control enabled, only authorized clients can connect dragon cornet This means that any program running on either of the machine dragon or cornet can place windows on your screen without any trouble. If the program was not run on either of these machines, the user must have a `authorization password' (See method 2). Remove a machine xhost -cornet and to add a machine xhost +cornet and to allow use of your display from any machine (in the world) xhost + to return to normal xhost - Note, because of the unusual syntax of xhost you can't use a "-display host:0" option with it, instead use the env command to set the "DISPLAY" environment variable for just that command. env DISPLAY=host:0 xhost This method is not recommended except as a temporary arrangement (See the Warning below). Note that many Tcl/Tk scripts will close xhost security by default as a precaution against remote attacks on Tcl/Tk clients. METHOD 2: Authority by MagicCookie (See the xauth man page) This is known as X authority and is currently the accepted method of protecting your display from unwanted access. When you start a session on a display the `xdm' program (the one that displays the initial login window) creates a file in your home directory called ".Xauthority". This file holds a password, key, magic-cookie or X authorization to allow you to access your display regardless of your xhost permission. Xauthorization can also be enables which you start a X session using the "startx" program. This involves setting up a .xserverrc file with the appropriate "-auth {key}" X server option. A tutorial on this is given below. xauth This command allows uses to list/add/remove/copy X authorization passwords from a given (default the users) ".Xauthority" file. This is a binary file and this command is the only real way of reading this file. Also the command ensures that all authority files is only read/writable by the owner of the file, thus insuring file security. Only root can read/write any authority file. To list this file type (assuming you are on dragon) prompt>> xauth list dragon.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 e102ba90f0f55f2108a9ee2526537845 prompt>> # machine auth-type authorization (cookie) Note: sometimes authorities from old sessions are also present. This is of no importance as every session has a new authority password generated on every login. If you do not have xhost permission (method 1) you MUST have the current authority to the display you wish to access. For example a friend decided to give me access to his display on thorax. He did not however wanted to use xhost as he only wanted to give me permission -- not just anyone on machine I am working on. So he mailed (or other means) his current authority. thorax.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 3704a0c7fd52c90eabf53892c0ba7ee1 So I then add this to my ".Xauthority" file prompt>> xauth add thorax.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 3704a0c..etc Now I have access to his display regardless of his xhost setup and can do anything on his display that he can do, until he (or I) kills the current X session. However unless I am in the same room it is difficult for me to actually see what I am doing without some sort of `spy' program, and I definatly do not have control over the mouse (physical, the cursor I could control) or the keyboard. WARNING: If someone has permission to access your display (via either xhost or xauth) they can not only open windows, but can also look at your display, or kill various windows, and terminate your current session! See Below for good reasons why you shouldn't allow this. The most common reason for allowing such access seems to be for X window games. METHOD 3: Authority by SUNDES In Suns SUNDES is another authorization based on your UserId and Domain. No matter where you are on your network and your user id is the same everywhere you automatically have authorization. Problems: However, a program that runs set-uid root uses root's key on the local machine rather your key, rendering SUN-DES-1 authorization only useful for useless clients like xclock, xman, ... . You can't run suid'd xterms. The fix: install xterm as set-gid tty, not set-uid root, and make sure /etc/utmp is group-writable by group tty. Then, an xterm runs with your user ID, so it uses your key for SUN-DES-1, and you've got the protection you were after. --- kelly@nmt.edu (kelly) Apparently, the X Consortium didn't test this before X11R5 was released. It needs to be fixed and I do not know if it is fixed in X11R6. --- anthony@cit.gu.edu.au Maybe the way this should work is to use the SUN-DES-1 key for the real uid, not the key for the effective uid. This is really a SUN-DES-1/suid problem, not an install problem. --- Bob.Myers@st.unocal.com ------------------------------------------------------------------------------ What a user with access to your display can do! Examples... * Kill the users session -- just close all the displays windows! The program "xclosedown" does this easily, though "xkill" can be used as well. * Delete or Destroy any window on your terminal. * Look at what is currently on the display (nothing special is needed) xwd -root -display OtherDisplay:0 | xwud -geometry +0+0 & It works however the xwd beeps the terminal you are looking at. Do it too often and the game is given away. With the source to xwd you can easily turn off the beeps, or write a program show a port-hole into the other users display (I did it as an exercise!). * Look at all the users key strokes (key logging) -- including passwords. A program on the network "xkey" can allow you to do this. This program is also incorporated into "xscreensaver" and "xautolock" clients to monitor user activity. Now it is stragight forward as xinput list # not the ID of a "keyboard" xinput test 10 # see every the keycode for press and release on Id 10 * Run any client program on your display, including some very obnoxious clients, such as "xroach" (display cockroaches that run and hide under windows), or "xcrabs" (which slowly eat at the edges of windows). * Lock the users display with the "xlock" program so he needs your login passwd to unlock it. * Draw or modify users client programs. For example put a 'naughty' background on the display or in some of the users windows (like his X terminal). * Generate random X events remotely. EG: make your mouse cursor seem 'possessed', or with extra interia or gravity effects. The point is -- If you have authority, you can do just about anything you want to do to that users display. Look at keys, the display, open/close windows, close sessions, probably even enter commands on an open xterm window! You are definitely asking for trouble if you open your display with "xhost +" which allows anyone IN THE WORLD to access your display. Anthony Thyssen -- local Xpert at Griffith University. ------------------------------------------------------------------------------ Automatically pass X Authorization & Display from one machine to another. All the methods I have seen to do this fall into one of the following general techniques. And all have some fault or another. Index 1/ Pipe line rsh/rexec/on -- Security may not allow remote cmd exec. 2/ As part of TERM environment -- visible with a "ps eww" for a moment 3/ NFS shared file -- Your system may not be set up that way 4/ Finger for it -- You need to encrypt the information 5/ Your own daemon -- what a lot of trouble 6/ Secure Shell (Ssh) -- Fully encrypted X Display channels thus automatic setup of X windows ----- 1/ Use a rsh/rexec/rstart/on... pipeline (See xauth online manual) Set up the your .rhosts file in the home directory on the remote machine so that a password in not required to remotely execute commands. xauth extract - $DISPLAY | rsh other xauth merge - Basically this method passes the authorization (and maybe other info) via a stdout/stdin command pipeline, which is completely invisible to everyone, except network monitors. Included in this method is the use of 'xrlogin' and 'xrsh' to do this job for you. These programs usually (the newer ones that is) allow you to pass a specified list of ENVIRONMENT variables which includes the `DISPLAY' and/or a copy of the authorization code as required. The new X11 R6 program 'rstart' is a simplified version of this method using rsh to run a special receiving program 'rstartd' at the remote end. It is simple and effective. The `on' program available (if enabled) on sun machines will also pass environment variables, as well as the current directory. You will however be required to store the Authority in such a variable for passing. Unless you are also have shared home directories. WARNING: Environment variables and command line arguments are visible in 'ps' listing with the appropriate flags. As such passing authorization information in environment variables or as arguments is not recommended. The recommended method as given in the manual (shown above) is safe from the view of other users. 2/ Wrap it as part of the TERM environment variable. This method uses the fact that most remote command executors do pass the TERM environment variable to the remote host. It is then a matter of an appropriate script in your remote .login file to extract the information from the TERM environment variable and set up things appropriately. This is not easy and is very prone to things `going wrong'. Regardless it does work, and in some cases may prove the best technique. A version of the xrlogin script is available on the network which does this. Basically you change the TERM environment variable before the actual call to rlogin is performed, to include your DISPLAY and your authorization. On the remote machine you then extract this information and return the TERM environment variable to normal BEFORE you use it for reseting or stty'ing your terminal. ---8<--- script for launching rlogin: #!/bin/sh # ~/bin/rl --- Rlogin with display: if [ -n "$DISPLAY" ]; then case "$DISPLAY" in :*) DISPLAY=`hostname`$DISPLAY ;; esac TERM="$TERM&$DISPLAY&`xauth nextract - $DISPLAY`" export TERM fi rlogin $* ---8<--- add to your .cshrc or .login if ( $?TERM ) then if ( `echo $TERM | tr -cd '&'` != " ) then echo "$TERM" | cut '-d&' -f3 | xauth nmerge - setenv DISPLAY `echo "$TERM" | cut '-d&' -f2` setenv TERM `echo "$TERM" | cut '-d&' -f1` endif endif ---8<--- xterm command to use xterm -T hostname -e ~/bin/rl hostname ---8<--- WARNING: Environment variables and command line arguments are visible in "ps" listing with the appropriate flags. As such passing authorization information in environment variables or as arguments is not recommended. Even though in a correct working situation the 'window of opportunity' is very small, a hacker knowing the exact method is being use may write a monitor to look for these special TERM environment variables, then do the nasty on you. Also on some systems the 'rlogin' or 'telnet' daemon process which is the parent of the users login shell may retain a copy of the `uncorrected' TERM variable, even though the daemon process does not need it. A Public Key encryption technique however could close that window of opportunity, but with further complication. The recommended method as given in the manual is a xauth pipeline, (shown above) and safe from the view of other users. 3/ NFS. Write it to a file on a shared NFS partition you have access to. Note that if the home directories are NFS mounted, then authorization is automatically passed, However you will still have to pass your DISPLAY environment variable via a file or other means. IE: login host: echo $DISPLAY > ~/.X11host remote host: setenv DISPLAY `cat ~/.X11host` This should be completely safe with the appropriate file permissions but requires the system to be setup with NFS mounts. And that is usually beyond the users control. 4/ Finger for the info in a .plan file This involves encrypting the information into your `.plan' or `.project' (the latter being easier to extract) and having the remote machine finger for the information. Decrypting it into the appropriate locations. (Mail me any code you may develop for this). With the availability of PGP and other public key encryption methods, the remote machine can also ensure that the sending machine is the expected host and not a 'spoof' of a hacker trying to get access. Encryption however is a MUST for security in this situation as the information is available to anyone fingering the user. A further improvement is to use the 'who fingered me' technique to only give the information only to your own remote accounts and not just to anyone who is asking. This method was developed by a second year IT student, but without any form of encryption (which was how I discovered it). After I explained to him his folly, he gave up this method. But with encryption, it is a valid method. 5/ Write your own Daemon Basically roll-your own... This is not easy for a beginner and requires a lot of thought to security as well and knowledge on how to go about doing this. You may be probably better of using the Encrypted Finger method than this, and less prone to bring the wrath of the System Managers down on you. 6/ Ssh (Secure Shell) *** RECOMMENDED *** The best remote machine security I have seen is to use a program such as Ssh (Secure Shell), which for the reasons I give here is becoming more and more popular. This program is a rsh replacement which uses host identification to ensure that the destination is the actual machine you want (to prevent host spoofing, or middle-man attacks) and will create encrypted network connections for both normal Rsh connections as well as the X server connections. Due to the latter it will also transfer and setup the DISPLAY and any authorization required for your Display connection (using a -X option). Once done, even the programs graphical X window commands are encrypted across the network preventing spying by any network monitor. This makes this method THE most secure X windows remote connections and will handle the X window requirements. Further compression can be arranged to allow it to be used even across slow modem connections. --- Anthony Thyssen ------------------------------------------------------------------------------ Tutorial on setting up Xauthority when using "startx" EG: Manual startup of the X Windows Display. 1. create a .xserverrc file similar to that below in your home directory. The important part is to pass the "-auth $HOME/.Xauthority" option to XSun. --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. --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 # On Linux Machines #key=`dd if=/dev/urandom count=1 | md5sum` # or #key=`ps -axl|md5sum` # generate a nice long random key ( x2 ensures string is even in length) #key=`perl -e 'srand; printf int(rand(100000000000000000))x2'` # alternative by Anthony Thyssen, This is more likely to work key=`perl -e 'srand; foreach(1..32){printf("%02x",rand(16))}'` # 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 + 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. In fact, xhost should report *no* hosts as being allowed in like this: :::prompt:::> xhost access control enabled, only authorized clients can connect :::prompt:::> --- Vivek Khera ------------------------------------------------------------------------------ What are these Authorization types. XDM-AUTHENTICATION-1 An authentication protocol used by XDMCP that allows the display and the host to prove their identities based on a shared, secret key (stored in NVRAM). It uses encryption to make sure that people can't determine the key by snooping the network. XDM-AUTHORIZATION-1 An authorization protocol used by X applications to send a shared secret (based on the secret key mentioned above) to the X server. It uses encryption to make sure that people can't determine the key by snooping the network. The X server "authorizes" connections from clients that can provide the correct secret key. MIT-MAGIC-COOKIE-1 An authorization protocol used by X applications to send a shared, but not very secure, secret to the X server. This is not encrypted and therefore is not very useful in hostile environments like universities. It is however the most common. SUN-DES-1 An authorization protocol used by X applications to securely send credentials based on one's login identity to the X server. The X server uses this information to authorize connections from *users* that it knows about (via xhost). ?-KERBEROS-1 The eventual authorization protocol that will be based on Kerberos. Nobody is working on this yet. NCD Terminals are known to understand the first 3 of these. Most other X server implementations are the same in this respect. You can of course avoid much of the problem by using the SSH encrypted X window Communications. MIT-MAGIC-COOKIE-1 is then only used locally and is different on each end. The X communications is encrypted across a secondary SSH pipeline. ------------------------------------------------------------------------------