The X Window System serves as the graphical user interface (GUI) foundation for desktops such as GNOME and KDE . A userspace program, the X server, manages the desktop system's display, draws windows, cursors, and other GUI constructs, delivers mouse and keyboard events to GUI applications, and provides basic clipboard and drag & drop support. Client applications, usually with the help of an X library and a toolkit such as GTK or Qt, connect to the X server and issue commands to create and manipulate their GUI . The protocol used by X clients and servers to communicate is extensible, and new command sets have been added to support shared memory, advanced rendering, hardware-accelerated graphics, and other features.
Existing security mechanisms in X mostly involve authenticating clients at connection time. Once connected, however, there are few controls in place to prevent client applications from engaging in malicious behavior. The X protocol allows client applications to manipulate windows belonging to other clients, including moving them, reading their contents, drawing into them, changing their focus, or listening for keyboard and mouse events being sent to them . Clients are also permitted to send events, including fabricated keyboard or mouse input, to other clients. Mechanisms exist for arbitrary data transfer between clients, such as by setting and reading window properties. Clearly, access controls are needed on windows and other X server objects to prevent malicious behavior and control the flow information between X clients.
The Linux kernel provides limited support to the X server, in the form of access to video RAM, but otherwise has no knowledge of the X server's internal objects such as windows. To the kernel, X client applications are simply normal processes which have a socket connection to the X server over which opaque data is being transferred. Current SELinux policy can prevent client applications from connecting to the X server entirely, but this solution is too coarse-grained from a usability perspective. What is needed are fine-grained controls on individual X server objects. An application of the Flask architecture to the X server itself will provide these controls, after which SELinux policy can be written for X objects and the X server made a policy enforcer in the same manner as the kernel.
Several steps are required to achieve this goal. A mechanism for obtaining policy decisions in userspace must be established, and supporting infrastructure must be provided in the SELinux libraries. Flask object classes and permissions must be selected to allow natural, comprehensive policy expressions governing X protocol operations, including protocol extensions. Enforcement logic of some form must be implemented in the X server and Flask semantics implemented. Finally, appropriate policy must be written. The following sections will discuss completed and ongoing work in all of these areas.