1XSECURITY(7) Miscellaneous Information Manual XSECURITY(7)
2
6 Xsecurity - X display access control
7
9 X provides mechanism for implementing many access control systems. The
10 sample implementation includes six mechanisms:
11 Host Access Simple host-based access control.
12 MIT-MAGIC-COOKIE-1 Shared plain-text "cookies".
13 XDM-AUTHORIZATION-1 Secure DES based private-keys.
14 SUN-DES-1 Based on Sun's secure rpc system.
15 MIT-KERBEROS-5 Kerberos Version 5 user-to-user.
16 Server Interpreted Server-dependent methods of access control
17 Not all of these are available in all builds or implementations.
18
20 Host Access
21 Any client on a host in the host access control list is allowed
22 access to the X server. This system can work reasonably well in
23 an environment where everyone trusts everyone, or when only a
24 single person can log in to a given machine, and is easy to use
25 when the list of hosts used is small. This system does not work
26 well when multiple people can log in to a single machine and
27 mutual trust does not exist. The list of allowed hosts is
28 stored in the X server and can be changed with the xhost com‐
29 mand. The list is stored in the server by network address, not
30 host names, so is not automatically updated if a host changes
31 address while the server is running. When using the more secure
32 mechanisms listed below, the host list is normally configured to
33 be the empty list, so that only authorized programs can connect
34 to the display. See the GRANTING ACCESS section of the Xserver
35 man page for details on how this list is initialized at server
36 startup.
37 MIT-MAGIC-COOKIE-1
39 When using MIT-MAGIC-COOKIE-1, the client sends a 128 bit
40 "cookie" along with the connection setup information. If the
41 cookie presented by the client matches one that the X server
42 has, the connection is allowed access. The cookie is chosen so
43 that it is hard to guess; xdm generates such cookies automati‐
44 cally when this form of access control is used. The user's copy
45 of the cookie is usually stored in the .Xauthority file in the
46 home directory, although the environment variable XAUTHORITY can
47 be used to specify an alternate location. Xdm automatically
48 passes a cookie to the server for each new login session, and
49 stores the cookie in the user file at login.
50 The cookie is transmitted on the network without encryption, so
52 there is nothing to prevent a network snooper from obtaining the
53 data and using it to gain access to the X server. This system
54 is useful in an environment where many users are running appli‐
55 cations on the same machine and want to avoid interference from
56 each other, with the caveat that this control is only as good as
57 the access control to the physical network. In environments
58 where network-level snooping is difficult, this system can work
59 reasonably well.
60 XDM-AUTHORIZATION-1
62 Sites who compile with DES support can use a DES-based access
63 control mechanism called XDM-AUTHORIZATION-1. It is similar in
64 usage to MIT-MAGIC-COOKIE-1 in that a key is stored in the .Xau‐
65 thority file and is shared with the X server. However, this key
66 consists of two parts - a 56 bit DES encryption key and 64 bits
67 of random data used as the authenticator.
68 When connecting to the X server, the application generates 192
70 bits of data by combining the current time in seconds (since
71 00:00 1/1/1970 GMT) along with 48 bits of "identifier". For
72 TCP/IPv4 connections, the identifier is the address plus port
73 number; for local connections it is the process ID and 32 bits
74 to form a unique id (in case multiple connections to the same
75 server are made from a single process). This 192 bit packet is
76 then encrypted using the DES key and sent to the X server, which
77 is able to verify if the requestor is authorized to connect by
78 decrypting with the same DES key and validating the authentica‐
79 tor and additional data. This system is useful in many environ‐
80 ments where host-based access control is inappropriate and where
81 network security cannot be ensured.
82 SUN-DES-1
84 Recent versions of SunOS (and some other systems) have included
85 a secure public key remote procedure call system. This system
86 is based on the notion of a network principal; a user name and
87 NIS domain pair. Using this system, the X server can securely
88 discover the actual user name of the requesting process. It
89 involves encrypting data with the X server's public key, and so
90 the identity of the user who started the X server is needed for
91 this; this identity is stored in the .Xauthority file. By
92 extending the semantics of "host address" to include this notion
93 of network principal, this form of access control is very easy
94 to use.
95 To allow access by a new user, use xhost. For example,
97 xhost keith@ ruth@mit.edu
98 adds "keith" from the NIS domain of the local machine, and
99 "ruth" in the "mit.edu" NIS domain. For keith or ruth to suc‐
100 cessfully connect to the display, they must add the principal
101 who started the server to their .Xauthority file. For example:
102 xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
103 This system only works on machines which support Secure RPC, and
104 only for users which have set up the appropriate public/private
105 key pairs on their system. See the Secure RPC documentation for
106 details. To access the display from a remote host, you may have
107 to do a keylogin on the remote host first.
108 MIT-KERBEROS-5
110 Kerberos is a network-based authentication scheme developed by
111 MIT for Project Athena. It allows mutually suspicious princi‐
112 pals to authenticate each other as long as each trusts a third
113 party, Kerberos. Each principal has a secret key known only to
114 it and Kerberos. Principals includes servers, such as an FTP
115 server or X server, and human users, whose key is their pass‐
116 word. Users gain access to services by getting Kerberos tickets
117 for those services from a Kerberos server. Since the X server
118 has no place to store a secret key, it shares keys with the user
119 who logs in. X authentication thus uses the user-to-user scheme
120 of Kerberos version 5.
121 When you log in via xdm, xdm will use your password to obtain
123 the initial Kerberos tickets. xdm stores the tickets in a cre‐
124 dentials cache file and sets the environment variable KRB5CCNAME
125 to point to the file. The credentials cache is destroyed when
126 the session ends to reduce the chance of the tickets being
127 stolen before they expire.
128 Since Kerberos is a user-based authorization protocol, like the
130 SUN-DES-1 protocol, the owner of a display can enable and dis‐
131 able specific users, or Kerberos principals. The xhost client
132 is used to enable or disable authorization. For example,
133 xhost krb5:judy krb5:gildea@x.org
134 adds "judy" from the Kerberos realm of the local machine, and
135 "gildea" from the "x.org" realm.
136 Server Interpreted
138 The Server Interpreted method provides two strings to the X
139 server for entry in the access control list. The first string
140 represents the type of entry, and the second string contains the
141 value of the entry. These strings are interpreted by the server
142 and different implementations and builds may support different
143 types of entries. The types supported in the sample implementa‐
144 tion are defined in the SERVER INTERPRETED ACCESS TYPES section
145 below. Entries of this type can be manipulated via xhost. For
146 example to add a Server Interpreted entry of type localuser with
147 a value of root, the command is xhost +si:localuser:root.
148
150 Except for Host Access control and Server Interpreted Access Control,
151 each of these systems uses data stored in the .Xauthority file to gen‐
152 erate the correct authorization information to pass along to the X
153 server at connection setup. MIT-MAGIC-COOKIE-1 and XDM-AUTHORIZATION-1
154 store secret data in the file; so anyone who can read the file can gain
155 access to the X server. SUN-DES-1 stores only the identity of the
156 principal who started the server (unix.hostname@domain when the server
157 is started by xdm), and so it is not useful to anyone not authorized to
158 connect to the server.
159 Each entry in the .Xauthority file matches a certain connection family
161 (TCP/IP, DECnet or local connections) and X display name (hostname plus
162 display number). This allows multiple authorization entries for dif‐
163 ferent displays to share the same data file. A special connection fam‐
164 ily (FamilyWild, value 65535) causes an entry to match every display,
165 allowing the entry to be used for all connections. Each entry addi‐
166 tionally contains the authorization name and whatever private autho‐
167 rization data is needed by that authorization type to generate the cor‐
168 rect information at connection setup time.
169 The xauth program manipulates the .Xauthority file format. It under‐
171 stands the semantics of the connection families and address formats,
172 displaying them in an easy to understand format. It also understands
173 that SUN-DES-1 and MIT-KERBEROS-5 use string values for the authoriza‐
174 tion data, and displays them appropriately.
175 The X server (when running on a workstation) reads authorization infor‐
177 mation from a file name passed on the command line with the -auth
178 option (see the Xserver manual page). The authorization entries in the
179 file are used to control access to the server. In each of the autho‐
180 rization schemes listed above, the data needed by the server to ini‐
181 tialize an authorization scheme is identical to the data needed by the
182 client to generate the appropriate authorization information, so the
183 same file can be used by both processes. This is especially useful
184 when xinit is used.
185 MIT-MAGIC-COOKIE-1
187 This system uses 128 bits of data shared between the user and
188 the X server. Any collection of bits can be used. Xdm gener‐
189 ates these keys using a cryptographically secure pseudo random
190 number generator, and so the key to the next session cannot be
191 computed from the current session key.
192 XDM-AUTHORIZATION-1
194 This system uses two pieces of information. First, 64 bits of
195 random data, second a 56 bit DES encryption key (again, random
196 data) stored in 8 bytes, the last byte of which is ignored. Xdm
197 generates these keys using the same random number generator as
198 is used for MIT-MAGIC-COOKIE-1.
199 SUN-DES-1
201 This system needs a string representation of the principal which
202 identifies the associated X server. This information is used to
203 encrypt the client's authority information when it is sent to
204 the X server. When xdm starts the X server, it uses the root
205 principal for the machine on which it is running (unix.host‐
206 name@domain, e.g., "unix.expire.lcs.mit.edu@our.domain.edu").
207 Putting the correct principal name in the .Xauthority file
208 causes Xlib to generate the appropriate authorization informa‐
209 tion using the secure RPC library.
210 MIT-KERBEROS-5
212 Kerberos reads tickets from the cache pointed to by the
213 KRB5CCNAME environment variable, so does not use any data from
214 the .Xauthority file. An entry with no data must still exist to
215 tell clients that MIT-KERBEROS-5 is available.
216 Unlike the .Xauthority file for clients, the authority file
218 passed by xdm to a local X server (with ``-auth filename'', see
219 xdm(1)) does contain the name of the credentials cache, since
220 the X server will not have the KRB5CCNAME environment variable
221 set. The data of the MIT-KERBEROS-5 entry is the credentials
222 cache name and has the form ``UU:FILE:filename'', where filename
223 is the name of the credentials cache file created by xdm. Note
224 again that this form is not used by clients.
225
227 The sample implementation includes several Server Interpreted mecha‐
228 nisms:
229 IPv6 IPv6 literal addresses
230 hostname Network host name
231 localuser Local connection user id
232 localgroup Local connection group id
233 IPv6 A literal IPv6 address as defined in IETF RFC 3513.
235 hostname
237 The value must be a hostname as defined in IETF RFC 2396. Due to
238 Mobile IP and dynamic DNS, the name service is consulted at con‐
239 nection authentication time, unlike the traditional host access
240 control list which only contains numeric addresses and does not
241 automatically update when a host's address changes. Note that
242 this definition of hostname does not allow use of literal IP
243 addresses.
244 localuser & localgroup
246 On systems which can determine in a secure fashion the creden‐
247 tials of a client process, the "localuser" and "localgroup"
248 authentication methods provide access based on those creden‐
249 tials. The format of the values provided is platform specific.
250 For POSIX & UNIX platforms, if the value starts with the charac‐
251 ter '#', the rest of the string is treated as a decimal uid or
252 gid, otherwise the string is defined as a user name or group
253 name.
254 If your system supports this method and you use it, be warned
256 that some programs that proxy connections and are setuid or set‐
257 gid may get authenticated as the uid or gid of the proxy
258 process. For instance, some versions of ssh will be authenti‐
259 cated as the user root, no matter what user is running the ssh
260 client, so on systems with such software, adding access for
261 localuser:root may allow wider access than intended to the X
262 display.
263
265 .Xauthority
266
268 X(7), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)
269X Version 11 xorg-docs 1.3 XSECURITY(7)