268 lines
13 KiB
HTML
268 lines
13 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of XSECURITY</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>XSECURITY</H1>
|
|
Section: Environments, Tables, and Troff Macros (7)<BR>Updated: xorg-docs 1.7.1<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
Xsecurity - X display access control
|
|
<A NAME="lbAC"> </A>
|
|
<H2>OVERVIEW</H2>
|
|
|
|
<P>
|
|
|
|
X provides mechanism for implementing many access control systems.
|
|
The sample implementation includes five mechanisms:
|
|
<PRE>
|
|
<BR>
|
|
|
|
Host Access Simple host-based access control.
|
|
MIT-MAGIC-COOKIE-1 Shared plain-text "cookies".
|
|
XDM-AUTHORIZATION-1 Secure DES based private-keys.
|
|
SUN-DES-1 Based on Sun's secure rpc system.
|
|
Server Interpreted Server-dependent methods of access control
|
|
</PRE>
|
|
|
|
Not all of these are available in all builds or implementations.
|
|
<A NAME="lbAD"> </A>
|
|
<H2>ACCESS SYSTEM DESCRIPTIONS</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="1">Host Access<DD>
|
|
Any client on a host in the host access control list is allowed access to
|
|
the X server. This system can work reasonably well in an environment
|
|
where everyone trusts everyone, or when only a single person can log in
|
|
to a given machine, and is easy to use when the list of hosts used is small.
|
|
This system does not work well when multiple people can log in to a single
|
|
machine and mutual trust does not exist.
|
|
The list of allowed hosts is stored in the X server and can be changed with
|
|
the <I>xhost</I> command. The list is stored in the server by network
|
|
address, not host names, so is not automatically updated if a host changes
|
|
address while the server is running.
|
|
When using the more secure mechanisms listed below, the host list is
|
|
normally configured to be the empty list, so that only authorized
|
|
programs can connect to the display. See the GRANTING ACCESS section of
|
|
the <I>Xserver</I> man page for details on how this list is initialized at
|
|
server startup.
|
|
<DT id="2">MIT-MAGIC-COOKIE-1<DD>
|
|
When using MIT-MAGIC-COOKIE-1,
|
|
the client sends a 128 bit "cookie"
|
|
along with the connection setup information.
|
|
If the cookie presented by the client matches one
|
|
that the X server has, the connection is allowed access.
|
|
The cookie is chosen so that it is hard to guess;
|
|
<I>xdm</I> generates such cookies automatically when this form of
|
|
access control is used.
|
|
The user's copy of
|
|
the cookie is usually stored in the <I>.Xauthority</I> file in the home
|
|
directory, although the environment variable <B>XAUTHORITY</B> can be used
|
|
to specify an alternate location.
|
|
<I>Xdm</I> automatically passes a cookie to the server for each new
|
|
login session, and stores the cookie in the user file at login.
|
|
<DT id="3"><DD>
|
|
The cookie is transmitted on the network without encryption, so
|
|
there is nothing to prevent a network snooper from obtaining the data
|
|
and using it to gain access to the X server. This system is useful in an
|
|
environment where many users are running applications on the same machine
|
|
and want to avoid interference from each other, with the caveat that this
|
|
control is only as good as the access control to the physical network.
|
|
In environments where network-level snooping is difficult, this system
|
|
can work reasonably well.
|
|
<DT id="4">XDM-AUTHORIZATION-1<DD>
|
|
Sites who compile with DES support can use a DES-based access control
|
|
mechanism called XDM-AUTHORIZATION-1.
|
|
It is similar in usage to MIT-MAGIC-COOKIE-1 in that a key is
|
|
stored in the <I>.Xauthority</I> file and is shared with the X server.
|
|
However,
|
|
this key consists of two parts - a 56 bit DES encryption key and 64 bits of
|
|
random data used as the authenticator.
|
|
<DT id="5"><DD>
|
|
When connecting to the X server, the application generates 192 bits of data
|
|
by combining the current time in seconds (since 00:00 1/1/1970 GMT) along
|
|
with 48 bits of "identifier". For TCP/IPv4 connections, the identifier is
|
|
the address plus port number; for local connections it is the process ID
|
|
and 32 bits to form a unique id (in case multiple connections to the same
|
|
server are made from a single process). This 192 bit packet is then
|
|
encrypted using the DES key and sent to the X server, which is able to
|
|
verify if the requestor is authorized to connect by decrypting with the
|
|
same DES key and validating the authenticator and additional data.
|
|
This system is useful in many environments where host-based access control
|
|
is inappropriate and where network security cannot be ensured.
|
|
<DT id="6">SUN-DES-1<DD>
|
|
Recent versions of SunOS (and some other systems) have included a
|
|
secure public key remote procedure call system. This system is based
|
|
on the notion of a network principal; a user name and NIS domain pair.
|
|
Using this system, the X server can securely discover the actual user
|
|
name of the requesting process. It involves encrypting data with the
|
|
X server's public key, and so the identity of the user who started the
|
|
X server is needed for this; this identity is stored in the <I>.Xauthority</I>
|
|
file. By extending the semantics of "host address" to include this notion of
|
|
network principal, this form of access control is very easy to use.
|
|
<DT id="7"><DD>
|
|
To allow access by a new user, use <I>xhost</I>. For example,
|
|
<PRE>
|
|
xhost keith@ <A HREF="mailto:ruth@mit.edu">ruth@mit.edu</A>
|
|
</PRE>
|
|
|
|
adds "keith" from the NIS domain of the local machine, and "ruth" in
|
|
the "mit.edu" NIS domain. For keith or ruth to successfully connect
|
|
to the display, they must add the principal who started the server to
|
|
their <I>.Xauthority</I> file. For example:
|
|
<PRE>
|
|
xauth add expo.lcs.mit.edu:0 SUN-DES-1 <A HREF="mailto:unix.expo.lcs.mit.edu@our.domain.edu">unix.expo.lcs.mit.edu@our.domain.edu</A>
|
|
</PRE>
|
|
|
|
This system only works on machines which support Secure RPC, and only for
|
|
users which have set up the appropriate public/private key pairs on their
|
|
system. See the Secure RPC documentation for details.
|
|
To access the display from a remote host, you may have to do a
|
|
<I>keylogin</I> on the remote host first.
|
|
<DT id="8">Server Interpreted<DD>
|
|
The Server Interpreted method provides two strings to the X server for
|
|
entry in the access control list. The first string represents the type
|
|
of entry, and the second string contains the value of the entry. These
|
|
strings are interpreted by the server and different implementations and
|
|
builds may support different types of entries. The types supported in
|
|
the sample implementation are defined in the SERVER INTERPRETED ACCESS
|
|
TYPES section below. Entries of this type can be manipulated via
|
|
<I>xhost</I>. For example to add a Server Interpreted entry of type
|
|
localuser with a value of root, the command is <B>xhost +si:localuser:root</B>.
|
|
</DL>
|
|
<A NAME="lbAE"> </A>
|
|
<H2>THE AUTHORIZATION FILE</H2>
|
|
|
|
<P>
|
|
|
|
Except for Host Access control and Server Interpreted Access Control, each of
|
|
these systems uses data stored in
|
|
the <I>.Xauthority</I> file to generate the correct authorization information
|
|
to pass along to the X server at connection setup. MIT-MAGIC-COOKIE-1 and
|
|
XDM-AUTHORIZATION-1 store secret data in the file; so anyone who can read
|
|
the file can gain access to the X server. SUN-DES-1 stores only the
|
|
identity of the principal who started the server
|
|
(unix.<I>hostname</I>@<I>domain</I> when the server is started by <I>xdm</I>),
|
|
and so it is not useful to anyone not authorized to connect to the server.
|
|
<P>
|
|
|
|
Each entry in the <I>.Xauthority</I> file matches a certain connection family
|
|
(TCP/IP, DECnet or local connections) and X display name (hostname plus display
|
|
number). This allows multiple authorization entries for different displays
|
|
to share the same data file. A special connection family (FamilyWild, value
|
|
65535) causes an entry to match every display, allowing the entry to be used
|
|
for all connections. Each entry additionally contains the authorization
|
|
name and whatever private authorization data is needed by that authorization
|
|
type to generate the correct information at connection setup time.
|
|
<P>
|
|
|
|
The <I>xauth</I> program manipulates the <I>.Xauthority</I> file format.
|
|
It understands the semantics of the connection families and address formats,
|
|
displaying them in an easy to understand format. It also understands that
|
|
SUN-DES-1 uses
|
|
string values for the authorization data, and displays
|
|
them appropriately.
|
|
<P>
|
|
|
|
The X server (when running on a workstation) reads authorization
|
|
information from a file name passed on the command line with the <I>-auth</I>
|
|
option (see the <I>Xserver</I> manual page). The authorization entries in
|
|
the file are used to control access to the server. In each of the
|
|
authorization schemes listed above, the data needed by the server to initialize
|
|
an authorization scheme is identical to the data needed by the client to
|
|
generate the appropriate authorization information, so the same file can be
|
|
used by both processes. This is especially useful when <I>xinit</I> is used.
|
|
<DL COMPACT>
|
|
<DT id="9">MIT-MAGIC-COOKIE-1<DD>
|
|
This system uses 128 bits of data shared between the user and the X server.
|
|
Any collection of bits can be used. <I>Xdm</I> generates these keys using a
|
|
cryptographically secure pseudo random number generator, and so the key to
|
|
the next session cannot be computed from the current session key.
|
|
<DT id="10">XDM-AUTHORIZATION-1<DD>
|
|
This system uses two pieces of information. First, 64 bits of random data,
|
|
second a 56 bit DES encryption key (again, random data) stored
|
|
in 8 bytes, the last byte of which is ignored. <I>Xdm</I> generates these keys
|
|
using the same random number generator as is used for MIT-MAGIC-COOKIE-1.
|
|
<DT id="11">SUN-DES-1<DD>
|
|
This system needs a string representation of the principal which identifies
|
|
the associated X server.
|
|
This information is used to encrypt the client's authority information
|
|
when it is sent to the X server.
|
|
When <I>xdm</I> starts the X server, it uses the root
|
|
principal for the machine on which it is running
|
|
(unix.<I>hostname</I>@<I>domain</I>, e.g.,
|
|
"<A HREF="mailto:unix.expire.lcs.mit.edu@our.domain.edu">unix.expire.lcs.mit.edu@our.domain.edu</A>"). Putting the correct principal
|
|
name in the <I>.Xauthority</I> file causes Xlib to generate the appropriate
|
|
authorization information using the secure RPC library.
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>SERVER INTERPRETED ACCESS TYPES</H2>
|
|
|
|
The sample implementation includes several Server Interpreted mechanisms:
|
|
<PRE>
|
|
<BR>
|
|
|
|
IPv6 IPv6 literal addresses
|
|
hostname Network host name
|
|
localuser Local connection user id
|
|
localgroup Local connection group id
|
|
</PRE>
|
|
|
|
<DL COMPACT>
|
|
<DT id="12">IPv6<DD>
|
|
A literal IPv6 address as defined in IETF RFC 3513. This allows adding
|
|
IPv6 addresses when the X server supports IPv6, but the xhost client was
|
|
compiled without IPv6 support.
|
|
<DT id="13">hostname<DD>
|
|
The value must be a hostname as defined in IETF RFC 2396. Due to Mobile IP
|
|
and dynamic DNS, the name service is consulted at connection
|
|
authentication time, unlike the traditional host access control list
|
|
which only contains numeric addresses and does not automatically update when
|
|
a host's address changes. Note that this definition of hostname does
|
|
not allow use of literal IP addresses.
|
|
<DT id="14">localuser & localgroup<DD>
|
|
On systems which can determine in a secure fashion the credentials of a client
|
|
process, the "localuser" and "localgroup" authentication methods provide access
|
|
based on those credentials. The format of the values provided is platform
|
|
specific. For POSIX & UNIX platforms, if the value starts with the
|
|
character '#', the rest of the string is treated as a decimal uid or gid,
|
|
otherwise the string is defined as a user name or group name.
|
|
<DT id="15"><DD>
|
|
If your system supports this method and you use it, be warned that some
|
|
programs that proxy connections and are setuid or setgid may get authenticated
|
|
as the uid or gid of the proxy process. For instance, some versions of ssh
|
|
will be authenticated as the user root, no matter what user is running the
|
|
ssh client, so on systems with such software, adding access for localuser:root
|
|
may allow wider access than intended to the X display.
|
|
</DL>
|
|
<A NAME="lbAG"> </A>
|
|
<H2>FILES</H2>
|
|
|
|
.Xauthority
|
|
<A NAME="lbAH"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<A HREF="/cgi-bin/man/man2html?7+X">X</A>(7), <A HREF="/cgi-bin/man/man2html?1+xdm">xdm</A>(1), <A HREF="/cgi-bin/man/man2html?1+xauth">xauth</A>(1), <A HREF="/cgi-bin/man/man2html?1+xhost">xhost</A>(1), <A HREF="/cgi-bin/man/man2html?1+xinit">xinit</A>(1), <A HREF="/cgi-bin/man/man2html?1+Xserver">Xserver</A>(1)
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="16"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="17"><A HREF="#lbAC">OVERVIEW</A><DD>
|
|
<DT id="18"><A HREF="#lbAD">ACCESS SYSTEM DESCRIPTIONS</A><DD>
|
|
<DT id="19"><A HREF="#lbAE">THE AUTHORIZATION FILE</A><DD>
|
|
<DT id="20"><A HREF="#lbAF">SERVER INTERPRETED ACCESS TYPES</A><DD>
|
|
<DT id="21"><A HREF="#lbAG">FILES</A><DD>
|
|
<DT id="22"><A HREF="#lbAH">SEE ALSO</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:10 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|