| Securing The X Window System With SELinux | ||
|---|---|---|
| <<< Previous | Next >>> | |
In this report, we have assumed that the vast majority of X applications will be unmodified, traditional, security-oblivious applications. None of the preexisting base of X applications are aware of security enhancements. However, there will be some applications which will need or want awareness of the security policy they are running under. An obvious example would be a large office application, which would want to execute document macros in the context of the document. While a graphical login program will need to be security aware, we do not expect it will need to be aware of the X security policies.
As we have mentioned throughout the report, the design of the security-aware X server assumes the existence of a trusted window manager. Certain security decisions need input that the X server can not provide, but the window manager can. By relying on the window manager to make proper visual labeling decisions, we can express these policies in the general policy language.
The server will have a single labeled object to represent the input stream. As mentioned in the Section called Control Requirements for Input, the window manager is responsible for labeling this object appropriately for the window which has input focus.
Most current window managers provide visual labels to let the user know which window has keyboard focus. Client applications provide desired strings for a title bar. The window manager could also visually label windows according to their security context, if this functionality was desired.
Linux systems may use a variety of window managers, all with slightly different functionality. Fortunately, KDE and GNOME have become the defacto standards for desktop environments, and either desktop works when using the other desktop's window manager. By modifying the either of the two window managers to supports the security extensions, we will get suitable coverage for a large portion of the Linux user base.
Large integrated applications, like StarOffice/OpenOffice present unique issues for security. A single application may have several documents open at the same time, and so be managing multiple security domains. These large office applications also include sufficient macro functionality to be considered a run-time environment instead of merely being a document editor and viewer.
While no one has yet started making these large applications security aware, we expect that future work will need to consider their needs. These applications will also need to be aware of the security policies of the X server, if just to help properly direct input.
The free desktop environments will also need to be security aware, but may not be aware of any X related security policies. While you want your file browser to be able to show you the extended security information of your files, it should not need special handling by the X server when it does so.
The file browsing functionality of KDE's file manager and the GNOME equivalent may be crossing security domains, but at least in the KDE case, the file viewer application is a separate program, and can run in a separate domain. To handle these applications, the policy needs to handle applications with sub-windows belonging to other applications, but this should be possible without needing help from the parent application.
| <<< Previous | Home | Next >>> |
| Implementation | Conclusions |