XDMCP Queries The Xaccess File

Other well commented configuration sections follow ..... ..... Administering vendor−specific X flavors recalls our previous discussion. The concept is the same, and configuration rules are the same, data organization is the same, and configuration files are almost the same. Differences are primarily in the naming of programs and configuration files; even the names are recognizable. All X−related administrative skills are fully transparent.

22.3 Access Control and Security of X11

22.3.1 XDMCP Queries

X is running in a network environment; it means the client host can be hypothetically accessed by any host on the network; sometimes, with naughty intentions. The only requirement for a potential intruder is to declare as an X server. Obviously, security issues are of a special interest from an administrative standpoint. First, let us see how a client host could be accessed at all. There are three types of queries defined in XDMCP X Display Manager Control Protocol to access a client host: direct, indirect, and broadcast. The queries originate from a remote X server to be more clear, in the text that follows, we will refer to a remote X server as an X terminal. The three types of queries are presented in the Figure 22.7. 540 Figure 22.7: Direct, indirect, and broadcast queries. A direct query means addressing a particular client host and asking for a connection; the running X daemon again, we will refer to an X daemon keeping in mind both xdm or dtlogin could accept or deny such a request. If it accepts, the login screen is launched on the corresponding X terminal. An indirect queryallows the X daemon on the addressed client host to decide what to do with the query; it could respond directly to the X terminal query forward the query to another client host, or offer a user at the X terminal a choice between multiple client hosts. All this could be configured accordingly. A broadcast query presents a general query throughout the network for any client host running X daemon to respond. The first client host that responds to the query positively makes the connection with the corresponding X terminal.

22.3.2 The Xaccess File

The special file, named Xaccess, was introduced with X11R5 to allow administrators to control how the X daemon responds to different types of queries. This file the opposite of its name is not related to the host access control; all that this file controls is the eligibility of a particular X terminal 541 Eligible X terminals are simply listed in the Xaccess file; queries from unlisted, or explicitly denied, X terminals are simply ignored by the X daemon, without possibility of establishing an X connection. By default, in its MIT−distributed form, the Xaccess file is configured to allow direct and broadcast connections from any X terminal. Here is an example; pay attention, this is the CDE configuration file, so all references in the file are toward the dtlogin daemon: cat usrdtconfigXaccess Xaccess Common Desktop Environment DO NOT EDIT THIS FILE usrdtconfigXaccess is a factory−default file and will be unconditionally overwritten upon subsequent installation. Before making changes to the file, copy it to the configuration directory, etcdtconfig. You must also update the accessFile resource in etcdtconfigXconfig. XConsortium: Xaccess.src maincde1_maint2 19950830 16:21:28 gtsang This file contains a list of host names which are allowed or denied XDMCP connection access to this machine. When a remote display typically an X−termimal requests login service, Dtlogin will consult this file to determine if service should be granted or denied. Access control file for XDMCP connections To control Direct and Broadcast access: pattern To control Indirect queries: pattern list of hostnames andor macros … To use the chooser: pattern CHOOSER BROADCAST or pattern CHOOSER list of hostnames andor macros … To define macros: name list of hosts … The first form tells dtlogin which displays to respond to itself. The second form tells dtlogin to forward indirect queries from hosts matching the specified pattern to the indicated list of hosts. The third form tells dtlogin to handle indirect queries using the chooser; the chooser is directed to send its own queries out via the broadcast address and display the results on the terminal. The fourth form is similar to the third, except instead of using the broadcast address, it sends DirectQuerys to each of the hosts in the list In all cases, dtlogin uses the first entry which matches the terminal; 542 grant service to all remote displays The nicest way to run the chooser is to just ask it to broadcast requests to the network – that way new hosts show up automatically. Sometimes, however, the chooser cant figure out how to broadcast, so this may not work in all environments. CHOOSER BROADCAST any indirect host can get a chooser If youd prefer to configure the set of hosts each terminal sees, then just uncomment these lines and comment the CHOOSER line above and edit the hostlist line as appropriate hostlist host−a host−b CHOOSER hostlist ENTRY FORMAT An entry in this file is either a host name or a pattern. A pattern may contain one or more meta characters matches any sequence of 0 or more characters, and ? matches any single character which are compared against the host name of the remote device requesting service. If the entry is a host name, all comparisons are done using network addresses, so any name which converts to the correct network address may be used. For patterns, only canonical host names are used in the comparison, so do not attempt to match aliases. Preceding either a host name or a pattern with a character causes hosts which match that entry to be excluded. When checking access for a particular display host, each entry is scanned in turn and the first matching entry determines the response. Blank lines are ignored, is treated as a comment delimiter causing the rest of that line to be ignored, ex. xtra.lcs.mit.edu disallow directbroadcast service for xtra bambi.ogi.edu allow access from this particular display .lcs.mit.edu allow access from any display in LCS While the direct and broadcast queries are easy to understand and administer, the indirect query, especially its chooser option, could be a little confusing. The Xaccess file gives an opportunity to the administrator to configure the X daemon for a transfer of an indirect query from an arbitrary X terminal, or a group of X terminals, to the other, specified, client host. The chooser is presented in the Figure 22.8. 543 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