185 lines
8.8 KiB
Plaintext
185 lines
8.8 KiB
Plaintext
|
|
|
|
A Sample Authorization Protocol for X
|
|
|
|
|
|
Overview
|
|
|
|
The following note describes a very simple mechanism for providing individual
|
|
access to an X Window System display. It uses existing core protocol and
|
|
library hooks for specifying authorization data in the connection setup block
|
|
to restrict use of the display to only those clients that show that they
|
|
know a server-specific key called a "magic cookie". This mechanism is *not*
|
|
being proposed as an addition to the Xlib standard; among other reasons, a
|
|
protocol extension is needed to support more flexible mechanisms. We have
|
|
implemented this mechanism already; if you have comments, please send them
|
|
to us.
|
|
|
|
This scheme involves changes to the following parts of the sample release:
|
|
|
|
o xdm
|
|
- generate random magic cookie and store in protected file
|
|
- pass name of magic cookie file to server
|
|
- when user logs in, add magic cookie to user's auth file
|
|
- when user logs out, generate a new cookie for server
|
|
|
|
o server
|
|
- a new command line option to specify cookie file
|
|
- check client authorization data against magic cookie
|
|
- read in cookie whenever the server resets
|
|
- do not add local machine to host list if magic cookie given
|
|
|
|
o Xlib
|
|
- read in authorization data from file
|
|
- find data for appropriate server
|
|
- send authorization data if found
|
|
|
|
o xauth [new program to manage user auth file]
|
|
- add entries to user's auth file
|
|
- remove entries from user's auth file
|
|
|
|
This mechanism assumes that the superuser and the transport layer between
|
|
the client and the server is secure. Organizations that desire stricter
|
|
security are encouraged to look at systems such as Kerberos (at Project
|
|
Athena).
|
|
|
|
|
|
Description
|
|
|
|
The sample implementation will use the xdm Display Manager to set up and
|
|
control the server's authorization file. Sites that do not run xdm will
|
|
need to build their own mechanisms.
|
|
|
|
Xdm uses a random key (seeded by the system time and check sum of /dev/kmem)
|
|
to generate a unique sequence of characters at 16 bytes long. This sequence
|
|
will be written to a file which is made readable only by the server. The
|
|
server will then be started with a command line option instructing it to use
|
|
the contents of the file as the magic cookie for connections that include
|
|
authorization data. This will also disable the server from adding the local
|
|
machine's address to the initial host list. Note that the actual cookie must
|
|
not be stored on the command line or in an environment variable, to prevent
|
|
it from being publicly obtainable by the "ps" command.
|
|
|
|
If a client presents an authorization name of "MIT-MAGIC-COOKIE-1" and
|
|
authorization data that matches the magic cookie, that client is allowed
|
|
access. If the name or data does not match and the host list is empty,
|
|
that client will be denied access. Otherwise, the existing host-based access
|
|
control will be used. Since any client that is making a connection from a
|
|
machine on the host list will be granted access even if their authorization
|
|
data is incorrect, sites are strongly urged not to set up any default hosts
|
|
using the /etc/X*.hosts files. Granting access to other machines should be
|
|
done by the user's session manager instead.
|
|
|
|
Assuming the server is configured with an empty host list, the existence of the
|
|
cookie is sufficient to ensure there will be no unauthorized access to the
|
|
display. However, xdm will (continue to) work to minimize the chances of
|
|
spoofing on servers that do not support this authorization mechanism. This
|
|
will be done by grabbing the server and the keyboard after opening the display.
|
|
This action will be surrounded by a timer which will kill the server if the
|
|
grabs cannot be done within several seconds. [This level of security is now
|
|
implemented in patches already sent out.]
|
|
|
|
After the user logs in, xdm will add authorization entries for each of the
|
|
server machine's network addresses to the user's authorization file (the format
|
|
of which is described below). This file will usually be named .Xauthority in
|
|
the users's home directory; will be owned by the user (as specified by the
|
|
pw_uid and pw_gid fields in the user's password entry), and will be accessible
|
|
only to the user (no group access). This file will contain authorization data
|
|
for all of the displays opened by the user.
|
|
|
|
When the session terminates, xdm will generate and store a new magic cookie
|
|
for the server. Then, xdm will shutdown its own connection and send a
|
|
SIGHUP to the server process, which should cause the server to reset. The
|
|
server will then read in the new magic cookie.
|
|
|
|
To support accesses (both read and write) from multiple machines (for use in
|
|
environments that use distributed file systems), file locking is done using
|
|
hard links. This is done by creat'ing (sic) a lock file and then linking it
|
|
to another name in the same directory. If the link-target already exists,
|
|
the link will fail, indicating failure to obtain the lock. Linking is used
|
|
instead of just creating the file read-only since link will fail even for
|
|
the superuser.
|
|
|
|
Problems and Solutions
|
|
|
|
There are a few problems with .Xauthority as described. If no home directory
|
|
exists, or if xdm cannot create a file there (disk full), xdm stores the
|
|
cookie in a file in a resource-specified back-up directory, and sets an
|
|
environment variable in the user's session (called XAUTHORITY) naming this
|
|
file. There is also the problem that the locking attempts will need to be
|
|
timed out, due to a leftover lock. Xdm, again, creates a file and set an
|
|
environment variable. Finally, the back-up directory might be full. Xdm,
|
|
as a last resort, provides a function key binding that allows a user to log
|
|
in without having the authorization data stored, and with host-based access
|
|
control disabled.
|
|
|
|
Xlib
|
|
|
|
XOpenDisplay in Xlib was enhanced to allow specification of authorization
|
|
information. As implied above, Xlib looks for the data in the
|
|
.Xauthority file of the home directory, or in the file pointed at by the
|
|
XAUTHORITY environment variable instead if that is defined. This required
|
|
no programmatic interface change to Xlib. In addition, a new Xlib routine
|
|
is provided to explicitly specify authorization.
|
|
|
|
XSetAuthorization(name, namelen, data, datalen)
|
|
int namelen, datalen;
|
|
char *name, *data;
|
|
|
|
There are three types of input:
|
|
|
|
name NULL, data don't care - use default authorization mechanism.
|
|
name non-NULL, data NULL - use the named authorization; get
|
|
data from that mechanism's default.
|
|
name non-NULL, data non-NULL - use the given authorization and data.
|
|
|
|
This interface is used by xdm and might also be used by any other
|
|
applications that wish to explicitly set the authorization information.
|
|
|
|
Authorization File
|
|
|
|
The .Xauthority file is a binary file consisting of a sequence of entries
|
|
in the following format:
|
|
|
|
2 bytes Family value (second byte is as in protocol HOST)
|
|
2 bytes address length (always MSB first)
|
|
A bytes host address (as in protocol HOST)
|
|
2 bytes display "number" length (always MSB first)
|
|
S bytes display "number" string
|
|
2 bytes name length (always MSB first)
|
|
N bytes authorization name string
|
|
2 bytes data length (always MSB first)
|
|
D bytes authorization data string
|
|
|
|
The format is binary for easy processing, since authorization information
|
|
usually consists of arbitrary data. Host addresses are used instead of
|
|
names to eliminate potentially time-consuming name resolutions in
|
|
XOpenDisplay. Programs, such as xdm, that initialize the user's
|
|
authorization file will have to do the same work as the server in finding
|
|
addresses for all network interfaces. If more than one entry matches the
|
|
desired address, the entry that is chosen is implementation-dependent. In
|
|
our implementation, it is always the first in the file.
|
|
|
|
The Family is specified in two bytes to allow out-of-band values
|
|
(i.e. values not in the Protocol) to be used. In particular,
|
|
two new values "FamilyLocal" and "FamilyWild" are defined. FamilyLocal
|
|
refers to any connections using a non-network method of connetion from the
|
|
local machine (Unix domain sockets, shared memory, loopback serial line).
|
|
In this case the host address is specified by the data returned from
|
|
gethostname() and better be unique in a collection of machines
|
|
which share NFS directories. FamilyWild is currently used only
|
|
by xdm to communicate authorization data to the server. It matches
|
|
any family/host address pair.
|
|
|
|
For FamilyInternet, the host address is the 4 byte internet address, for
|
|
FamilyDecnet, the host address is the byte decnet address, for FamilyChaos
|
|
the address is also two bytes.
|
|
|
|
The Display Number is the ascii representation of the display number
|
|
portion of the display name. It is in ascii to allow future expansion
|
|
to PseudoRoots or anything else that might happen.
|
|
|
|
A utility called "xauth" will be provided for editing and viewing the
|
|
contents of authorization files. Note that the user's authorization file is
|
|
not the same as the server's magic cookie file.
|