Other Access Control Mechanisms

Figure 22.8: The chooser. For example, the Xaccess entry: .scps.nyu.edu clientname.scps.nyu.edu will forward an Indirect query from any X terminal in the scps.nyu.edu domain directly to the client host clientname.scps.nyu.edu. Alternatively, to set the X daemon to respond to an indirect query with the Chooser Box on the X terminal screen, offers a user the chance to choose between several displayed client hosts. The Xaccess entry: .scps.nyu.edu CHOOSER client1.scps.nyu.edu client2.scps.nyu.edu client3.scps.nyu.edu will allow the user on any X terminal in the scps.nyu.edu domain to choose the client host between client1, client2, and client3. Instead of a list of client hosts to choose from, the Xaccess entry: .scps.nyu.edu CHOOSER BROADCAST allows the user on the X terminal to choose among all client hosts that respond to the chooser broadcast query. Chooser is the compiled client program; the opposite of other client programs that are scripts, this program cannot be read; however, it could be configured via the Xresources file.

22.3.3 Other Access Control Mechanisms

The described X terminal eligibility checking, provided by the Xaccess file, is not the only available access control; there are several other host−based and user−based access control mechanisms. The host−based scheme involves a system file etcX n. hosts and can be controlled using the xhost client program. The user−based schemes involve authorization capabilities provided by the 544 The etcXn. hosts file contains a list of hosts that are allowed to access local X server n this file resides on the X server side. In most cases, a single local X server is running on a particular system, so the etcX0.hosts file is the only important one. This file is not included in any default configurations of X11, and it must be edited by a system administrator. This file lists all client hosts that X server can communicate with. How it works is presented in Figure 22.9a. Figure 22.9: a Host−based access control; b User−based access control. In this hypothetical example, the local X server pink:0.0 could be accessed by the host blue.scps.edu hosts in the same domain do not require the domain name suffix, but it is recommended to use it, while the access is denied to the host red.scps.edu. Additional acceptable hosts are also pink.scps.edu the host where the X server is running, and green.colors.com; all these hosts are specified in the etcX0.hosts file at the host pink.scps.edu. The xhost command could be used, interactively, to grant or deny access to the X server, i.e., to modify the etcX0.hosts file. This could be done only since a login session was established with the X server we want to change access to. Otherwise, such an attempt would be rejected, and an error message displayed. The host−based access control is insufficient for true security; it has some conceptual drawbacks. For example, it is overridden by NIS, and any user included in the NIS password map is granted access regardless of the hosts status. Because of that, starting with X11R4, a user−based access 545 The MIT−MAGIC−COOKIE−1, presented in Figure 22.9b, is the most common method, although it is not the most secure one. If both the client host and the X server are configured to use this method, then when a user logs in using an X daemon, a machine readable code is put in a file called .Xauthority in the users home directory. This code, called a magic cookie, is also transferred to the X server. Practically, the magic cookie presents some kind of a passcode known only to a particular X server, and a particular user on a particular host do not read it literally — as a matter of fact, all that is hidden from the real user. Once the magic cookie is established for that X session, each client program must present the passcode before it is allowed to connect to the X server. The only way for a client to get the passcode is by reading the .Xauthority file in the users home directory. The existing permissions for this file are write and read only for its user−owner, and it means that only client programs started by the same user can read the magic cookie. Obviously this type of access control is based entirely on UNIX file permissions, and it is as secure as the users account protected by a password. Here is a real example: ls −l homesam.Xautority −rw −−−−−−−−−−− 1 sam 99 Dec 12 16:29 homesam.Xauthority cat homesam.Xauthority OMIT−MAGIC−COOKIE−15nsO6ZzEasP17vcmx370MIT−MAGIC−COOKIE−15nsO6ZzEasP17v The displayed passcode does not make a lot of sense, especially because it contains nonprinting characters that could not even be displayed. The access control is activated through the corresponding, master configuration file, by the authorization resource entry: DisplayManager.DISPLAY.authorize: true The concept of the MIT−MAGIC−COOKIE−1 supposes that all client programs have access to the magic cookie in the .Xauthority file. This is OK, as long as the client programs are local at the host where the users home directory, with the .Xauthority file, is located. However, in the distributed processing environment, it is not a must. The solution was found with the program xauth, which is used to propagate the magic cookie from one client host to another. xauth extracts a users authorization information for the current display, copies it to another machine, and merges it into the HOME.Xauthority file on the remote machine. In the hierarchy of access controls, the user−based access control is overridden by the host−based access control. For that reason, it is important that no host is being listed in the host−based access list at the X server side; for any listed client host, the user−based access control will be automatically bypassed. To check from the command line for any client host listed, type: xhost access control enabled, only authorized client can connect If a bunch of hosts are also listed afterward, they should be removed, or their users will have access granted regardless of user−based access control use the command xhost − to remove all hosts. 546

22.4 The User X Environment