MirBSD manpage: Xsecurity(7)

XSECURITY(7)        UNIX Programmer's Manual         XSECURITY(7)


     Xsecurity - X display access control


     X provides mechanism for implementing many access control
     systems. The sample implementation includes five mechanisms:
         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.
         MIT-KERBEROS-5                Kerberos Version 5 user-to-user.


     Host Access
          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
          xhost command. 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.

          When using MIT-MAGIC-COOKIE-1, the client sends a 128
          bit "cookie" along with the connection setup informa-
          tion. 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; xdm generates such cookies automatically when
          this form of access control is used. The user's copy of
          the cookie is usually stored in the .Xauthority file in
          the home directory, although the environment variable
          XAUTHORITY can be used to specify an alternate loca-
          tion. Xdm automatically passes a cookie to the server
          for each new login session, and stores the cookie in
          the user file at login.

          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

XFree86                   Version 4.5.0                         1

XSECURITY(7)        UNIX Programmer's Manual         XSECURITY(7)

          difficult, this system can work reasonably well.

          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 .Xauthority 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.

          When connecting to the X server, the application gen-
          erates 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.

          Recent versions of SunOS (and some other systems) have
          included a secure public key remote procedure call sys-
          tem.  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 .Xau-
          thority 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.

          To allow access by a new user, use xhost.  For example,
              xhost keith@ ruth@mit.edu
          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 .Xau-
          thority file.  For example:
              xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
          This system only works on machines which support Secure
          RPC, and only for users which have set up the appropri-
          ate public/private key pairs on their system.  See the

XFree86                   Version 4.5.0                         2

XSECURITY(7)        UNIX Programmer's Manual         XSECURITY(7)

          Secure RPC documentation for details. To access the
          display from a remote host, you may have to do a keylo-
          gin on the remote host first.

          Kerberos is a network-based authentication scheme
          developed by MIT for Project Athena.  It allows mutu-
          ally suspicious principals to authenticate each other
          as long as each trusts a third party, Kerberos.  Each
          principal has a secret key known only to it and Ker-
          beros.  Principals includes servers, such as an FTP
          server or X server, and human users, whose key is their
          password.  Users gain access to services by getting
          Kerberos tickets for those services from a Kerberos
          server.  Since the X server has no place to store a
          secret key, it shares keys with the user who logs in.
          X authentication thus uses the user-to-user scheme of
          Kerberos version 5.

          When you log in via xdm, xdm will use your password to
          obtain the initial Kerberos tickets.  xdm stores the
          tickets in a credentials cache file and sets the
          environment variable KRB5CCNAME to point to the file.
          The credentials cache is destroyed when the session
          ends to reduce the chance of the tickets being stolen
          before they expire.

          Since Kerberos is a user-based authorization protocol,
          like the SUN-DES-1 protocol, the owner of a display can
          enable and disable specific users, or Kerberos princi-
          pals. The xhost client is used to enable or disable
          authorization. For example,
              xhost krb5:judy krb5:gildea@x.org
          adds "judy" from the Kerberos realm of the local
          machine, and "gildea" from the "x.org" realm.


     Except for Host Access control, each of these systems uses
     data stored in the .Xauthority 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.hostname@domain when the server is started
     by xdm), and so it is not useful to anyone not authorized to
     connect to the server.

     Each entry in the .Xauthority file matches a certain connec-
     tion family (TCP/IP, DECnet or local connections) and X
     display name (hostname plus display number).  This allows
     multiple authorization entries for different displays to

XFree86                   Version 4.5.0                         3

XSECURITY(7)        UNIX Programmer's Manual         XSECURITY(7)

     share the same data file.  A special connection family (Fam-
     ilyWild, 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.

     The xauth program manipulates the .Xauthority 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 and MIT-
     KERBEROS-5 use string values for the authorization data, and
     displays them appropriately.

     The X server (when running on a workstation) reads authori-
     zation information from a file name passed on the command
     line with the -auth option (see the Xserver 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 informa-
     tion, so the same file can be used by both processes.  This
     is especially useful when xinit is used.

          This system uses 128 bits of data shared between the
          user and the X server. Any collection of bits can be
          used.  Xdm generates these keys using a cryptographi-
          cally secure pseudo random number generator, and so the
          key to the next session cannot be computed from the
          current session key.

          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.  Xdm generates these keys using
          the same random number generator as is used for MIT-

          This system needs a string representation of the prin-
          cipal 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 xdm
          starts the X server, it uses the root principal for the
          machine on which it is running (unix.hostname@domain,
          e.g., "unix.expire.lcs.mit.edu@our.domain.edu").  Put-
          ting the correct principal name in the .Xauthority file
          causes Xlib to generate the appropriate authorization

XFree86                   Version 4.5.0                         4

XSECURITY(7)        UNIX Programmer's Manual         XSECURITY(7)

          information using the secure RPC library.

          Kerberos reads tickets from the cache pointed to by the
          KRB5CCNAME environment variable, so does not use any
          data from the .Xauthority file.  An entry with no data
          must still exist to tell clients that MIT-KERBEROS-5 is

          Unlike the .Xauthority file for clients, the authority
          file passed by xdm to a local X server (with ``-auth
          filename'', see xdm(1)) does contain the name of the
          credentials cache, since the X server will not have the
          KRB5CCNAME environment variable set. The data of the
          MIT-KERBEROS-5 entry is the credentials cache name and
          has the form ``UU:FILE:filename'', where filename is
          the name of the credentials cache file created by xdm.
          Note again that this form is not used by clients.




     X(7), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)

XFree86                   Version 4.5.0                         5

Generated on 2021-12-07 11:07:08 by $MirOS: src/scripts/roff2htm,v 1.103 2021/01/23 20:24:35 tg Exp $ — This product includes material provided by mirabilos.

These manual pages and other documentation are copyrighted by their respective writers; their sources are available at the project’s CVSweb, AnonCVS and other mirrors. The rest is Copyright © 2002–2021 MirBSD.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report — diffs preferred.