a high assurance window system prototype1 - CiteSeerX

Journal of Computer Security 2, 2, (1993 published mid 1994), 159{190 IOS Press

159

A HIGH ASSURANCE WINDOW SYSTEM PROTOTYPE1 Jeremy Epstein Cordant, Inc. John McHugh Portland State University Hilarie Orman University of Arizona Rita Pascale ORA Corporation Ann Marmor-Squires, Bonnie Danner TRW Systems Division Charles R. Martin The University of North Carolina Martha Branstad, Glenn Benson, Doug Rothnie Trusted Information Systems, Inc.

Abstract

This paper describes the architecture of a prototype multilevel secure windowing system based on the X Window System. The prototype, known as TX, is designed to meet the class B3 architectural requirements of the Trusted Computer System Evaluation Criteria (TCSEC). The architecture and prototype described here demonstrate that high assurance windowing technology is feasible. The TX architecture is based on the encapsulation of untrusted functionality, such as that contained in an ordinary X server, using a relatively small amount of trusted applications code. The untrusted functionality is then polyinstantiated 1

This work is sponsored by the Defense Advanced Research Projects Agency under Contract No. MDA 972-89-C0029. Correspondence should be addressed to Ann Marmor-Squires, TRW Systems Division, Fairfax, VA. or by email to [email protected]. An earlier version of this paper was presented at the Seventh Annual Computer Security Applications Conference, San Antonio TX, December 1991.

Epstein, McHugh, Orman, Pascale, et al.

160

or replicated once for each active sensitivity level. This leads to a combination of high assurance and complex functionality while reducing the evaluation eort to a tractable level. The architecture of TX is described, and its information ow and visible labeling security policies are discussed. The trade-os that were made to maintain assurance while achieving other software engineering goals are considered. TX is compared with several other trusted windowing systems.2

1. Introduction

During the 1980s, relatively inexpensive computers with moderate to high resolution bitmap displays became widely available. This led to the development of a variety of user interface systems based on windowing paradigms. Researchers at MIT developed a workstation-based, platform independent, networked windowing system for such workstations: the X Window System3, commonly known as X. X rapidly became the windowing system of choice in the UNIX world. The widespread availability of X and other windowing systems has sparked interest in the use of windowing systems in multilevel secure environments. The availability of low and moderate assurance (B1 { B2) multilevel secure UNIX based workstations has provided a base for windowing systems of similar assurance levels and the impending advent of high assurance (B3) multilevel secure workstations, based on operating systems such as Trusted Mach has sparked an interest in a windowing system with comparable assurance. We chose to attempt a high assurance version of X which we call Trusted X or TX. There are many problems associated with building a trusted X Window System. The fundamental problem is that X has a very limited notion of protection. X is modeled around client/server interactions designed to encourage cooperation in an atmosphere of openness and mutual trust. It provides support for this cooperation via numerous direct and indirect communication mechanisms. The X protocol provides numerous examples of cases in which one client can ask to observe the actions of another. It also provides numerous ways in which clients are informed of the actions of other clients simply because of their sharing of resources such as displays, keyboards, etc. This cooperation and uncontrolled sharing is the antithesis of secure computing design. An extensive discussion of trust issues associated with X can be found in [Ep'91a]. Despite the diculties, we feel that the bene ts of a high assurance multilevel secure (MLS) windowing system are well worth the design eort required. Users doing interactive work with MLS data in a non-benign environment [NC'85a] have operating systems to support their work; they will expect and need state-of-the-art data presentation to accompany the environment. 2

3

Authors' current email addresses are: Epstein, [email protected]; McHugh, [email protected]; Orman, [email protected]; Pascale, [email protected]; Marmor-Squires, [email protected]; Martin, [email protected]. Branstad, [email protected]; Benson, [email protected]; Rothnie, [email protected]; Trademarks: X Window System is a trademark of the Massachusetts Institute of Technology. OSF/Motif is a trademark of the Open Software Foundation. UNIX is a registered trademark of X/Open. Macintosh is a registered trademark of Apple Computer, TMach and Trusted Mach are registered trademarks of Trusted Information Systems, Inc.

A High Assurance Window System Prototype

161

While our development is targeted at the TCSEC B3 level, we have not attempted to build a B3 certi able system per se, primarily due to the limited resources available to us. We focused on the dicult, high risk technical problems to demonstrate that the problem is solvable. We concentrated on designing an architecture that satis es the B3 structuring and minimization criteria, an architecture which we believe limits the potential for covert channels with minimal impact on X applications. We have investigated the security policy issues associated with trusted windowing applications but have not developed a formal security policy model. We have taken covert channels into account in making architectural decisions, but we have not performed a covert channel analysis. We have not satis ed some of B3 assurance requirements that would be needed for a product evaluation, such as con guration management and extensive security testing and documentation, but we see nothing in our approach that would preclude development of a B3 product based on our research. TX is a trusted application, not a complete computing system. As such, it depends on an operating system platform of B3 or better. We are using the TMach Operating System version 2.5 [Gr'90] prototype from Trusted Information Systems as our base. The security policy of a trusted application presents a number of interesting issues. In the case of a windowing system one of these involves the visible labeling of windows. We have conducted substantial research in this area and report our current thinking in this paper. In addition, we feel that we have developed an approach to the general issues of what must be trusted in a trusted application and are beginning to understand the composition of base and applications speci c security policies. We also feel that our architectural approach, based on the replication or polyinstantiation and encapsulation of untrusted functionality may permit the economical development of complex trusted applications. We invite the reader to consider the generalization of the windowing system example presented here to other problems of interest. The reader must understand X in order to understand our approach to securing it. The paper continues with an introduction to X followed by an overview of the TX architecture. The TX security policy is then introduced. This has two components, the rst extending the underlying policy of the TMach Operating System to cover the operations of the trusted components of TX, the other dealing with the visible labeling of windows on the TX display. With this background, the operations of the trusted and untrusted components of TX are presented. The paper concludes with a discussion of the architectural tradeos associated with our approach and a comparison with three other approaches to MLS windowing systems.

2. X Architecture

The X architecture is based on a client/server model of distributed computing. As shown in Figure 1, the X server manages the screen(s) and input devices. X clients are programs that interoperate with the server. They receive keyboard and pointer4 input from the X server, and perform operations on resources maintained by the X server. Drawing in a window is an example of such an operation. 4

The pointer is typically a mouse or a similar device.


162 Window Manager

Client #1

Client #2

Client #3

X Server • • • •

• • • •

Figure 1: X Architecture X clients and the X server communicate via the asynchronous X protocol [Sc'88]. Clients send requests to the server over a bi-directional communications channel using any reliable byte-stream protocol (for example, TCP/IP or DECnet), and they receive responses. The server also issues events as a side eect of performing requested operations or responding to keyboard and pointer input. Protocol requests include administrative requests, requests to create and destroy resources, and drawing requests. The X server does not guarantee that responses are returned to the requesting client; clients may intercept and monitor requests from other clients. Clients may register to receive events associated with their requests and resources as well as those associated with other clients' requests and resources. Client requests must identify the resource to be operated upon and the operation to be performed along with other parameters. Some resources, such as the search path for fonts and the keyboard and pointer characteristics, are global to the server. Other resources are local to the clients that create them. Global resources have well known names and can be accessed and modi ed by all clients. Local resources are given names by the client that creates them5 but may be accessed and modi ed by any client able to name them. X has no concept of privilege and a minimal notion of protection. Protection is provided at connection time only. The X server maintains a host access list that identi es those computers from which connections will be accepted. An optional authentication mechanism allows the server to demand some form of authentication 5

These names are typically composed from the connection identity to avoid name con icts.


163

from the client like an MIT magic cookie or a Kerberos [St'88] authentication ticket. Once connected, a client may request any server function, including the disabling of authentication for clients that attempt to connect in the future. Clients can directly impact other clients, for example, by killing their connection to the server. Such behavior is considered undesirable and conventions have been established for \well behaved" clients[MI'89]. The most important X resource, and the most complicated, is the window. Windows have abstract properties that are maintained by the server, and most windows also have a visual representation on a display. The manner in which a window is displayed is typically determined by the window manager. The window manager is an ordinary X client without special privileges, and is distinguished by being the rst to register for certain events associated with the \root" or background window of a display. There are many examples of window managers, each of which provides a dierent look-and-feel, varying in window border styles, window layout, menu style, etc. The conventions described in the X Inter-Client Communication Conventions Manual [MI'89] are used to de ne a set of conventions that allow compliant clients to interact cooperatively.

3. TX Architecture This section begins with a high-level view of the TX architecture, introducing each of the trusted and untrusted components of the system. Next, we describe the size and internal structure of each component. The remainder of the section describes the facilities provided by each component and the component interactions.

3.1. System Overview

TX consists of a collection of trusted and untrusted components. The design philosophy is based on the replication of single level X servers and their encapsulation in a way that allows single level (untrusted) clients to interact freely with clients at their own sensitivity level and securely (albeit in a limited fashion) with clients at other sensitivity levels. The design permits secure sharing of the X display and of the keyboard and pointer input devices. Polyinstantiation of untrusted single level X servers, once for each sensitivity level at which a client is using or seeking to use X, is the basic architectural concept of the TX system. The single level servers are slightly modi ed X servers. Security relevant modi cations were made primarily to coordinate the server's access to the input and display hardware, with these functions becoming part of the Trusted Computing Base or TCB. Additional modi cations were made to replace the UNIX socket code with Mach port code. The TX TCB provides the means for ensuring correct multilevel secure operation of TX. The TCB is comprised of four sets of trusted processes that mediate client access to TX and control multilevel interactions among clients. The modular structure of the TCB and the specialized functionality assigned to each module simpli es analysis of the modules and strengthens the assurance arguments providing an example of good software engineering contributing to security. - Input control and trusted path functions. This functionality is provided by three trusted modules. The Input Manager (IM) distributes keyboard and


164

Client Initiator

T X / M a s t e r

TCB

Server boundary

Selection Emulator

Window Manager

Other Clients

AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA

Task creation Message flow

Single Level Server

Server Initiator

Display Manager

Trusted Shell

AAAA AAAA AAAA

Legend : Untrusted

Property Escalator

Input Manager

Mini Server

Figure 2: TX Overall Architecture pointer inputs and coordinates activities of the trusted Mini Server (MS) and the Trusted SHell (TSH) which provide the user with operational control of TX. - Display management and window labeling functionality. The Display Manager (DM) composes the physical display from the virtual displays of the single level servers and adds the necessary visible labels to top level windows. - Initiation of the task set for each sensitivity level. The single level servers and their associated supporting clients are started by two trusted modules; the Server Initiator (SIT) for starting the servers and the Client Initiator (CIT) for the clients. - Multi-level information sharing functionality. The Property Escalator (PE) supports \cut and paste" operations among single-level clients. All accesses to shared or multilevel resources by the single-level X servers (SLS) are mediated or limited by these modules. The resources required by each trusted component, such as screen font representations, are part of the TCB and are subject to scrutiny and review by evaluators. Each trusted subject has its own internal security policy that is consistent with the TMach Operating System access control policy. The security policies of the MS and TSH are quite minimal, because they do not interact with untrusted clients, however their functional correctness is important to ensure the integrity of


165

TX operation. This accounts for the eort put into minimizing their functionality. The DM, IM, SIT, and CIT all interact with untrusted clients, but their interactions are such that the information does not ow between dierent levels giving each of them an isolation policy. The PE allows information to ow upward through the lattice of sensitivity levels and its security policy is consistent the TMach Operating System policy. Figure 2 shows the TX subjects and their interactions. Each instance of an untrusted X server or SLS is supported by two additional untrusted clients: the selection emulator (SE), and the window manager (WM). An untrusted X client interacting with other untrusted X clients at its sensitivity level sees the full X functionality and is unaware of the existence of clients at other sensitivity levels.

3.2. TCB Modularization and Minimization

One of the key diculties in building a high assurance X is to modularize and minimize the TCB to conform to the architectural requirements of for B3 evaluation under the TCSEC[NC'85]. The TX implementation addresses this requirement through the creation of a small number of trusted modules, each with limited functionality and a speci c role in supporting the system operation. Modularization of the TX TCB takes two forms; at the architectural level, the system is divided into multiple servers based on function, while at the implementation level each server is written as a series of largely independent modules that communicate through well-de ned interfaces. The TX trusted subjects are trusted in a limited sense. Each may have limited interactions with several untrusted clients and must be shown not to pass information among them in unacceptable ways. TX trusted subjects do not have unlimited access to the TMach Operating System resources and cannot, for example, open arbitrary les, manipulate the memory management, etc. While the MIT provided code has withstood \testing through widespread use", this manner of testing is far from meeting any formal assurance test. Design documents do not exist, and the X code is far too large (roughly a 100,000 lines of C code (LOCC) in the server alone) to meet B3 minimization requirements. In contrast, the prototype contains about 30K LOCC (or 8K statements) in its TCB. This size compares favorably with other B3/A1 TCBs: the SCOMP TCB with about 21K statements[Fr'91]; the XTS 200 TCB (SCOMP's successor) with about 20K statements[Bo'91]; and the TMach Operating System TCB with about 100K (preliminary estimate) statements[Tj'91]. Comparable numbers for the GEMSOS TCB were unavailable[Br'91]. The individual trusted subjects range from a few hundred to a few thousand LOCC. The encapsulation and limited roles should make their evaluation less dif cult than comparable portions of an operating system kernel. Table 1 shows approximate LOCC for each of the subjects in the prototype.6 In addition, a library of common functions used by all tasks consists of approximately 6

These numbers are somewhat higher than in [Ep'91] because they include support for the Sun 3 workstation and Intel 486 platforms, including both black and white and color versions, while the earlier counts were for the Sun 3 black and white workstation version only.


166 Subject

Trusted?

LOCC

Stmts

Master Input Manager Display Manager Mini Server Trusted Shell Server Initiator Client Initiator Property Escalator

Yes Yes Yes Yes Yes Yes Yes Yes

550 2,400 9,700 2,300 3,000 600 200 300

150 600 2,500 400 1,050 150 50 50

Single Level Server Selection Emulator Window Manager

No No No

103,000 1,200 58,000

39,700 400 11,000

Table 1: Lines of C Code for TX Subjects 9300 LOCC (2500 statements). The total LOCC for trusted components (including the library) is approximately 30K (8K statements), while the untrusted portion of the system contains approximately 414K LOCC (or 130K statements).7

3.3. The TX Master

The Master task synchronizes the initialization of the TCB components. Once all the TX components are initialized and synchronized, the Master does not take an active part in its operation. The Master does not communicate with untrusted subjects.

3.4. The Input Manager

The Input Manager (IM) routes keyboard and pointer input, checks for the secure attention key (SAK) sequence, and waits for inactivity timeouts. It also provides information about the input hardware con guration; this information is bound at TX initialization time and not subsequently changed. When the user selects an input destination, i.e. a SLS, the MS, or none, the Input Manager is responsible for routing subsequent input to that destination and only to that destination. The SAK sequence initiates trusted path operation in which the user is assured that input is going directly to a trusted subject, in this case, the TSH. X input data are low-level operations representing key press and release events, pointer motions, etc. The SAK sequence is not necessarily a single key press event, but may represent a combination of events that the IM looks for. When the SAK is detected, the input buers are ushed, and the current server is set to be the MS, which then receives all subsequent input. If the IM does not detect any keyboard or pointer activity for a (con gurable) period of time, it sets the current server to none, even if the server is the MS. In this mode, all inputs except the SAK are discarded. This allows implementation of a screen lock facility (described in section 5.6). Once locked, the screen can only be unlocked through the trusted path. The current server is also set to none if the current server dies. Otherwise, the IM changes its current server only when instructed to do so by the MS. 7

Including 252K LOCC (78K statements) in common libraries shared by all clients.


167

The IM noti es a SLS when it becomes the current server and when it loses this status. This noti cation allows the SLS to inform the window manager (or any other client), which might take actions such as raising all windows to the top on activation, or clearing its focus indicator on deactivation. This is an operational consideration; although it introduces some information ow from the TCB to an untrusted subject, the information is not \new"; the SLS could with high probability determine that the user was working at a dierent level simply by noting that it was not receiving any input event noti cations. Because TX provides a graphical interface, it might appear logical to use a pointer click on an icon (rather than a typed combination of keys) for the SAK. In the present architecture, the physical cursor position on the screen is not known by the IM because each SLS is free to set the cursor position as it sees t, and thus the IM would is unable to determine when the cursor is pointing to an icon. Also, because the cursor position is interpreted by untrusted code, the cursor could be constrained to remain in the same place, despite pointer movement initiated by the user, resulting in a denial of service.

3.5. The Display Manager

The Display Manager (DM) controls the physical display and maintains the image of the screen from each active security level. The DM does not interpret the contents of the windows; it is only responsible for the placement, labeling, and physical display commands. The DM is trusted to construct the visible label for the window and to include the label on the four sides of the window. Several attributes of the windows are used to compose a screen image: the window sensitivity level, the window size and location, the \stacking order" of the window with respect to other windows that intersect it, and whether or not the window's owner has indicated that it should be displayed on the screen. The DM composes a complete screen image from the pieces that are provided by the individual SLSs and the MS. It is also responsible for ensuring that the individual windows on the display have proper visible labels. To maintain X functionality, the DM provides a special service, the drawing of \helping lines" to assist users in placing windows.8 The DM maintains general hardware and con guration information that can be queried by any SLS. This information is bound at TX initialization time and cannot be changed thereafter. As is the case with the IM, the DM supports a notion of a currently active server, which is none, a SLS, or the MS. The current server is set by the MS. The display is divided into two regions, one for the exclusive use of the MS, the other for use by all servers, including the MS. The MS reserved area is used for interactions with TSH and for displaying status information: for example, the visible labels for the current operating level and the high water mark level. The con guration information supplied to the SLSs does not include the MS reserved area and their virtual screens do not include it. Within the DM, certain artifacts of the display state are polyinstantiated and maintained on a per level basis. They include a list of installed colormaps; the position, image, and color of the cursor; the positions, sizes, and stacking order of 8

This task is usually handled by window managers.

168


top level windows; the size and location of the \helping lines"; and the individual full-screen images. Each SLS has two ports for sending messages to the DM. The \nonhold" port is used by the SLS to update the contents of currently mapped (i.e., displayed on the screen unless completely obscured by another window) top level windows and to query the hardware con guration (which is read-only). To update window contents, the SLS provides a replacement screen image, which the DM clips using the boundaries of the given window and any overlapping windows. The \hold" port is used to map and unmap windows, change their stacking order, update the cursor position and image, draw \helping lines", and perform various other administrative functions. Internally, DM identi es windows by both their SLS provided window ID and the identity of the SLS that owns them. Each SLS can only refer to windows that it owns. All requests from all nonhold ports are processed by the DM as they are received. Requests from the hold ports are handled only when they are from the current server. The distinction between the hold and nonhold ports is to prevent another SLS from interfering with the current server by mapping windows arbitrarily. As is the case with input noti cation, this is mostly an issue of functionality rather than security and is a partial solution to potential problems that could arise because single level window managers are not aware of windows at other levels. The MS can update the contents of the \reserved area" by providing a replacement image, just as SLSs provide replacement images for windows. When the current server changes, the DM installs the colormap(s) belonging to the newly chosen server and displays the server's last cursor image in the proper position. Polyinstantiation of cursor position and colormap values allows complete

exibility in colormap and cursor handling without the insecurities that would result from attempting to share these resources across levels. The DM also brings up the last set of helping lines (if any) provided by the server. The DM visibly labels each mapped window using a visible representation of the sensitivity level of the SLS that owns the window. The labels appear on all four sides of the window and are outside any window manager decorations. They are controlled entirely by the DM and are not accessible by any SLS. Adding visible labels is the only graphics operation performed by the DM other than copying virtual window contents to the real frame buer and drawing helping lines. Many window managers assist users in placing windows on the screen by drawing rectangular boxes called \helping lines" directly on the screen background. Unfortunately, there is no way for the X server to distinguish between a window manager drawing helping lines and a client performing arbitrary drawing on the screen background. We extended the X protocol to provide an explicit request for the drawing of helping lines. A SLS passes this request to the DM through its hold port. The DM only allows one set of helping lines on the screen at any time, namely those belonging to the current server. Each request by a server to draw helping lines cancels any previous request. We do not consider helping lines to be information requiring a visible label. Note that helping lines cannot be detected by clients or SLSs, so no insecurity is introduced. The DM is the largest and most complex component of the TX TCB. The majority of the code in this component handles window overlapping and display-


169

ing the resulting multilevel screen. This portion could be implemented in a high assurance hardware facility that could increase both performance and assurance.

3.6. The Mini-Server

Trusted path functions must be supported by small modules for B3 assurance, and the Display Manager is far from the minimum needed to support the simple window functions needed in TX. The Mini-Server (MS) ful lls the display and input functions for trusted path in TX. It coordinates the activities of most of the TCB: the IM, DM, SIT, and TSH. It also performs limited drawing on the screen (using the same graphics facilities as the DM) to update the trusted path area. Based on its interactions with the TSH, the MS directs the IM and DM to set the current server and thus the current operating level. The MS updates the reserved area of the screen to re ect the input level change. Also, it noti es the SIT to start new single level servers as needed. Ordinary X systems allow use of arbitrary fonts and have primitives for drawing lines, rectangles, polygons, circles, and other shapes using a variety of dierent styles (e.g., line width, mitering algorithms). In contrast, the MS provides primitives for the TSH to clear an area, draw vertical and horizontal lines, and draw text using a xed width font. These restrictions allow the size of the MS drawing code to be orders of magnitude smaller than that of an X server. The MS draws in a virtual frame buer, which is sent to the DM for actual display either in the reserved area or on the general screen. MS also handles input in a very restricted fashion. Cursor movement is tracked internally, and the cursor position is passed to the TSH only when a pointer button is pressed or released. Key press and release events are converted into text strings before transmission to the TSH.

3.7. The Trusted Shell

The TX Trusted Shell (TSH) provides the user with an interface for performing the administrative and security functions necessary for the operation of TX. These functions are: - creating a new Single Level Server, - selecting the current operating level, - displaying the sensitivity level of a window on the screen, - locking the screen (so users can safely leave an active session), - unlocking the screen after a manual or automatic lock, - changing the user's password,9 - exiting TX. The TSH is a minimal implementation of the graphics support needed for a simple trusted shell interface: it uses only the drawing primitives provided by the MS, and its user interface is based on a simple menu displayed in the reserved area of the screen. All of its functions, except verifying the sensitivity label of a screen region, could be provided through a less complex use of the screen hardware, speci cally by using the screen as if it were a \dumb tty". However, our visible label 9

This function is provided so the user need not exit TX and use the TMach Operating System TSH. It adds about 100 LOCC (50 statements) to the TCB.

170


policy requires the system to provide facilities for obtaining the sensitivity level of a displayed window through trusted path interactions. This requirement means that the implementation must include the facility to address the screen through its bitmap interface and the provision of a trusted shell with minimal graphic facilities requires relatively little additional code.

3.8. The Server Initiator

The Server Initiator (SIT) performs two main tasks: creating SLSs and connecting clients to the appropriate SLS. The SIT starts a SLS at the request of the MS or when a client requests a connection to TX at a sensitivity level for which no SLS exists. This avoids a need for precon guration. When the SIT creates a new SLS, it also requests the CIT to create a new window manager and selection emulator at the sensitivity level of the new SLS. The SIT also connects untrusted clients to the correct SLS. It would be preferable for each SLS to make itself known to the TMach Operating System name server and for clients to connect to the appropriate SLS through the TMach Operating System. In the TMach Operating System prototype on which TX is based, the Name Server will not support this mode of operation. While it would be possible to compose unique server names based on the sensitivity of the server, this would require substantial client modi cations to ensure that the client asked for the correct server10 . To avoid this, the SIT registers as the point of contact for all TX connection requests. When clients ask to connect, the SIT forwards the request to the appropriate SLS, starting a new one if necessary. Once the connection is established between the client and the SLS, the SIT is no longer involved, and the TX client converses directly with its SLS.

3.9. Client Initiator

The Client Initiator (CIT) starts window managers and selection emulators as requested by the SIT. The CIT and SIT could be folded into one task. They are separated to maintain the distinction between clients (managed by the CIT) and servers (managed by the SIT). This distinction would allow the CIT and clients to run on a dierent machine from the server tasks, which are usually on the same machine as the physical display and input hardware.

3.10. The Property Escalator and Selection Emulator

The ability to transfer information from one window to another is the de ning characteristic of modern windowing systems. We expended extra eort to include multilevel secure functionality to support this in TX. For simplicity we call the function \cut and paste", although it is much more general than the name would imply. The central module in support of this function is the trusted module called the Property Escalator. TX supports multilevel cut and paste in accordance with the ICCCM \selection" protocol, which lets clients exchange information using the server as an intermediary. The X protocol requests that support this form of cut and paste involve bidirectional communications between the cutting and pasting clients. These 10

Asking for the wrong server would result in a denial of access but would not cause a security problem.


171

have the potential for substantial information ows that would be counter to the security policies of TX and Trusted Mach. Our solution to this problem involves a combination of a trusted module called the Property Escalator (PE) and untrusted X clients, one per SLS, called Selection Emulators (SEs). In ordinary X, a client performing a \cut" operation asserts ownership of a resource known as the \selection." A client wishing to perform a \paste" operation can determine the ownership of the selection and negotiate with the owner for a mutually acceptable data format for the exchange. While it is permissable to transfer information cut by a client at one sensitivity level to another at a dominating level, the negotiation process cannot be secured. We avoid the negotiation process, but at a price, by using the PE as a repository for cut information. The untrusted SE acts as an intermediary in the process. The system works as follows: The SE asserts ownership of the selection so that it will be noti ed when another client of the SLS performs a \cut" operation. When the cutting client asserts ownership of the selection, taking it away from the SE, the SE asks for the cut data in all supported formats and sends it to the PE. The SE then reasserts ownership of the selection. When a client wishes to \paste," it will discover that the selection is owned by the SE associated with its SLS and will negotiate with the SE for the data to be pasted. The SE will obtain the data from the PE and transfer it to the pasting client. When the PE receives data from a SE, it stores it in a multilevel store, tagged with its sensitivity level and the time at which it was received. When the PE receives a request for data, it responds with the most recently cut data that has a sensitivity level that is dominated by the sensitivity level of the of requester. The SE that sent the data is not informed, nor can it discern, when the data has been requested. This eliminates a covert channel, but it imposes a limitation on X functionality. Normally, the X client supplying the data has an opportunity to convert the data to the format that the requesting client speci es. Formats are uninterpreted names whose meaning is determined only by convention or by mutual agreement among clients. In our implementation, most possible format conversions11 are made prior to storing the data in the PE in order to maximize the chance of having the appropriate format for the pasting client. Note that there is an instance of SE running for each SLS. A cut and paste operation involves two SEs: one at the sensitivity level of the cutting client, and one at the sensitivity level of the pasting client. Through this mechanism, compatibility with the ICCCM is maintained without covert channels or loss of exibility. The price paid is lower performance, as we use \eager" evaluation, (i.e., the opposite of \lazy" evaluation). Should the overhead of conversions become excessive, compromises are possible. Multilevel cut and paste can be restricted to only a few formats with the 11

We say \most" conversions formats because we must know the names and eects of the format conversions at system con guration time. We do not handle the \delete" format, for example, because this format always removes the selection from the screen.

172


lazy conversion rule. While the selection based ICCCM protocol is recommended for new applications, older X clients may use \cut buers," \clipboards," or other communications mechanisms. Within a single sensitivity level, these mechanisms may be used, but they are not supported across levels. We suspect that some or all of these mechanisms could be supported, at a price, given sucient need.

3.11. Single Level Servers

The untrusted Single Level Servers (SLSs) are modi ed versions of the MIT X server. Whenever possible, we have avoided modifying the MIT source code in the hope of preserving the \correctness" of X and maintaining compatibility between TX and X. Our changes involve device initialization code, code that directly interacts with input and output devices, UNIX operating system dependent code (where we replaced UNIX socket dependencies with the TMach Operating System message and port dependencies), and disabling the code that changes global settings such as the keyboard mapping. Because the SLS does not have control of the physical input and output devices, device initialization code is not necessary, and these functions have been transferred to the IM and DM. The SLS receives its input from the IM via a TMach Operating System port. Making the SLS device access virtual has minimal impact on the X server. For output, the SLS allocates a virtual frame buer of the same size as the physical frame buer (without the reserved area, which is unknown to the SLS). All drawing is performed using this virtual frame buer, which is then sent to DM through the TMach Operating System interprocess communication mechanism. Mach and the TMach Operating System can send messages using an option that invokes a virtual memory operation known as \copy-on-write", and this option is used by TX to avoid the physical copy operation. This way, the SLS and DM share the same frame buer, except when it is being updated by the SLS. Sharing the buer minimizes the additional memory required and avoids the overhead of unnecessary copying. Window mapping and unmapping requests result in messages to the DM to either place a window on the display or to remove it from the display. Rather than adding \move window" and \resize window" primitives to DM, the SLS unmaps a window and remaps it in its new size and position. Cursor and colormap changes are similarly modi ed to send messages to the DM. Note that the SLS is unaware of labels placed on windows by DM. All demultiplexing of input events (such as keystrokes or pointer events) to clients is performed by the SLS. A feature of X is that it allows software control of the interpretation of the keyboard. The interpretation is called the key mapping. Each SLS could map the keyboard dierently. For example, the secret SLS could use a QWERTY keyboard mapping, while the con dential SLS could use a Dvorak keyboard mapping. This is a side-eect of the polyinstantiation of the SLSs that may appear at rst to be a aw in the system: why would one want to have dierent keyboard mappings for dierent sensitivity levels? Consider, however, a system that provides specialized function keys, some of which may only apply to interactions with data at one sensitivity level. Under TX, these keys would automatically be mapped appropriately to the sensitivity level of the interaction window because each SLS performs its own mapping from the physical keys to the


173

logical values. We feel that any bene t of allowing this exibility is outweighed by potential problems for the user. Thus, our SLS ignores requests to remap the keyboard (along with certain other administrative requests) not as part of our security policy, but simply to avoid confusion. Remember, despite the interpretation of the keyboard events by the untrusted SLS, the IM is always scanning for the same two physical keys - not characters - that invoke trusted path.

3.12. Window Managers

The window manager is an X client that sets a style for the user interactions and the screen appearance. In TX, there can be a window manager controlling the windows at each sensitivity level. Several window managers are available for use with X, and a goal of the TX design is to support them all. Any X window manager can be easily modi ed to be a TX window manager (WM). The only change required is in the drawing of \helping lines" to assist the user in placing windows on the screen. For the reasons discussed above, this must be done via the X protocol helping-lines extension. An implication of having a separate window manager for each sensitivity level is that a secret window manager could not be used to move a con dential window, as the secret WM would not have any knowledge of the con dential window. An interesting side eect of this architecture is that dierent window managers can be used at dierent sensitivity levels, although the probable user confusion resulting from the attempt of each window manger to impose its own style on the entire screen makes this undesirable. The prototype supports three window managers: mwm (the OSF/Motif window manager), olwm (the OPEN LOOK window manager), and twm (the MIT provided window manager).

4. TX Policy: Security and Visible Labels In developing our architecture for TX we had several goals dictated by concerns for both B3 certi able security and acceptable X functionality and performance. From the standpoint of secure functionality, the primary requirements of TX are that that users can run untrusted applications without violating the TMach Operating System security policy and that data labels are displayed correctly in an unspoofable fashion. The former is simply an extension of the B3 requirements to a trusted application, the latter is our extension of the B3 requirements for labeling human readable output to a multilevel display device. With the exception of the functionality required to assure correct labeling and trusted path interactions, we make no claims about the veracity of data displayed by clients.

4.1. TX Security Policy

As seen by its clients, the TX security policy is a slightly weakened separation policy based on the subject security level information that the TMach Operating System uses for mandatory access control. In practice, this policy means that clients at dierent sensitivity levels cannot engage in the arbitrary sharing of X resources normally allowed within an X server. The one exception to this isolation allows a client to \paste" information that has been \cut" by a client whose sensitivity level is dominated by that of the pasting client.

174


The separation policy provides a clean way of dealing with the complex internal state maintained by an X server. The polyinstantiation of single level servers allows the X server's internal state to be instantiated once for each active sensitivity level. Each client accesses the state information of the server at its sensitivity level via the operating system's interprocess communication mechanism, the sending of messages through Mach ports. Once the TX servers and clients are instantiated with appropriate MAC labels, all other mediation outside the TX trusted computing base relies on the port mediation performed by the TMach Operating System TCB. Under the TMach 2.5 Operating System, a Mach port always has a single security level. Subjects are labeled processes (or groups of processes having identical security characteristics, including the associated user and group identi ers) that operate over a security level range bounded by two values called alter min and view max. For untrusted subjects, the two bounds are the same. For trusted subjects, view max dominates alter min. This allows the trusted subject to send and receive messages across a range of levels. Under the TMach Operating System, port rights are transferred between tasks as a side eect of the interprocess communication mechanism. Rights correspond generally to read-and-write and write (append) permissions. The transfer of rights is mediated in accordance with the level of the task receiving the right. The trusted subjects of TX can operate across a range of levels, however, they cannot propagate port rights in violation to the Trusted Mach policy described above. The Trusted Mach de nition of a trusted subject creates the potential for the routing of information in ways that violates the intent of its security policy. For example, a trusted subject with a view max of secret and an alter min of unclassi ed could receive arbitrary secret messages over a secret port and rebroadcast their contents over an unclassi ed port. A trusted subject that behaved in this fashion would be considered ill behaved, untrustworthy and should not be a part of the system. The trusted components of TX have individual policies that state, in eect, that they are well behaved. The SIT and CIT policies require them perform actions that are only visible to TX trusted components and to untrusted clients at the level of the connection request being processed. The DM policy does not allow it to pass information obtained from one SLS to another at a dierent level and requires the DM to label the display appropriately. The IM policy requires it to treat the input stream as being classi ed at the current input level and to pass it to the client at that level, to the TSH, or to discard it as appropriate. The MS and TSH policies require accurate delivery of their speci ed functionality. The PE is the only component that is responsible for moving information between untrusted clients. It has a Bell-LaPadulla style policy based on receiving information from SEs supporting \cut" operations and sending it to SEs supporting \paste" operations. Its policy can be stated as: \Information received through a port at a given

sensitivity level can only be transmitted through a port with a dominating level."

The PE acts as a simple MLS database module. Information can be sent to the module by the SE supporting a given SLS. The PE labels the information with the sensitivity level of the sender. It is then timestamped and associated with a lookup key provided by the sender. Subsequently it can be retrieved by an SE supporting another (or the same) SLS with a dominating sensitivity level. There


175

is no interaction between resources managed by this module and the resources managed by the SLSs, which contributes to its simplicity. Because there can be multiple instances of data associated with a lookup key, it is legitimate to return any or all instances dominated by the requester's level. Our implementation returns the one with the most recent timestamp. The TMach Operating System has a discretionary access control (DAC) policy based on user and group identity that applies to the acquisition of port rights. TX uses the DAC available in the native operating system to control access to the workstation display and the polyinstantiated servers. The result is that only one authorized user at a time can start a session with the workstation display, and only that user can run client programs that modify the display. TX does not extend DAC to the X resource level. We made this design decision for two reasons. One reason is that for DAC to be meaningful at this level implies that X client applications with dierent user identi cations share one workstation screen in ways that require the clients to protect themselves from one another. While this idea is attractive for teaching purposes, it falls outside the expected uses of most secure workstations. The second reason for omitting DAC is that while we found only one speci c class of information that had to be shared across MAC levels, there was no such limitation apparent for DAC. The practical implication was that the X server would have to be completely rewritten to manage DAC labels and perform mediation on all resources and operations. This is a complex task from which we saw little bene t. The rules for assigning sensitivity levels to the entities managed by TX are straightforward. At any given time, user input from the keyboard and pointer has a single security level, and its label is clearly displayed at all times. Window sensitivity labels on the display are inherited from the task that created the window. These tasks are started by a trusted program that enforces the TMach Operating System policy with respect to user's authorizations.

4.2. TX Visible Label Policy

The foremost consideration for the visible labeling policy is that the labels must be easily readable and clearly associated with the window contents. It is also preferable for the visible labeling mechanism to be \spoof-free". Another consideration is to allow enough exibility in the implementation of the policy to preserve the \lookand-feel" of the X Window System. These requirements are very general and permit broad interpretations. We learned quickly that there is no universally acceptable solution. We chose a visible labeling policy with the intent of balancing utility with assurance[Ep'90]. Precise characterization of a visible label policy is dicult because there are human interface issues concerning visual perception that impact the policy. We have chosen the following policy elements: - Every screen pixel has an associated sensitivity level that can be easily computed by the TCB. This internal value correlates to a unique text representation (e.g., Secret). - All text representations of labels (from now on referred to as \textual labels") are written in a standard font using standard foreground and background colors.

176


- Displayed windows must be visually marked with their respective textual labels. The labels are treated as part of the window for purposes of determining window overlap and other visual interactions. - The current input level must be visually depicted at all times. - Windows must have the textual label displayed on all four sides. - There is an algorithm for computing the label of any pixel on the screen, given only the array of displayed screen pixels as input. This is the \non-spoof" property, and it is not entirely met by the implementation, as explained below. - [Optional] spoof protection: the grey pattern. An alternative to the previous item is to allow some window contents to be indeterminate. In formal terms, this means that the previous item de nes \spoofable" pixels, and we we require that the contents of window with any such pixel be a uniform grey pattern. Thus, the contents are visually indeterminate as well. The prototype does not implement this optional policy item. - The user may request veri cation of the label of any screen region contained within a window. The predominant feature of our solution to satisfying these requirements is that we allow windows with incompatible security labels to be displayed simultaneously on the screen, with overlap. This solution allows the workstation user a great deal of latitude in how to arrange the display. On the other hand, it allows window con gurations that may confuse the user about the true label of a window's contents. Operationally, the user has control over the window placement. We provide an unambiguous way to validate the label of any screen section. The labels are there to assist the user; and the user can keep the placement simple (no overlapping) on a window-by-window basis or can overlap them as desired. Because the visible label policy is for the convenience of the user, we chose not to interpret it as strictly as the MAC policy, and we have left open the possibility of spoofs and confusing window layouts. A spoof can be easily created by having a high-level window display the image of a low-level window, complete with textual labels. This display might mislead a viewer into believing that the contents of the window had been labeled at \system low", for example, and the viewer might then disclose the contents to a system low subject. It is important to note the computer system itself would not mishandle the data, because the internal labels would be correctly mediated. A constructive proof demonstrating all spoo ng con gurations that arise from implementing the policy would be highly desirable, but we have not devised one. We do know that implementing the optional policy item regarding grey patterns considerably restricts the number of spoofs, at a great computational cost. Even in that case we know of one spoof: a high level window displays a spoof of a low-level window surrounded by a grey pattern. Formally, this spoof can be prevented by disallowing placement of a low label window within the con nes of a high label window. Practically, it raises questions about how much geometric computation the user has to do in order to non-interactively determine labels. Even if we were able to further restrict the implementation and could prove that no window con guration had an interpretation in which high-level data seemed to be part of a low-level window, there is still the question of whether the user could


177

or would nd the correct mathematical interpretation of the layout. This question is what makes the selected policy a compromise. There is enough exibility to use the display to view multilevel data in a large variety of ways; if the windows have a high degree of overlap, there is no guarantee of mathematical or practical disambiguation without user intervention. On the other hand, the implementation of the labeling policy was done in such a way as to provide high assurance that the labels were always displayed in accordance with the selected mechanism. We have been working towards a formalization of the visible labeling policy and an analysis of the cost of display restrictions that would reduce or eliminate the possibility of spoo ng. Our results to date are as follows: There is a partial ordering on windows, maintained by the X server. This is the stacking order. The stacking order (which includes the window dimensions and locations) and the screen dimensions determine the screen representation. Given a stacking order and a screen, it is possible to determine the label of every point on the screen. There is a mapping of the stacking order to the screen, resulting in a set of rectangular regions and a collection of line segments that are subsegments of the window borders. This is the screen representation. We assume that if a line segment is a window border, we can determine its security label, and that rectangular window regions can be distinguished from the root window background, which is implicitly labeled \system low." We assume that any given screen representation is the image of a stacking order S . We assert that a screen representation of a stacking order S can be mapped to a set of stacking orders that includes S . Label determinism property: if all mappings of the screen representation to stacking orders result in the same label for every screen point, then we say the screen is label deterministic. Not all stacking orders result in label deterministic screen representations. One solution to this problem is to visually distinguish screen areas that cannot be mapped to a consistent security label. These areas could be, for example, a uniform grey color or pattern, with no other features displayed. This is a safe con guration, because the window contents cannot be associated with the wrong security label. There are a priori restrictions on the stacking order that guarantee a label deterministic screen representation. Schemes that do not allow window overlap, for example, satisfy this. Our design goal was to investigate possibilities for general layout schemes, and we widened the avenues of investigation by trading computational cost for exibility in placing windows. Finding the indeterminate regions in the general case requires building the screen representation and then nding the reverse mapping to a set of stacking orders. The computational cost of this is quite high, and it may be as bad as exponential in complexity. This suggests the idea of imposing restrictions on the stacking order or the layout in order to reduce the cost. Possible minimalist restrictions include requiring that at least one corner of every partially displayed window be part of the screen representation, or that low-level windows not obscure highlevel windows. A proof that either restriction leads to a subexponential algorithm for proving label determinism would be a welcome outcome, but our investigations did not reveal one.

178


If we consider line segments contained within windows to be part of the set used to map from the screen representation to the set of stacking orders, then we can address the problem of spoo ng. A spoof occurs when a line segment that is not a window border in the original stacking order S can be mapped to a window border in some other stacking order T . In that case, regions adjacent to the line segment might be identi ed as being labeled with the visual label of the false line segment. Unless windows borders can be reliably distinguished from window contents by, for example, unique coloring or blinking, the problem of preventing spoofs is dicult. We looked for minimal restrictions on the stacking orders or screen displays that would prevent spoofs. One possibility is to disallow the placement of a window entirely within the con nes of another. We did not prove that this prevents spoofs, but we did investigate the computational complexity that would be introduced in implementing the restriction. This is no worse than nlogn.

5. TX Operation

The user interacts directly with TX in a variety of ways that require him to interact explicitly with its security features. - Startup, Login, etc. - Starting a new security level. - Trusted path. - Screen lock. In addition, the TX TCB will mediate interactions between the user and the single level X clients that the user is using. - Starting clients. - Window operations. - Cut and Paste. This discussion of TX operations that follows demonstrates how the architecture functions and achieves its trust and assurance goals during each of the scenarios. We rely heavily on the TMach Operating System for the establishment and control of communications paths among the trusted and untrusted subjects that make up TX. A fundamental aspect of TX operation is that there is a current operating level that is de ned by the user and there is at most one \current server." In normal operation, this server is the SLS that is running at the current operating level. Only this server can change the display status of windows (by \map" and \unmap" operations), and it is the only server that receives input. Any SLS can update windows that it has mapped, no matter what the currently selected server is. When no SLS has control of the system (i.e., trusted path is invoked, the system is locked, or the active SLS has crashed), no input crosses the TCB boundary, and the operating level is unde ned.

5.1. TX Startup

The user invokes TX from the TMach Operating System Trusted Shell. This invocation starts the trusted TX Master; the user will see the basic TX screen layout and will be able to interact with the trusted shell.


179

The Master starts all of the trusted tasks (IM, DM, CIT, SIT, PE, MS, and TSH). Initially, the IM and DM have no current operating level because they have no SLS with which to communicate. Any input is discarded by the IM. The DM is inactive because there are no hold or nonhold ports to read yet (i.e., there are no windows). When the TSH starts, it requests the MS to display the current operating level (which is none) in the reserved area. When initialization is complete, the internal communications paths shown in gure 2 have been established by giving the trusted tasks the appropriate rights to use TMach Operating System ports. Because further propagation of these rights is controlled, this pattern of communication cannot be changed by the tasks holding the rights. The SIT registers its connection request port with the TMach Operating System name server. Thereafter, the SIT receives requests for connections to TX which are forwarded from the name server. The SIT passes these requests on to the appropriate SLS, starting the SLS, as discussed in the next section, if necessary. Connection establishment involves the propagation of port rights. The client seeking to connect to TX includes the send rights to the port that it wishes TX to reply to in its request. The SLS, will include send rights for the port that the client is to use for making X protocol requests in its connection acknowledgement. These transfers of port rights are mediated by Trusted Mach and the SIT cannot establish a two way connection between clients at dierent levels.

5.2. Single Level Server Startup

As the session progresses, the user might make requests to run applications at security levels other than the initial level. New levels are instantiated for the user by creating a SLS with running at the appropriate sensitivity level. SLSs are normally started by the user through the TSH. However, if a client requests services at a security level for which a SLS does not currently exist, the SIT creates one automatically. Whether noti ed by the TSH or by a client connection request, the SIT launches a new untrusted SLS task at the requested sensitivity level and noti es the CIT of the newly created level. The CIT creates new Window Manager and Selection Emulator clients at the same sensitivity level as the new SLS. The Window Manager and Selection Emulator clients send requests to the SIT to be connected to the new SLS. The SIT holds the requests. The new SLS sends connection requests to the IM and DM; these trusted components reply to a successful connection by sending the input and display hardware con guration data. This global, static information is considered to be system low, and each SLS obtains a copy of exactly the same data. The Input Manager and the Display Manager inform the Mini-Server that the new SLS has connected. The Mini-Server in turn informs the TSH. When it is fully initialized, the new SLS noti es the SIT that it is ready to accept connections. SIT forwards any waiting client connection requests along with the send rights to the reply ports that are contained in the requests to the new SLS. The new SLS replies directly to the clients (e.g., the Window Manager and Selection Emulator), and they are then connected. At this point, the SIT is eectively out of the loop. It does not retain communication rights with the untrusted clients. The SIT does retain send rights to the


180

Property Escalator Selection Emulator

Window Manager

Other Clients

AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA Single Level Server

•• ••

Display Manager

AAA AAA AAA

Legend:

Untrusted TCB

Server boundary Task creation Message flow

Input Manager

Figure 3: TX Normal Operational State SLS connection request port in order to permit future client connections.

5.3. Client Connection

An X application is a program that uses X services by making requests of an X server. X applications are typically started by the window manager or another client. The connection of the client to the appropriate instantiation of a SLS (one with a matching sensitivity label) is handled by coordination between the client, the SIT, and a SLS. The client sends a connection request to SIT having obtained send rights to its request port from the TMach Operating System name server. If a SLS at the client's sensitivity level is not already running, one is started as described in the previous section. In this case, the client's request is passed to the new SLS along with the requests for the Selection Emulator and Window Manager. Otherwise, the SIT forwards the request to the appropriate SLS, and the SLS responds directly to the client. As noted above, the SIT retains no connection to the client.

5.4. Normal Operation

Once clients are connected to the SLS, the system is in normal operation. Figure 3 shows the connections used in this state. This section describes a few common operations and how the architecture provides MLS support for them. The DM operates on top level windows (\children of root" in the X vernacular). Within these windows, all graphics operations performed by the SLS are integrated into the SLS's own screen image; this image is then passed on to the DM for display on the physical screen. When a client requests mapping of a top level


181

window, the SLS sends a message to the DM using its \hold" port. If the SLS is the current server, the DM will immediately process the request and send back an acknowledgment. If the SLS is not the current server, then the message will remain queued until the user selects its sensitivity level, at which point it will be processed. When the DM maps a window for a SLS, it creates a suitable labeled border around the window. All windows, including those that are displayed only brie y (e.g., pop-up menus), are labeled. Moving, resizing, and unmapping top level windows is handled similarly. Note that these operations on non-top-level windows are entirely internal to the SLS, except that they may cause the contents of a top level window to change. Reparenting a window (an operation performed by window managers to add \decorations" to the window) is simply unmapping the old top level window, followed by mapping the new top level window in its place. When a client draws in a window, the SLS performs the drawing in its virtual frame buer. When the drawing is complete, the SLS sends its virtual frame buer to the DM along with a list of windows and areas changed. The DM receives the contents update request on its nonhold port from the SLS. After clipping the new window contents relative to other windows on the screen, the DM updates the visual display. The clipping con nes the updating to the unobscured interiors of windows belonging to the SLS in question. The DM constrains the display of information from each untrusted SLS to the areas surrounded by its proper visible labels. When the user moves the pointer, clicks buttons, or types on the keyboard during normal operation, the IM sends the input to the SLS that is the current server. The SLS performs the ordinary X rules for routing input to its clients and is oblivious to any other SLSs. When the user wishes to perform a \cut and paste" operation, the cutting client will interact with the SE client for that level. As far as the cutting client is concerned, the SE is asking to paste the information although the SE is actually storing it with the PE. Similarly, the pasting client sees the SE as though it had performed a cut operation, when, in fact, it gets its information from the PE.

5.5. Trusted Path

Trusted path operation is provided to permit the user to change input sensitivity levels and perform other security related administrative functions. The user accesses trusted path operations by entering the secure attention key sequence. If the current server is a SLS, then the IM noti es it that it has been deactivated and noti es the MS that trusted path was invoked. The IM then begins sending input to the MS. The MS noti es the DM and TSH that the trusted path has been invoked. The DM sets its current server to none, blocking processing of \hold" port requests. The TSH sends commands to the MS to draw the menu of commands, and to change the current operating level label displayed in the reserved area to Trusted Computing Base. The MS performs the drawing operations in its virtual frame buer and forwards it to the DM for display. The TSH then waits for the user to click in one of the menu boxes. Note that all pointer motion is interpreted by the MS, and the TSH is only given pointer

182


coordinates when a click occurs. The details of the TSH command processing are too lengthy to describe here. As an example, consider the case where the user has asked to change the current sensitivity level to another existing SLS. The TSH updates the current label in the reserved area to be the newly selected sensitivity level by sending drawing requests to the MS. Again, the MS performs the drawing in its virtual frame buer and forwards the virtual frame buer to the DM for display. The TSH noti es the MS of the new value for the current operating level. The MS noti es the IM and DM of the new value for the current level. The IM noti es the newly selected SLS that it has been selected as the current server and begins sending it pointer and keyboard input. The DM begins processing requests from the \hold" port of the newly selected SLS.

5.6. Screen Lock

Automatic screen locking occurs when the IM detects that a certain period of time has elapsed without any input. The goal of automatic locking is to cover the working area (that portion of the screen which is not the reserved area) with an opaque pattern and not to remove the cover until the user unlocks the screen. Manual screen locking is invoked through the trusted path. It is initiated when the user clicks on the \lock" menu entry in the reserved area and is otherwise identical to automatic locking. If the IM detects a timeout without any input, it noti es the MS. If the current server is an SLS, then the IM noti es it that it has been deactivated. The MS noti es the DM to change its current sensitivity level to none, thus causing it to stop processing its current \hold" port (if any). The MS noti es the TSH of the timeout. The TSH requests the MS to map a window over the entire user portion of the screen. The TSH then draws a pattern on this window using MS drawing primitives. The TSH also sends messages to the MS to set the current operating label displayed in the reserved area to none and to display instructions to unlock the screen. After drawing the pattern, the MS sends the virtual frame buer to the DM for display. The TSH noti es the MS to change the current operating level to none. The MS noti es the IM and DM to change the current operating level to none.12 the IM discards input, and the DM ceases to process its \hold" port until the user unlocks the screen through the trusted path.

6. Architectural Tradeos The architecture described here takes the complex problem of securing a large graphical user interface package and solves it easily with polyinstantiation. Tradeos have been made to achieve trust and simplicity. This section describes some of the positive and negative aspects of these tradeos. 12

If an automatic lock occurs, IM is already in the none state. This extra noti cation is required when the user manually locks the screen.


183

6.1. The Price of Polyinstantiation

Polyinstantiation of servers has a price. For example, while the TMach Operating System's security policy allows write-up and read-down, the TX policy does not allow either of these operations for arbitrary X resources. If an untrusted low client were to send an untrusted high client an X resource ID (using the TMach Operating System mechanisms, not TX), the ID will not be useful to the high client, because the high client has no means of using it in its low context. Similarly, the X operation that gets a list of windows in the system (XQueryTree) will return a list of windows at the level of the caller only. Alternative implementations, such as Compartmented Mode Workstations (CMWs) [Gr'91], that do not polyinstantiate servers, can allow general read-down. Some CMWs also allow write-up. The CMWs do this at the cost of including the entire X server within their TCB, something that polyinstantiation avoids. Should a need for the secure sharing of X resources be demonstrated, we suspect that this could be eected by the introduction of a MLS database with an appropriate access policy for managing them. This would probably require substantial modi cations to the SLSs, obviating some of the advantages of our approach. Other eects of polyinstantiation include problems with managing screen real estate. A tiling window manager (i.e., one that does not produce overlapping windows) could successfully tile the windows within each level, but windows at dierent levels could and probably would overlap since a window manager at one level is unaware of windows at all other levels. Each window would be correctly labeled, but the eect would not be what the user anticipated.

6.2. DAC and Information Labels

Many people who work with trusted X systems believe that some form of discretionary access control (DAC) over X resources is desirable[Ep'91a]. Short of making the SLSs and window managers trusted (which would vastly increase our TCB size), DAC at the X resource level cannot be added to this architecture. We feel that restricting a TX server to clients belonging to a single X user (or to users that the X user is willing to trust) at one time is an acceptable tradeo to minimize the TCB. While this project is clearly not aimed at the Compartmented Mode Workstation[Wo'87][Gr'91] community, the question of whether information labels13 could be added to the architecture has been raised. As with DAC, the answer is no. Once again, the SLSs and window managers would have to be trusted to provide useful information labels. Whether clients that use DAC or information labels also require a degree of trust remains an open question. Hybrid solutions are possible. TX as a B3 windowing system could have C2 trusted single level servers and window managers to provide DAC or CMW 13

An information label represents the sensitivity of the information contained in a subject or object. Information labels are required in CMWs and are used for labeling information that is believed to be of a lower sensitivity than the object (or subject) from which it came. Information labels are advisory and are not used for access control.

184


based trusted SLSs and WMs to provide information labels. This hybrid allows a high degree of assurance that the system is trusted and enforces the overall system security policy, with lesser assurance that information labels are properly maintained and that the DAC policy is properly enforced.

6.3. Trusted Graphics

TX provides no assurance that the SLS drawing code is correct. For example, if an application asks to draw a circle, there is no guarantee that the circle will be drawn in the correct location with the correct attributes. In TX, we do guarantee that whatever the SLS draws in its private frame buer, be it a circle or a square will be correctly copied to the screen and displayed in an appropriately labeled region by the DM. Thus, we have traded the functionality of trusted graphics for a much smaller TCB. A close analogy can be drawn to an untrusted le server encapsulated within a trusted system. In this case, the overall trusted system makes no guarantee that the data will be stored or retrieved faithfully, only that it will be labeled correctly.

6.4. Graphics Hardware Usage

Our architecture presumes a \dumb" frame buer (i.e., one where the graphics hardware simply maps bits in memory to the screen). Intelligent graphics boards now perform many functions, such as drawing polygons, lling regions, and threedimensional operations using hardware, rather than using software as in our SLSs. Without special provisions, our architecture is unable to take advantage of intelligent graphics boards. The problem is that the SLSs cannot be allowed to use the graphics board directly because it typically contains a large observable state of its own, and DM only performs simple region copying operations. If graphics hardware could be encapsulated so that each SLS could use it with its own virtual frame buer and state in a way that supported ecient context switching, then it could be used in this architecture. It is likely that the economics of hardware will make a reasonable level of graphics hardware polyinstantiation feasible in the future, permitting a dierent approach to the problem.

6.5. Performance

Performance of the prototype TX server has not been studied in detail. Some standard X benchmarks were run. TX operation responses were on the average about half the speed of ordinary X when run on the same underlying hardware and operating system. The actual performance data indicates that TX does poorly on small area operations (15% of X on single pixel operations, 20% of X on small random areas) but much better on large area operations (95% of X on larger rectangles, 80% { 90% of X on other larger areas). Performance measurement (through pro ling) has shown that the TMach Operating System's message passing and context switching times dominate the system throughput. These issues will require further study to separate the security costs from the platform and operating system costs.

6.6. User Interface

In order to access windows at dierent sensitivity levels, users must invoke trusted path and activate the SLS of the desired window. Once an SLS is active, only


185

windows of the active level may be manipulated. To interact with a window within the level, the standard X focus policy14 is in force. It is impossible to interact with a window at a dierent senstivity level. We are unsure how users will react to this incongruous window focus policy, however we have been unable to devise any other mechanism that would be satisfactory.

6.7. Non-X Implementations

While we are using this architecture as a platform to build trusted X, there is no fundamental reason why the SLS could not implement a window protocol other than X. For example, a SLS could provide the graphical portion of a Macintosh or MS-Windows system, rather than an X server. This is a convenient mechanism to allow running dierent windowing systems simultaneously on the same display, with minimal modi cations to the windowing systems and their clients. Such an approach might have utility even in an environment where trust is not required. To demonstrate this concept, the Sun workstation version of the prototype includes support for both X and MGR[Uh'88], a freely available windowing system from Bellcore. Approximately a month's eort was required to get MGR running in the TX environment. Almost no changes15 to the TX TCB were required to support MGR, which indicates that our basic architecture is exible enough to support a variety of windowing systems.

6.8. Extensions

Various extensions have been developed for X, including three-dimensional graphics (PEX) and video (VEX). In the TX architecture, many extensions can be added without requiring any trusted code, and hence would not require re-evaluation. For example, we expect that PEX could be implemented as part of the SLS without any change to the TCB. This ability to extend the SLS (or replace it entirely) without changing the TCB is a major advantage of our architecture over other architectures. When the TX prototype rst became operational, the SLS was based on X11R416. Adding support for X11R5 when it became available required just two days of eort and no TCB changes.

7. Related Work Compartmented Mode Workstations (CMWs) are low assurance (B1) MLS X window systems originally designed for intelligence analysts. In addition, we are aware of two other approaches for high assurance windowing systems, a paper design for a system without any trusted code by Mayer and Padilla[Ma'92], and a patented architecture using hardware for high assurance by Sherman, Dinolt, and Hubbard[Sh'91]. We compare the TX approach with each of these. 14

15 16

The focus policy determines the identity of the X client that is to receive input. In X, there are two focus policies: \follow pointer" gives focus the top-most window that contains the pointer, \click-to-type" requires the user to click on the window. MGR required minor changes to the Input Manager. The fourth release of the eleventh version of X.

186


7.1. Compartmented Mode Workstations

All existing CMW implementations have similar architectures, including a monolithic trusted server, a trusted window manager, and a few trusted clients to assist with visual labeling and cut and paste operations. However, there is no reason why other architectures (including the one described here) could not be adapted to the CMW requirements. The descriptions of CMWs are based on numerous conversations with CMW designers and developers. The TX TCB is much smaller than that of the existing CMWs (see Table 1). Our TCB is about 10 percent of the size of existing CMW X TCBs. CMWs provide trusted graphics, DAC on X resources, and information labels; TX does not. While we do not feel these are major limitations, the hybrid approach described in section 6.2 is a possible alternative. That approach provides a high level of assurance on the overall system, with assurance equal to that of the CMWs for graphics, DAC, and information labels. Compatibility with untrusted X is a major goal for both TX and CMWs. The TX architecture oers a much higher degree of compatibility with X. For example, we are able to run untrusted window managers, which is impossible with CMWs. We require no special privilege mechanisms, unlike CMWs. While we constrain what clients can do, our system imposes fewer limits than CMWs, a counter-intuitive result. CMWs, however, can perform window operations across levels with ease, whereas it is not so simple in TX. We suspect that the key to the dierences lies in the respective security policies of the two systems. TX takes a very strong view of security. This view led us to conclude that securing the X protocol was impossible at the B3 level due to the rather arbitrary patterns of interclient communications that are established through the events that arise from the sharing of screen real estate and the input devices. While we are unaware of a detailed published description of a CMW security policy, it is our understanding that the typical CMW policy considers many of the interactions that result in these events to be examples of \covert channels" that do not have to be considered at the B1 level. This would explain why CMWs can perform operations that would not be allowed by the TX policy. Finally, our architecture allows X server extensions, or even replacement of the X server (e.g., with a new release) without modifying the TCB. We believe that TX can keep up with developments in the broader X marketplace more easily than CMWs.

7.2. Mayer/Padilla Design

A paper design for a high assurance windowing system is proposed by Mayer and Padilla in [Ma'92]. That paper describes a multilevel windowing system with no trusted code, henceforth referred to as MP. Mayer and Padilla argue that the TX architecture is not minimal, as their strawman architecture is clearly smaller. In the MP architecture, the Input Manager functions of detecting trusted path and routing input are presumed to be handled by the operating system. Their equivalent of the Display Manager runs at system high, accepting requests from window system servers (such as X servers) but never acknowledging the operations. While this architecture avoids trusted code, the cost is usability:


187

- No visible labels on windows Windows are not visibly labeled because the Display Manager equivalent is not trusted. While TCSEC has no speci c requirements for labeling windows, we believe that its requirements for labeling human readable output can be logically extended to include windows and that visible labeling is crucial to usability of multilevel windowing systems. - Trusted path is not graphical The user's windowing environment is destroyed and the user is placed into a simple terminal mode to perform trusted path actions. We feel that users want to use graphical interfaces as much as possible. CMW implementations have carried this even further, providing highly stylized color interfaces. - No veri cation of a region's sensitivity label If visible labels are not provided, we feel it is critical to be able to positively identify the sensitivity label of speci c region of the screen. The MP architecture cannot support this functionality. - No support for \cut and paste" between levels One reason for having a MLS windowing system is to facilitate the interoperation of clients at dierent levels. While the MP approach oers a primitive multilevel display, it provides no features that would allow clients to use the display features to cooperate. We feel that without this feature, a windowing system is of little or no practical use. In attempting to de ne a MLS windowing system without creating a trusted application, Mayer and Padilla overlook the primary reasons for wanting to use a windowing system in the rst place. Windowing systems exist to provide human interfaces. We believe that a windowing system security policy must include the human interface. A consequence of this is the extension of the application security policy to cover aspects of its operation that are irrelevant for the host. This in turn implies trusted application code. The TX architecture uses trusted code to provide those functions that need to be trustworthy: input routing, trusted path detection, trusted path features, and visible labeling.

7.3. Sherman/Dinolt/Hubbard Design

Richard Sherman, George Dinolt, and Frank Hubbard describe a very high assurance (beyond A1) multilevel windowing system using hardware[Sh'91], henceforth referred to as SDH. The SDH architecture (which predates TX, but was largely unknown to us during our design phase and did not in uence our architecture) is not based on any particular windowing system. SDH dedicates an untrusted processor to each imaging generator, which is analogous to TX single level server processes isolated using a high assurance operating system. The SDH display generator uses hardware to merge the results of imaging generators together and place them on the screen, performing a subset of the functions provided by the TX Display Manager. Because of its reliance on hardware separation, SDH provides high assurance and high performance. However, in order to keep the hardware simple, SDH does not allow overlapping windows of varying sensitivity labels. Rather, it partitions the screen into horizontal bands, each of which has a unique sensitivity label. Within each band, windows can overlap. Use of hardware as an isolation mechanism gives higher performance than TX, but requires additional hardware for each new sensitivity level to be used. Also,

188


the set of sensitivity levels supported is prede ned in SDH. This special purpose hardware with xed labels is in contrast to the general purpose hardware with a trusted operating system used in TX, where servers can be dynamically created and destroyed as necessary. Because the SDH uses non-overlapping bands, the input management and trusted path concepts are much simpler than in TX[Di'92]. Applications in SDH can cause the position of the pointer to move, but only within the current band. When the user moves the pointer to another band, the user's input is then labeled at the new band's sensitivity level and sent to the appropriate processor by the SDH equivalent of the TX Input Manager. The ability to switch levels via pointer movement was an early goal of TX. Our security analysis of the X protocol, especially the events associated with pointer movement across overlaping windows of dierent levels, convinced us that \point to change levels" was inconsistent with our other goals and we adopted our current approach. The size of the window bands can also be adjusted using the pointer. Since bands cannot overlap, spoo ng is not a concern as it is in TX. Other trusted path facilities necessary in TX, such as creating new window system servers, are not necessary, since the set of sensitivity labels in use is xed. We have a \human engineering" concern with using the pointer position for determining input sensitivity level: if the user inadvertently moves the pointer so that it points into a dierent window band, the input classi cation may be changed without the user noticing. The adoption of a \point and click to change levels" mechanism would eliminate this objection. One feature present in SDH but not in TX is that SDH is designed to allow trusted input (such as video) to be routed directly to the screen in a trusted manner. In summary, SDH trades o functionality in the areas of overlapped windows, the ability to create windows that cover the whole screen, and dynamically created untrusted window system servers for a high performance special-purpose hardware solution that has a simple input paradigm.

8. Conclusions

Two versions of TX are now operational: one for Sun 3 workstations with black and white monitors, and a second for Intel 486 based systems (IBM PC clones) with color monitors. When this research started in 1989, the general reaction in the security community was that a B3 windowing system (especially one based on X) was impossible; some of the team had doubts as well. Our design and development has shown that the early pessimism was unfounded. Our minimal, modular TCB, combined with a simple security policy and a formal model indicate that B3 X is feasible. Our experience thus far with implementation indicates that our analysis was correct. We present our working prototype as our strong evidence. In a more general vein, we see the creation of multilevel trusted applications by the encapsulation of untrusted functionality as a paradigm worthy of further study. With the advent of high assurance computing platforms such as Trusted Mach, we feel that the whole subject of trusted applications that extend or alter the policy of the supporting platform is ready for serious examination. One school of thought, typi ed by the Mayer and Padilla paper discussed above, feels that no


189

applications code should ever be trusted and that users should have to live with the environment presented by a traditional reference monitor based host operating under an access control policy. We reject this view. Even if we were to concede that the Mayer and Padilla X server is feasible, we feel that the facilities that it would oer users would be unsuitable for any realistic task. We can easily envision complex applications that involve the processing of information of multiple sensitivities. We see the need for specialized security policies that arise from the applications' domains and are not of sucient general interest to warrant their incorporation into a general purpose TCB. We are aware of the diculties inherent in attempting to secure large application programs and suggest that the use of trusted encapsulation code may be one solution in such cases.

9. Acknowledgements The authors appreciate the assistance of Steve Padilla and Marvin Shugerman, both of whom assisted during various phases of the architecture development. We also appreciate many valuable comments from reviewers.

10. References [Be'75]

David Bell and Leonard La Padula, Secure Computer Systems: Uni ed Exposition and Multics Interpretation, Technical Report MTR 2997, The MITRE Corporation, Bedford, MA, (July, 1985.). [Bo'91] Chuck Bonneau, Personal Communication, (telephone conversation), (1991). [Br'91] Don Brinkley, Personal Communication, (telephone conversation), (1991). [Di'92] George Dinolt, Personal Communication, (telephone conversation), (1992). [Ep'91] Jeremy Epstein, John McHugh, Rita Pascale, Hilarie Orman, Glenn Benson, Charles Martin, Ann Marmor-Squires, Bonnie Danner, and Martha Branstad, \A Prototype B3 Trusted X Window System", in Proceedings of the Seventh Annual Computer Security Applications Conference, December, 1991. [Ep'90] Jeremy Epstein, \A Prototype for Trusted X Labeling Policies", in Proceedings of the Sixth Annual Computer Security Applications Conference, December, 1990. [Ep'91a] Jeremy Epstein and Jerey Picciotto, \Trusting X: Issues in Building Trusted X Window Systems -or- What's not Trusted About X?", in Proceedings of the 14th Annual National Computer Security Conference, October, 1991. [Fr'91] Les Fraim, Personal Communication, (telephone conversation), (1991). [Gr'90] Jerey Graham and Wayne Morrison, Trusted Mach System Architecture, TIS Report #324, Trusted Information Systems, Glenwood, MD, (April, 1990). [Gr'91] Graubart, R. D., Berger, J. L., Woodward, J. P. L., Compartmented Mode Workstation Evaluation Criteria, Version 1, Technical report MTR 10953, The MITRE Corporation, Bedford, MA, (June, 1991). [MI'89] MIT X Consortium, Inter-Client Communication Conventions Manual, Version 1.0, MIT X Consortium Standard, (1989).

190


[Ma'92] Frank Mayer and Steve Padilla, \A Straw Man Design for an MLS Window System: An Example Complex Application for High Assurance Systems", in Proceedings of the 15th Annual National Computer Security Conference, October, 1992. [NC'85] National Computer Security Center, Trusted Computer Systems Evaluation Criteria, DoD 5200.28{STD, Fort Meade, MD, (December, 1985). [NC'85a] National Computer Security Center, Computer Security Requirements Guidance for Applying the DOD TCSEC in Speci c Environments, Fort Meade, MD, (June, 1985). [Sc'88] Robert Schei er, X Window System Protocol, MIT X Consortium Standard, X Version 11, Release 4, (1988). [St'88] Jennifer Steiner, Cliord Newman, and Jerey Schiller, \Kerberos: An Authentication Service for Open Network Systems", in Proceedings of the Winter USENIX 1988 Conference, 1988. [Sh'91] Richard Sherman, George Dinolt and Frank Hubbard, Multilevel Secure Workstation, U.S. Patent 5,075,884, December 24, 1991. [Tj'91] Homayoon Tajalli, Personal Communication, (telephone conversation), (1991). [Uh'88] Stephen Uhler, MGR - C Language Application Interface,, Bell Communications Research, 1988.. [Wo'87] John P. L. Woodward, Security Requirements for System High and Compartmented Mode Workstations, DIA Document Number DDS-2600-5502-87, (November, 1987).

a high assurance window system prototype1 - CiteSeerX

a high assurance window system prototype1 - CiteSeerX

Suggest Documents

A Concurrent Window System

High Assurance Platform (HAP) High Assurance Challenges

Initial Documentation Requirements for a High Assurance System ...

SCR: A Practical Approach to Building a High Assurance ... - CiteSeerX

High Assurance Requires Goal Orientation - CiteSeerX

High-Assurance Distributed, Adaptive Software for ... - CiteSeerX

78_Cross domain comparison of System Assurance - CiteSeerX

78_Cross domain comparison of System Assurance - CiteSeerX

High Power Coax Window

Using the Web Instead of a Window System - CiteSeerX

Model-Based Design of a Power Window System ... - CiteSeerX

Using the Web Instead of a Window System - CiteSeerX

A Practical Approach to High Assurance Multilevel Secure ... - CiteSeerX

Safety assurance for a signalling system based on quality ... - CiteSeerX

high-assurance sdr-based avionics rfid system - ee.washington.edu

Process Authentication for High System Assurance - People - Virginia ...

High order adaptive optics system with a high density ... - CiteSeerX

X Window System Protocol - XFree86

High Assurance BPEL Process Models

JThD137 - High-Dynamic-Range, 200-ps Window, Single ... - CiteSeerX

High-pressure Metamorphism in the Tauern window - CiteSeerX

Hospitals Pharmacy Quality Assurance System

A Virtual Window On Media Space - CiteSeerX

Waste Paper Grade Identification System using Window ... - CiteSeerX