17.4. Chameleon ImplementationThe current implementation of Chameleon is being written in C and C++ for X Windows on Linux (kernel 2.4.x). It will support existing applications and allow new role-aware applications to be developed. The X Windows implementation does not put support for the Chameleon security model directly into X Windows or the operating system, but instead layers the Chameleon model on top, using existing security features. A schematic of the desktop for the X Windows implementation is shown in Figure 17-3. Because they deal with multirole windows and objects, the desktop and the taskbar are managed by trusted programs. Applications, however, need not be trusted. The following section describes how this implementation enforces role separation in three places: the windowing system, the filesystem, and the network. 17.4.1. Window System PartitioningIn the Chameleon security model, applications are not allowed to see what is in windows in other roles, or to send input events (e.g., mouse clicks, key presses) to windows in other roles. However, in X Windows, once an application connects to the server, it is allowed to inspect the contents of, and send input to, all windows. To enforce role separation, Chameleon uses a separate X server for each role (see Figure 17-8). Applications connect to an X server as usual, but it is actually a virtual X server (Xvfb, from the standard X Windows distribution) that writes its output to a buffer in memory instead of to a display, and does not connect to a mouse or keyboard. Chameleon uses a new program, cproxy, to monitor each role-specific X server for output. cproxy takes the output and copies it to the X server with which the user interacts. cproxy also takes the input from the user (via the desktop X server) and sends it to the appropriate X server, depending on which window has input focus. For example, if a window from the Vault role has focus, input will be sent to the X server for the Vault role, which will forward it to Figure 17-8. Architecture of Chameleon in X Windows implementationthe appropriate application. If a window moves or resizes on a role-specific X server or on the desktop X server, cproxy mirrors this change on the corresponding display to keep them synchronized. Interactions with the desktop and the taskbar do not need to be forwarded, because they are connected directly to the desktop X server. In addition to cproxy, Chameleon contains these custom software components:
Each role manager needs access only to its own role, so it is run as that role. However, the other Chameleon components interact with programs and servers from multiple roles, so they must be trusted. For example, the Desktop and Toolbar may launch applications in any role. All nonapplication software components are started by Chameleon. The trusted Chameleon components are told where the desktop and role X servers are when they start, and are notified if role X servers are created or destroyed later. This architecture has several advantages. The primary advantage is that it provides good separation of roles. When a program is launched by Chameleon (e.g., by the Toolbar), the only X server to which it is given access is the one for its role, so it cannot affect other roles or the desktop X serverin fact, it doesn't even know they exist. And because it has no access to the other X servers, it cannot give greater access to any program it launches. Even if a role-specific X server crashed, other roles would not be affected. This architecture also allows X applications that are unaware of Chameleon and roles to run normally, without modification. At the same time, it allows applications that are role aware to run side by side. It is also considerably less work than building role awareness into the X server, primarily because the X server manages many different resources internally (e.g., windows, properties, fonts, colormaps, keyboard maps), and access to all of them would have to be controlled based on role.[14] And it has the deployment advantage that each user can run the same X server on his desktop that he normally uses.
This architecture has the disadvantage that it consumes more resources than an architecture where there is one X server that is role-aware. However, because X Windows is designed for distributed operation, it would be easy to spread the CPU and memory requirements across multiple computers. 17.4.2. Filesystem SecurityThis prototype prevents applications in one role from accessing files belonging to another role by using a separate user account for each role, and setting the operating system's built-in file permissions appropriately. Chameleon provides a graphical interface to the filesystem that makes all files for the same user appear to belong to different roles rather than to different user accounts. The advantage of this scheme is that it does not require a new security infrastructure based on roles, but instead takes advantage of existing file security mechanisms. However, it has the disadvantage that what the user sees is different from what is going in the filesystem, and this difference is visible to applications. In particular, programs that are not Chameleon-aware will likely expose the different user accounts. It was a compromise to make the implementation of this prototype simple. In the future, we may use other security systems that can support the Chameleon model more directly (e.g., SELinux[15]).
17.4.3. Network Security and Interprocess CommunicationThis prototype does not implement network access control based on role, as a result of the lack of support in the underlying operating system (Linux). Extensions such as SELinux include the mechanisms needed to include this feature in Chameleon, and may be used in the future. Controls on interprocess communication are managed by the operating system. Because separate roles run as separate users, programs cannot kill programs in other roles or access them except with mechanisms that work across users, such as with sockets. The environment for Chameleon, home use, is not a high-security one, so Chameleon does not attempt to control covert channels. The Chameleon architecture allows each role to be run on a separate physical or virtual machine, which would make it more difficult for programs running in different roles to find one another and communicate. 17.4.4. Software Architecture for Usability and SecurityAlthough in the Chameleon project we are focused primarily on designing paradigms and interfaces for usable security, we are also interested in how to architect the software to make it easier to implement in a way that is both usable and secure. One issue in particular concerns in which part of the software system the security should go. In high-level terms, there are three places it might go: the operating system, the application, or a toolkit or library sitting between them. Each of these has advantages and disadvantages:
|