How does x11 authorization works? (MIT Magic Cookie)

Question

I am interested in an in-depth answer explaining how exactly X11 authorization works and especially MIT Magic Cookies.

I understand that what it actually does is to forbid access to everyone else except the user that is logged in, also there are some control mechanisms that control whether a client application can connect to an X display server or not.

I also found that there are five standard access control mechanisms and they can be categorized in three main categories:

1. Access based on host
2. Access based on cookie
3. Access based on user

But from this point and on I don't really understand the way these work and what ways they exactly use in order to do the authorizations.

Answer 1

Well, first of all there is a file ~/.Xauthority on the machine. Notice that (usually on machine with GUI) wrong permissions of this file, can cause a login screen loop... (took me hours to understand that).

As you mentioned there are 5 mechanisms:

1. Host access: the server has host access list (if a network address exists in this list, the connection is permitted). the list is managed using xhost command. NOTE: this doesn't allow more than a single connection simultaneously. I don't know more about this method because I don't really used it. but you can see man Xserver GRANTING ACCESS section :)

2. MIT-magic-cookie-1: Generating 128bit of key ("cookie"), storing it in ~/.Xauthority (or where XAUTHORITY envvar points to). The client sends it to server plain! the server checks whether it has a copy of this "cookie" and if so, the connection is permitted. the key is generated by DMX.

3. XDM-authorization-1: Again, there is a key stored in ~/.Xauthority. this key consists 2 parts- 56bit DES encryption key and 64bits of random data used as the authenticator. When you connect to the server the client generate 192bits of data: ctime combined with 48bits identifier (for tcp/ip: ip address+port, for local connections it's the PID and 32 bit unique id). the DES key is used to encrypt the data and then it is sent to server. the server validate the user by decrypting it then validating the 64bits authenticator and additional data.

4. sun-des-1: it uses asymmetric encryption, the server has a public key which he uses to decrypt incomming requests. it also uses the "host list". This require some additional mechanisms in the network, I don't have such network so again, I don't understand this mechanism well.

5. server interpreted: It can be implemented in so many ways... but in general, the client send 2 string to server. The second string is the user entry (such as username) and the first string is the entry type (such as localuser).

NOTE: the 2nd, 3rd and 4th mechanisms store the keys inside ~/.Xauthority therefore anyone who has access to this file, can connect to the server pretending to be "you".

xauth command can parse Xauthority file and extract the interesting values.

$ xauth 
Using authority file /home/ME/.Xauthority
xauth> list        
ME/unix:10  MIT-MAGIC-COOKIE-1  5e443c146376d0bdadfd712bfe7654be
ME/unix:0  MIT-MAGIC-COOKIE-1  c48ddba801384dce3aaaa9d442931ea12
xauth> info
Authority file:       /home/ME/.Xauthority
File new:             no
File locked:          no
Number of entries:    2
Changes honored:      yes
Changes made:         no
Current input:        (stdin):2
xauth> 

• The data is changed....