Security Architecture for the X Protocol

Object Classes

The logical abstractions provided by the X Window system were studied to determine the set of object classes that need to be labeled and controlled by the security enhanced X server. The set of object classes for the X Window system component is shown in Table 1.

The Drawable object class does not represent a type of object actually found in the X server, although it is a type recognized by the X protocol. X requests that draw to an object currently take either a Pixmap or a Window as a target, and the Drawable will represent this object. For the purposes of defining permissions, the Drawable object class is defined to be a separate entity. In the modified X server, whenever a Window or a Pixmap object is created, a Drawable permission class will be used for permission checks related to draw operations.

Server objects other than those listed in Table 1 will be labeled in the secure server. In particular, there will be labels for a single Server object and the Input object. Those objects do not have particular permissions, and so are not listed as object classes here.

Permissions

For each object class, a set of permissions is defined to control access to objects in that class. These permissions were identified by studying the services provided by the X Window system component. For each service, the objects whose state is observed or modified by the service were identified, and permissions for the corresponding object classes were defined.

Control Requirements for Drawables

The requests that reference objects of the Drawable object class are mostly draw functions. The only permission that they need to checked is the permission to draw to that object. The CopyArea, CopyPlane, and GetImage requests can also copy the contents of a Drawable, so these methods will also check for this permission.

The GetGeometry request returns the geometry of the Drawable, which could have been either a Window or a Pixmap. The X server will only check the permissions relevant to the actual object type.

The PolyText8, PolyText16, ImageText8, and ImageText16, requests are listed in Table 15 in the Section called Control Requirements for Fonts and Text with other font requests.

Control Requirements for Windows

As windows are the base input and output object for most X applications, the control requirements for the Window object class are extensive.

The entry in the control table for CreateWindow is abbreviated. The CreateWindow request takes an array of attributes which it uses to set the initial values for the window. This array is the same array that is passed to ConfigureWindow, and so the same permission checks will need to be performed.

Table 12 covers many of the situations in which event permissions will be checked, but not all of them. The event permissions will be checked whenever an event of the appropriate type is sent to the client. This may be as direct result of a client request, in which case the permissions are listed with the request, or it may be more indirect. If the event was spawned directly from a client request, as in the case of the SendEvent and the SelectionClear requests, the SSID will be the SID of the client. Otherwise, the SSID will be the SID of the X server. For input events, the SID will be the SID of the Input object, a second virtual singleton object. The label of the Input object will initially be the same as the server's SID, but may be changed by a trusted window manager. The target SID checked is the SID of the window which is nominally the target of the event.

Control Requirements for Input

Sometimes an X client wishes to prevent other clients from receiving input from the keyboard or the mouse. For example, an application wishing to see if a click is a click or a drag will need to compare button press and release events. This is much easier if it can prevent other applications from receiving pointer events until drag is finished. The X server implements ``grab'' functionality to support these applications.

By calling GrabKeyboard or GrabPointer, the application immediately grabs the input from the keyboard or the pointer, redirecting all future input to the client until the grab is released. The GrabKey and GrabButton calls specify conditions when a grab will occur. Pointer grabs are used to generate system modal dialogs, a practice of declining popularity. Keyboard grabs are rarely used, but the ssh-ask graphical application for grabbing the pass-phrase for ssh uses it to prevent keyboard snooping.

A malicious application can currently change the keyboard mappings in order to disrupt the user. Changes to the input settings are closely related to user preferences, so prudent policies will limited these changes to direct action from the user.

As the keyboard keymap is shared by all applications, the context of the single server object will be used on permission checks. Like other server parameters, these settings may be changed during the server initialization, but generally won't be during normal use. This may not be the case with international users, however. Both KDE and GNOME come with mini applications to change the keyboard mappings, primarily targeted at users of international keyboards.

Applications need to query the state of they keyboard to translate the keycode in a ButtonDownEvent with the character that keycode represents. Very few policies will want to restrict the ability of a client to query the keyboard state.

Control Requirements for Colors and Colormaps

The control requirements for X protocol operations that manage Color and Colormaps objects are described in this section.

Control Requirements for Fonts and Text

The control requirements for X protocol operations that manage Font objects and text manipulation are described in this section.

The Font objects are centralized in the server for performance reasons. An application lists the fonts, loads the fonts it wants to use, and then uses the font to draw into a Drawable. The SID for a Font object will be derived from the label of the font source file, allowing the policy to make font-specific decisions.

Control Requirements for Pixmaps

A Pixmap object is normally used by applications to cache the results of drawing operations. The client will initially draw some complex entity to a pixmap, then copy that pixmap to the target window. Reading a client's pixmap is therefore equivalent to reading the data from the client's window, and writing to the pixmap may be equivalent to writing to the client's window.

While a Window object is more than just a Drawable object, the same can not be said for a Pixmap; thus Pixmap object in the server is represented in the policy only by Drawable objects. Creating a Pixmap creates a Drawable. The Drawable's context is derived from the context of the client that creates it.

Control Requirements for the Cursor object

Cursor objects are associated with windows. When the pointer is over a window, the Cursor object associated with that window will be shown as the pointer image. Most applications create their cursors from a standard cursor font loaded by the server. To limit an application to the standard cursors, the policy should deny the create permission and limit the use of fonts.

Control Requirements for the Server object

The Server object does not represent any object actually managed by the X server. Instead, it is a virtual object used to provide a label for properties of which are global to the X server, and not specific to any one client.

The screen saver requests also need to be enforced on the requests in the MIT-SCREEN-SAVER extension. Those control requirements are not listed here, as this paper has not addressed the control requirements of any extensions.

The host-based access controls secured by the hostcontrol permission have generally been deprecated. The replacement, MIT magic cookies, are not managed through the X server, and therefore can not be controlled by X server permissions.

Extensions

To permit applications to create objects with a specified label rather than the default label, an extended form of each of the object creation requests must be added that accepts an additional context parameter. To permit clients to obtain the context of an object, an extended form of each of the object status requests must be added that returns an additional context parameter. To permit clients to change the context of an object, new requests must be added for these security-aware applications and are shown in Table 19.

For the new requests that are extended forms of existing requests, the existing set of control requirements apply.

Client Communication Events

Client communication events exist to enable client communication, and will be sent by clients to other clients. While any event can be sent via SendEvent the expectation is that all other event types are only generated by the server.

The SelectionClear, SelectionNotify, and SelectionRequest events are used to notify clients of changes to selection buffers used for cut-and-paste functionality. When a client wishes to export a selection buffer, it will use the SetSelectionOwner request, which will generate the SelectionClear event to the previous owner of the selection. When a client wants to get the selection in a different format, it calls the ConvertSelection request, which causes the server to send a SelectionRequest event to the owner of the selection. The owner of the selection is expected to convert the selection to the requested type, and send a SelectionNotify event to the requesting client by the SendEvent request.

The ClientMessage event is an arbitrary event. Two clients who have agreed on the interpretation of data can exchange ClientMessage events. The X server will never generate this type of event.

The PropertyNotify event is sent to a client when properties on a window change. Since the server never changes a windows properties, this event results from client communication.

A policy should only allow clients to send these events to each other, or cause these events to be sent to each other, if it would otherwise allow direct communication between the clients.

Input Events

Input events should only be sent by the server. Input events are generated by the user's interactions with the input hardware. They tell the client about input, and alert the client when input will be directed to the client.

The ButtonPress and ButtonRelease events inform the client when any buttons on the pointing device have been pressed or released. The client can also find out the state of the modifier keys on the keyboard as part of these events. The MotionNotify event gives the client information about the motions of the mouse pointer. A MotionNotify event is guaranteed to be generated only if the motion begins or ends inside the window.

The KeyPress and KeyRelease events inform the client when any keys on the keyboard have been pressed or released. There is no way for a client to select event notification on a subset of the keyboard. If the client receives key events it will receive them when any key on the keyboard is pressed, even the modifier keys.

The KeymapNotify event is reported to clients when a window acquires keyboard input focus. The event allows the client to determine which keys were pressed when the input focus was transfered to the window.

The EnterNotify and LeaveNotify events inform the client when the mouse pointer has entered or left a window. The FocusIn and FocusOut events inform the client when the window has keyboard input focus.

Draw Events

These events alert the client that some portion of its window needs to be redrawn. The Expose event gives the client a list of rectangular areas that need to be redrawn in the given window. In normal operation this event, like most, will only be generated by the server.

The VisibilityNotify event can be used to alert clients that a section of their window is no longer visible. A client could use this information to avoid updating that portion of their window when it changes, for example. The event will also be issued when the window regains visibility.

The NoExpose and GraphicsExpose events are generated by CopyArea and CopyPlane requests. If the copy failed because the source region is obscured, unmapped, or otherwise unavailable, a GraphicsExpose event will be generated. Otherwise, a NoExpose event will be generated.

Window Change Events

These events alert a client when the window manager performs various window operations. They originate only from the X server. There will rarely be any need to prevent a client from receiving any of these events, as they only inform the client of operations that have already occurred. The majority of these events can be sent to both the window that was modified, and the parent of that window.

The CirculateNotify event informs a client when the stacking order has changed. This is normally related to focus changes. The ConfigureNotify event is sent to the client when a window has had its configuration changed by ConfigureWindow.

The CreateNotify and DestroyNotify events are sent to a client when a sub window is created or destroyed. The MapNotify and UnmapNotify events are sent to the window being mapped and unmapped. The GravityNotify event is sent to a window when it has moved because of a change in size of its parent. The ReparentNotify event is sent to a window that has been re-parented.

Window Change Request Events

These events are used by the Window Manager to control certain window manager functionality. If a client requests an operation that the Window Manager controls, the X server will send an appropriate event to the window manager instead of performing the operation. The Window manager can then determine if the operation should be performed, and if so, tell the X server to perform the operation.

Only the window manager should be allowed to to select the StructureRedirectMask events on the root window, and clients should not be allowed to set the override_redirect attribute on their top-level windows. Some older applications may set the attribute for transient windows, but more recent applications will generally use window hints instead. Applications which set the attribute will generally work with the attribute unset.

The different events covered by the windowchangerequest permission contain the same information, and have the same meaning as the equivalent event listed under the windowchangeevent permission. Those permissions are discussed in the Section called Window Change Events.

Server State Change Events

These events are sent to clients when global server state changes. These events should only be sent from the server, although they will frequently result directly from client requests. These events should generally not be quelled by the policy.

The ColormapNotify events is reported to clients when the colormap attribute of a window is changed, or the currently installed colormap changes. Clients that wish to correct their colors based on the currently installed colormap need to receive this event.

The MappingNotify event is reported to all clients when the mappings for the input devices change. Clients need to receive this event to keep their model of the keyboard and pointer mappings consistent with the X server's model.

Event Control Requirements

The control requirements for events generated as the result of client requests are shown in the client request tables. Events can also be dispatched directly from the server, particularly in the case of input events. Any client can forge any event through the SendEvent. Events sent through SendEvent will always have the source SID of the sending client, and the target SID of the target window.

The control requirements for events covered by the clientcomevent are included in Table 12 in the Section called Control Requirements for Windows. The source SID and target SID used are listed there. The target will always be the window receiving the event, and the source will be the client sending the event, or the client that invoked the request that directly caused the event to be sent.

By itself, applying a policy to the inputevent permission will not enforce Trusted Path functionality, as there is not sufficient information to determine the window which has focus. As previously mentioned, a trusted Window Manager could apply a label to the input. The source SID for events covered by the inputevent permission will be that of the input object. Applications will also need to carefully grab input when required, and policies will need to prevent malicious applications from grabbing the input.

For events covered by the serverchangeevent, the source SID will be that of the server object, even though these events happen in response to actions of the client. Clients need to receive these events to properly understand the state of the server, yet these events are indirectly generated by clients. These events allow a high-bandwidth covert channel, and so the permissions to install colormaps or change keyboard mappings should be tightly regulated.

The events covered by the drawevent permission are considered to be asynchronous events. The source SID will be that of the server object. Like the serverchangeevent events, Expose and VisibilityNotify events can result from client requests, and so could be used for covert channels. When the expose event is the result of client actions the server should modify the information in the event to reduce the information passed. The server should enlarge the exposed rectangle to include the entire window.

The events covered by the windowchangerequest permission should only be sent to the window manager. The events are generated as the result of client requests, so the source SID will be that of the client, and the target SID will be that of the window manager. The events covered by the windowchangeevent permission will use the source SID of the client performing the operation, which should be that of the window manager.