X Security

Last updated -[Sun Oct 9 10:17:59 2005 by cxh]-

Places to go

  • X11
  • /usr/sww/doc/faq/X11/X11.faq
  • Colormaps
  • CDE
  • XDM

  • Contents

  • Overview
  • Using Authority Files
  • xauth
  • More information about xauth
  • Sysadmin notes about setting up xdm
  • Framemaker and xauth
  • exmh and xhost
  • [This tutorial is a draft. More work needs to be done concerning xauth. Some of the text from this file came from /usr/sww/doc/security/X11/x-server-security ]


    It is possible for someone else to run a program called 'xkeys' that will echo what keys you type to your X display. This means that a cracker could view any passwords that you typed.

    This file discusses workarounds to fill this security hole.

    The simplest form of security is the 'xhost' program. This program allows a user to control what hosts are allowed to make connections to the X server. A cracker can only successfully run xkeys from a host that is permitted to make a connection to your Xserver. Workstations running X11 and NCD Xterminals all support xhost.

    The next form of security is to use display authorization information stored in a file. Under this scheme a user has a ~/.Xauthority file and it is only readable by the user. The 'xauth' program is used to modify the authorization file. For a client to connect to your Xserver, it must be able to read the authorization file. If a client is on a remote system, then the remote authorization file must match the local file.

    There are three authorization file levels of security

    3. SUN-DES-1
    MIT-MAGIC-COOKIE-1 is the least secure. It should only be used on a network where 'network snooping' would be difficult. The magic cookie is a long hexidecimal string. The string is sent as plain text between the client and the server.

    MIT-MAGIC-COOKIE-1 is the only form of authorization file security that will work for the current NCD Xterminal server. The NCD Xserver due out in March may support XDM-AUTHORIZATION-1.

    XDM-AUTHORIZATION-1 is more secure. It can be used where the it may be possible to snoop the net. The magic cookie is send as a DES encripted string. This method only works if you are running xdm, it will not work from xinit. Some of the NCD Xterminals are set up to run XDM-AUTHORIZATION-1.

    SUN-DES-1 may be the most secure. It will only work on Suns running NIS and secure RPC. To use SUN-DES-1, you have to have secure RPC installed. [I was unable to test this method].

    See the manpages for Xsecurity, xhost, xauth, Xserver and xdm for more information. The O'Reilly book 'X11 Administration' is very good.

    Using Authority Files

    To turn on authorization file checking in an Xserver, the server is started with the -auth option. A typical xinit line would be:
    xinit -- -auth .Xauthority
    If you are sitting at an NCD Xterminal, then the only way to use authority files is to set up XDM for that xterminal. I've included a sample NCD configuration file at the end of this doc (appendix A).

    If you are sitting at a Sun running Xkernel, then you will have to have the system manager change the way X is started up. See /export/root/Xkernel/etc/Xstart


    The xauth program is used to look at the contents of your .Xauthority file.
    	xauth list

    Will list the entries in your .Xauthority file. xdm creates and destroys entries in .Xauthority automatically.

    If you want to start up clients on a remote host that could not read your .Xauthority file and display them locally, you will need to copy over your .Xauthority entries.

    The alias rxauth:

    	alias rxauth 'xauth extract - `hostname`:0 | rsh \!:1 xauth merge -'

    will rsh over to the remote client and set up your .Xauthority file for you:

    	rxauth radon
    would rsh over to radon and create entries in my .Xauthority file on radon.

    Now I will be able to start up client on radon and display them on arsenic, but no one else will be able to start a client on radon that will successfully connect to arsenic.

    More information about xauth

    I received mail from someone describing how to use xauth. That mail is included below. Note that I have installed the customized version of xauth on argon and radon sun4s. I hope to install it on sun3s soon. Eventually I hope to fold this mail message to into a better tutorial. Return-Path: robm@ataraxia.Berkeley.EDU Date: Tue, 2 Mar 93 14:23:51 -0800 From: robm@ataraxia.berkeley.edu (Rob McNicholas) Subject: [Fwd: Secure X Server Tutorial] ------- Start of forwarded message ------- Date: Tue, 2 Mar 93 13:59:11 PST From: dglo@manray.berkeley.edu (Dave Glowacki) Message-Id: <9303022159.AA04806@manray.Berkeley.EDU> To: sww-announce@auspex.berkeley.edu Subject: Secure X Server Tutorial The increasing popularity of the X Window System has brought with it an ever-growing number of people willing to take advantage of its security holes. There are publicly available programs which can display every character typed to an xterm window. If you're only using xhost's host-based method of access control as your means of security, you can assume that everything you type *including passwords* can be read by a cracker. Fortunately, X provides a way to secure your communications. This message addresses how to accomplish this whether you use xdm, openwin or some other xinit-based method to start up your server. I) XDM If you're using the Software Warehouse 'xdm' with the default configuration files to manage your workstation display, you should already have authentication. If you're using 'xdm' from another source, you may need to change a few things to get it working. The most general method is to edit the xdm-config file. Simply change the 'DisplayManager*authorize' resource to 'true'. You should also verify that 'DisplayManager._0.authorize' and 'DisplayManager*authComplain' are also set to 'true'. These changes will take effect the next time you start up xdm. If you can't change the xdm-config file for some reason, you can specify these resources with the -xrm flag when you start xdm. Something like xdm -xrm 'DisplayManager*authorize: true' will enable authorization. II) xinit (or programs like startx, which use xinit) If you start X using 'xinit' (which is probably true if you log in using the boring old login:/Password: prompts rather than a bitmapped box,) you can use the 'xauth' program to set up keys to encrypt a connection. Here are two easy steps to X security: 1) Save the following lines in a file named .xserverrc in your home directory: #!/bin/sh # generate new authorization keys each time server is started # for display in :0 `hostname`:0 localhost:0; do xauth create $display XDM-AUTHORIZATION-1 done # start the server # exec X :0 -auth ${XAUTHORITY-$HOME/.Xauthority} *Note* The Software Warehouse version of 'xauth' implements the non-standard 'create' option, so this probably won't work at other sites. If you don't have access to the Software Warehouse, you can create a simple program to generate a random 32 byte string of hexadecimal characters (0-9a-f) and replace the 'xauth create...' lines with: xauth add $display XDM-AUTHORIZATION-1 `your-key-program` 2) If you use 'xinit' and specify something after the '--' option, you'll need to customize the final line of your .xserverrc file. For instance, if you usually type 'xinit -- XsunMono' (in order to use the smaller monochrome Sun server) the final line in your .xserverrc file would be: exec XsunMono :0 -auth ${XAUTHORITY-$HOME/.Xauthority} *Another Note* If you set the XAUTHORITY environment variable to anything (except $HOME/.Xauthority) it must be set BEFORE you run xinit, which does an XOpenDisplay() to verify that the server has started. If the server is started with a non-standard '-auth $XAUTHORITY', xinit won't be able to contact the server and, after several minutes of annoying messages, will kill the server and exit. III) openwin If you use 'openwin' to start up Sun's X/NeWS server, you can get a secure X session by running openwin -auth magic-cookie No matter which way you go about securing your connection, make *sure* to remove any 'xhost' commands which allow hosts access when you start X. .xinitrc and .xsession files are good places to check for these. The next time you start X, you should have a more secure connection. You can confirm this by running 'xhost' with no arguments. It should say something like: access control enabled, only authorized clients can connect This is still not 100% secure, since someone grabbing raw bits off the network could still manage to intercept your key, but it should deter most crackers. As long as your home directory is mounted on every machine you use, this is all you'll need to do. The authorization file is written in a portable format which works across architectures. If you have two or more home directories, you'll need to transfer your keys to a file in each home directory before you are be permitted to open new windows from the machine(s) served by those home directories. This is accomplished with the following command: xauth extract - $DISPLAY | rsh remote-machine xauth merge - (where "remote-machine" is the name of the new machine.) An easier way to do this is to use Software Warehouse version of 'xon' which has been hacked to support a '-auth' flag. The command xon auspex -auth & will start up an xterm window from auspex after making sure your auspex directory has an up-to-date .Xauthority file. The command xon manray -auth xload -geometry =100x50 & will bring up a small xload window from manray after updating the $XAUTHORITY file there. ------- End of forwarded message -------

    Sysadmin notes about setting up xdm

    These are notes for a System Administrator, most users will not find them interesting.

    Setting up an NCD to use XDM

    If you have Xkernel running, you can easily set up an NCD to use the same XDM setup. If you are a version of NCDware earlier than 3.0, include the following file into your NCD configuration file. (Versions earlier that 3.0 will not handle XDM-AUTHORIZATION-1).

    # Set to use XDM
    xdm-server = radon		    # hostname
    virtual-terminal-at-reset = xdm     # {default, cterm, dw-login,
                                        # lat-manager, local-serial, serial,
                                        # telnet, xdm, none}
    xdm-access = indirect               # {broadcast, direct, indirect}
    xdm-death-timeout = default         # {}
    xdm-detect-death = default          # {default, off, on}
    xdm-fail-action = default           # {default, persist, stop}
    xdm-hibernation-time = default      # {}
    xdm-wait-for-last-client = default  # {default, on, off}
    Usually the configuration file is in /usr/X11/lib/ncd/configs. Usually, each Xterminal has its own configuration file. Add the line:
    include-file = 	xdm/tcp
    If you are running NCDware 3.0, site.cfg should have the following lines
    xserver-access-control-enabled = true
    xserver-access-control-enabled-default = true
    xserver-access-control-list = {

    -----Begin of part of site.cfg----- -----End of part of site.cfg----- xdm and XDM-AUTHORIZATION-1

    To use XDM-AUTHORIZATION, xdm must be compiled with -DHASXDMAUTH One way to do this is to set your /usr/lib/X11/config/site.def:
    #define HasXdmAuth		YES
    1. You will have to compile and install  new versions of libXdmcp and xdm.
    	Get libXdmcp/Wraphelp.c
    	Anonymous ftp to export.lcs.mit.edu, look in pub/R5/xdm-auth.
    	make and install libXdmcp
    	make and install xdm
    	To build xdm, you will need the cbc_crypt in libc.a.
    	I copied ohm's sun3 libc.a to /usr/lib/libc_crypt.a
    	Change the xdm Makefile to:
    	EXTRA_LIBRARIES = -L/usr/local/x11r5/lib -Bstatic -ldl -lc_crypt -Bdynamic
    2. Copy over and install a better local version of xauth:
    	This version has a nifty 'create' option.
    	ftp export.lcs.mit.edu /pub/R5untarred/mit/clients/xauth
    	rsh roger-rabbit "cd /usr/sww/X11R5/src/mit/clients/xauth; tar -cf - . " | tar -xBpf -
    	[Our source is in /usr/local/src/x11/xauth]
    	make install
    	make install.man
    If you run xdm on a sun console, then you can use XDM-AUTHORIZATION-1.
    	You have to turn off the screen saver.
    	xdm-config should look like:
    	DisplayManager._0_1.authName:	XDM-AUTHORIZATION-1

    XDM-AUTHORIZATION-1 on NCDs running NCDware3.0

    If you are running NCDware3.0, you may use XDM-AUTHORIZATION-1 See p 6-26 and 6-27 of the "NCDware3.0 Advances User's Guide for Unix Systems"
  • You can use login-xdm-authentication-key to upload the initial XDM-AUTHORIZATION-1 key to the NCD. After you get things working, you should remove login-xdm-authentication-key so that unauthorized userwon't read the key. login-xdm-authentication-key = "123456789abcd"
  • In your xdm directory (usually /usr/lib/X11/xdm), create a file called xdm-keys. This file should be root owned and readable only by root. Add an entry like: # xview11 -Ethernet-00:00:a7:12:03:3a 123456789abcd The key should be up to 14 hexadecimal characters. The key does not need a leading 0x, The manual seems to be wrong about this point. The xdm-config resource DisplayManager*keyFile controls the location and name of xdm-keys Note that all clients running xdm will need to be able to read xdm-keys as root for XDM-AUTHORIZATION-1 to work correctly.
  • Framemaker and xauth

    Certain commercial X programs such as Framemaker and Pure Inc's quantify program qv do not handle XDM-AUTHORIZATION-1, but these programs often will handle MIT-MAGIC-COOKIE-1.

    If you are creating keys in your .xserverrc, you can try: xauth create $display MIT-MAGIC-COOKIE-1

    The reason that Frame and qv don't support XDM-AUTHORIZATION-1 is that XDM-AUTHORIZATION-1 uses the Data Encryption Standard (DES) which is not supposed to be exported. To include XDM-AUTHORIZATION-1 an X11 library, one must obtain a special file from MIT and do a build from X11 sources. Companies like Frame and Pure don't want to have a U.S. version and and export version of their software.

    MIT-MAGIC-COOKIE-1 is sent across the net as plain text, whereas XDM-AUTHORIZATION-1 is encrypted. Using MIT-MAGIC-COOKIE is much more secure than using xhost style authentication.

    exmh and xhost

    If you have problems with exmh, use 'xhost' to see what hosts have access control turned on, then for each host, type xhost -hostname. For instance, if xhost returned foucault.eecs.berkeley.edu and babbage.eecs.berkeley.edu, you would type:
    	xhost -babbage
    	xhost -foucault
    Then use xhost to verify that access to all the hosts have been turned off.

    xhost - merely restricts access to only those on the list, it does not remove access to all hosts.

    cxh at eecs