home *** CD-ROM | disk | FTP | other *** search
-
-
-
- XSECURITY(1) XSECURITY(1)
-
-
- NNAAMMEE
- Xsecurity - X display access control
-
- SSYYNNOOPPSSIISS
- X provides mechanism for implementing many access control
- systems. The sample implementation includes five mecha-
- nisms:
- 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.
-
- AACCCCEESSSS SSYYSSTTEEMM DDEESSCCRRIIPPTTIIOONNSS
- Host Access
- Any client on a host in the host access control
- list is allowed access to the X server. This sys-
- tem can work reasonably well in an environment
- where everyone trusts everyone, or when only a sin-
- gle 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
- _x_h_o_s_t command. When using the more secure mecha-
- nisms listed below, the host list is normally con-
- figured to be the empty list, so that only autho-
- rized programs can connect to the display.
-
- MIT-MAGIC-COOKIE-1
- 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; _x_d_m generates such cookies auto-
- matically when this form of access control is used.
- The user's copy of the cookie is usually stored in
- the _._X_a_u_t_h_o_r_i_t_y file in the home directory,
- although the environment variable XXAAUUTTHHOORRIITTYY can be
- used to specify an alternate location. _X_d_m auto-
- matically 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 net-
- work 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 run-
- ning 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
-
-
-
- X Version 11 Release 6.1 1
-
-
-
-
-
- XSECURITY(1) XSECURITY(1)
-
-
- control to the physical network. In environments
- where network-level snooping is difficult, this
- system can work reasonably well.
-
- XDM-AUTHORIZATION-1
- Sites in the United States 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 _._X_a_u_-
- _t_h_o_r_i_t_y file and is shared with the X server. How-
- ever, 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
- 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/IP connec-
- tions, the identifier is the address plus port num-
- ber; for local connections it is the process ID and
- 32 bits to form a unique id (in case multiple con-
- nections 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.
-
- SUN-DES-1
- 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 _._X_a_u_t_h_o_r_i_t_y 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 _x_h_o_s_t. 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 _._X_a_u_t_h_o_r_i_t_y file. For example:
-
-
-
- X Version 11 Release 6.1 2
-
-
-
-
-
- XSECURITY(1) XSECURITY(1)
-
-
- 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 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 _k_e_y_l_o_g_i_n on the remote host
- first.
-
- MIT-KERBEROS-5
- Kerberos is a network-based authentication scheme
- developed by MIT for Project Athena. It allows
- mutually suspicious principals to authenticate each
- other as long as each trusts a third party, Ker-
- beros. Each principal has a secret key known only
- to it and Kerberos. 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 ser-
- vices 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 _x_d_m, _x_d_m will use your password
- to obtain the initial Kerberos tickets. _x_d_m stores
- the tickets in a credentials cache file and sets
- the environment variable _K_R_B_5_C_C_N_A_M_E 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 proto-
- col, like the SUN-DES-1 protocol, the owner of a
- display can enable and disable specific users, or
- Kerberos principals. The _x_h_o_s_t 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.
-
- TTHHEE AAUUTTHHOORRIIZZAATTIIOONN FFIILLEE
- Except for Host Access control, each of these systems uses
- data stored in the _._X_a_u_t_h_o_r_i_t_y file to generate the cor-
- rect 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._h_o_s_t_n_a_m_e@_d_o_m_a_i_n when the server
- is started by _x_d_m), and so it is not useful to anyone not
- authorized to connect to the server.
-
- Each entry in the _._X_a_u_t_h_o_r_i_t_y file matches a certain
-
-
-
- X Version 11 Release 6.1 3
-
-
-
-
-
- XSECURITY(1) XSECURITY(1)
-
-
- connection family (TCP/IP, DECnet or local connections)
- and X display name (hostname plus display number). This
- allows multiple authorization entries for different dis-
- plays 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 con-
- nections. Each entry additionally contains the authoriza-
- tion name and whatever private authorization data is
- needed by that authorization type to generate the correct
- information at connection setup time.
-
- The _x_a_u_t_h program manipulates the _._X_a_u_t_h_o_r_i_t_y file format.
- It understands the semantics of the connection families
- and address formats, displaying them in an easy to under-
- stand 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 autho-
- rization information from a file name passed on the com-
- mand line with the _-_a_u_t_h option (see the _X_s_e_r_v_e_r manual
- page). The authorization entries in the file are used to
- control access to the server. In each of the authoriza-
- tion 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 _x_i_n_i_t is
- used.
-
- MIT-MAGIC-COOKIE-1
- This system uses 128 bits of data shared between
- the user and the X server. Any collection of bits
- can be used. _X_d_m generates these keys using a
- cryptographically secure pseudo random number gen-
- erator, and so the key to the next session cannot
- be computed from the current session key.
-
- XDM-AUTHORIZATION-1
- This system uses two pieces of information. First,
- 64 bits of random data, second a 56 bit DES encryp-
- tion key (again, random data) stored in 8 bytes,
- the last byte of which is ignored. _X_d_m generates
- these keys using the same random number generator
- as is used for MIT-MAGIC-COOKIE-1.
-
- SUN-DES-1
- 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 _x_d_m starts the X server, it uses the
- root principal for the machine on which it is run-
- ning (unix._h_o_s_t_n_a_m_e@_d_o_m_a_i_n, e.g.,
-
-
-
- X Version 11 Release 6.1 4
-
-
-
-
-
- XSECURITY(1) XSECURITY(1)
-
-
- "unix.expire.lcs.mit.edu@our.domain.edu"). Putting
- the correct principal name in the _._X_a_u_t_h_o_r_i_t_y file
- causes Xlib to generate the appropriate authoriza-
- tion information using the secure RPC library.
-
- MIT-KERBEROS-5
- Kerberos reads tickets from the cache pointed to by
- the _K_R_B_5_C_C_N_A_M_E environment variable, so does not
- use any data from the _._X_a_u_t_h_o_r_i_t_y file. An entry
- with no data must still exist to tell clients that
- MIT-KERBEROS-5 is available.
-
- Unlike the _._X_a_u_t_h_o_r_i_t_y file for clients, the
- authority file passed by xdm to a local X server
- (with ``--aauutthh _f_i_l_e_n_a_m_e'', see xdm(1)) does contain
- the name of the credentials cache, since the X
- server will not have the _K_R_B_5_C_C_N_A_M_E environment
- variable set. The data of the MIT-KERBEROS-5 entry
- is the credentials cache name and has the form
- ``UU:FILE:_f_i_l_e_n_a_m_e'', where _f_i_l_e_n_a_m_e is the name of
- the credentials cache file created by xdm. Note
- again that this form is _n_o_t used by clients.
-
- FFIILLEESS
- .Xauthority
-
- SSEEEE AALLSSOO
- X(1), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- X Version 11 Release 6.1 5
-
-
-
