X Security
Last updated -[Sun Oct 9 10:17:59 2005 by cxh]-
Places to go
Contents
[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
]
Overview
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
- MIT-MAGIC-COOKIE-1
- XDM-AUTHORIZATION-1
- 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
xauth
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 -------
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
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"
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.
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