Requirements

Labeling

In CMW systems, top-level windows need to be clearly marked with their current security domain. The user must be aware that the window he or she is using is considered secret or unclassified. The window system, along with the window manager, is expected to clearly mark windows with visual labels to pass this information along to the user. Applications must be prevented from spoofing the label and misleading the user. In addition to visual labels that indicate which windows are in which security contexts, visual labels that clearly indicate which windows are capable of receiving input are required.

The visual labeling requirements for a CMW may not apply to SELinux systems running the default policy. The SELinux Security Identifier (SID) can encapsulate more information than just the classification level of a process. In an SELinux system, applications are expected to operate in many different domains and unique, clearly distinguishable visual labels for each domain may not be practical.

While individual windows in an X application rarely contain child windows from another client, it is possible. For example, the preview screen for screen savers in both KDE an GNOME execute the screen saver in a small window as the preview pane. This possibility requires us to track data flow on all the window objects in the X server, and apply policy to sub windows as well as parent windows.

If a secured X Window system needs to provide a visual labels, this functionality will be provided by the window manager, which is considered to be a trusted client. The window manager is responsible for determining input focus, so adding CMW-style labeling is an appropriate function for the window manager. The secured X server will provide information to the window manager to enable it to add the visual labels, and will protect the window manager from malicious clients.

Trusted Path

Trusted path is a mechanism by which a user can communicate directly with the trusted computing base, providing confidentiality, integrity, and availability on the input channel. Trusted paths are used for entering particularly sensitive information, like authentication tokens.

The trusted-path requirements for graphical displays are linked to window labeling, as they require that the user be made aware of where their input is and require that their input not go elsewhere. Ensuring a trusted path is most critical at login, so key sequences guaranteed to reset the system to a login state may be sufficient.

Currently, X provides very little protection for an application's input stream (keyboard input, mouse actions). Any client can grab the input stream, observe, discard or otherwise modify it, or fabricate input before passing it to what appears to be the active client application. Any client can open a screen-covering input-only window, catching any otherwise non-grabbed input. The protections developed need to allow a policy to prevent arbitrary programs from grabbing the input and from forwarding faked events, but they do not need to prevent clients from snooping non-grabbed input. To prevent classic X input snooping, the window manager must be trusted. The window manager can then relabel the input stream according to its knowledge of input focus. The secure X server can then apply permissions to input events, allowing the policy to limit their visibility.

Window Data Snooping

X clients can easily retrieve the bitmaps of other client's windows, as demonstrated by the availability of screen shot applications. This ability allows client programs to violate a systems confidentiality policy. The Security Extension already in common X servers provides some protection by preventing untrusted applications from accessing the window data of trusted applications, but it specifies a rather limited policy and is not widely used.

There are two approaches clients can use to get screen shot information. The first is to simply get the information directly from the window via the GetImage request. The secure X server must allow the policy to prohibit this action. The second approach is to create an new empty no-background window over the screen, and then look at its contents. Optimally, the secure X server could enforce a policy that prohibits windows that have no background. The policy we present here does not have sufficient granularity to express this restriction, as window attributes are not suitable objects classes for SELinux. The policy enforcement layer must recognize that mapping a window may involve copying the contents of a window being covered. The server must check for that permission and force some kind of default background upon the window if the permission to copy is denied.

Cut-and-Paste

The cut-and-paste protocol relies on the ability of an application to set properties on the window offering the data [XSelections]. Unfortunately, properties are used for everything from drag-and-drop to instructions to the window manager necessary for the proper operation of the application. Properties are name/value pairs defined outside of the X protocol with specific use dictated both by convention and other standards documents (Internet RFCs). Clients must cooperate with each other and the X server to perform cut-and-paste operations.

A policy can enforce confidentiality and integrity requirements by preventing a client from setting window properties on windows belonging to another client. This policy will also prevent cut-and-paste from working between these clients. If cut-and-paste is required functionality, a mechanism must be developed to mediate cut-and-paste actions. Previous approaches have created a trusted cut-and-paste server that manages all requests, limiting the communication between the two processes.

Another approach would require that the properties of a window be labeled. This would require the use of a property object as a separately managed object inside the X server. This object would be suitable for labeling despite not appearing as an object type in the X protocol. However, without a separate labeling-by-name step, there is no way to separately label the cut-and-paste relevant properties from other client-specific properties. In fact, the property used for passing the actual data in a cut and paste operation is arbitrarily chosen by the client requesting the data.

A trusted window manager could provide a solution, but only in combination with the proposed clipboard related extensions currently under development by XFree86 [ClipExt]. One proposed extension would allow clients to register for notification when the active selection changed. The window manager will claim the selection when that happens and place it in a window with a special label. The policy will allow or deny property reads and sending events to that window.

Application Compatibility

Well-behaved X applications must continue to run unmodified on a secure X system. This high level of transparency would give an SELinux system a large catalog of useful graphical applications and ease development of other applications. Certain applications (e.g. screen-shot programs) may not run, but that is a desired result of policy enforcement.

If possible, actions that would violate the system's security policy should fail cleanly. For example, a paste operation of high confidentiality data into a low-confidentiality client should simply fail, as if no data were available in the clipboard. Screen shot applications should simply fail to accurately represent the state of the screen. Clients should not, in general, see X protocol errors which might cause them to abort abnormally.

Scope of Changes

The changes to the XFree86-based X server need to be minimal as XFree86 is an evolving system. Small, self-contained changes are easier to adapt to changing systems than large intrusive changes, tend to be easier to understand, and are more likely to be accepted by project maintainers.

Any changes to the X system should be suitable for inclusion into the XFree86 project so that SELinux systems can gain greater use. Prior experience in proposing changes to software maintained by others has shown that large complex patches are hard to review are often not applied. If the changes can be pushed into the primary XFree86 tree, they are more likely to be picked up by other systems, and will ease the support burden of the SELinux project.

Placement of Trust

The expectation, presented below, is that the X server will operate as a trusted application, capable of enforcing security decisions. We assume that the X server is able to enforce a wide range of policies, and able to communicate simultaneously with clients in separate domains.

The SELinux module enforces all security decisions in the kernel, protecting the enforcement mechanism from tampering by malicious agents. A system policy will be created that will prevent users from directly controlling the X server. If further assurance is required, then various poly-instantiation approaches could be used[Kirk97], where the system would limit which clients could connect to any given X server, but many X servers could be running at any one time. Particularly in the SELinux model of many domains, a poly-instantiation based approach may consume excessive resources to be practical, but is possible within the design we present.