Section 17.4. Chameleon Implementation

17.4. Chameleon Implementation

The 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 Partitioning

In 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 implementation

the 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:

• cselman. Manages selections and the clipboard across the X servers and makes it appear to applications that the system has a shared clipboard.^[13] When an application requests pasting the selection from another role, cselman asks the user for permission before allowing access.

  ^[13] Actually, X Windows has multiple "selections," of which the clipboard is one (along with PRIMARY and SECONDARY). cselman makes each one shared as a single selection.

• cxdnd. Manages the X drag-and-drop protocol so that it works across X servers.

• Desktop. Manages the icons the user sees on the desktop (e.g., My Computer, the trash can).

• Toolbar. Provides a menu for easy access to launch programs. It also shows an icon for each running program so that it can be (de)iconified, closed, etc., easily.

• Role managers. There is a role manager for each role, which provides a central point for operating on all applications in a role at once, for example, to iconify or kill them.

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.

^[14] For a discussion of building security into the X server, see Doug Kilpatrick, Wayne Salamon, and Chris Vance, "Securing the X Window System with SELinux," NAI Labs (March 2003); http://www.nsa.gov/selinux/x11-abs.html.

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 Security

This 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]).

^[15] National Security Agency, "SELinux"; http://www.nsa.gov/selinux/.

17.4.3. Network Security and Interprocess Communication

This 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 Security

Although 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:

Operating system

Traditionally, security is implemented in the operating system. This has the advantage that a single implementation is available to all applications, which makes it easier to ensure that the security is implemented correctly.

However, the operating system provides only low-level primitives, and it is up to the application writer to present these in a way that makes sense to the user. To look at it another way, the operating system has no context for operations. For example, if the operating system receives the command to reformat a disk, it does not know if that is a secure operation. It could be a legitimate user preparing for a reinstall, or it could be malware.

Applications

Security today is often found in applications, such as email clients that include encryption functionality or secure web browsers. From a usability perspective, applications have an enormous advantage over operating systems, because the application knows the higher-level goal the user is trying to accomplish. So the application can, at least in theory, put the security operations in the context of the user's normal workflow so that they are easy to understand and convenient to use.

Unfortunately, it is undesirable to implement security features separately in every application, because doing so introduces more opportunities for bugs that introduce security vulnerabilities, and for inconsistent user interfaces.

Toolkit

We believe that application authors need help bridging the gap between the security features users desire and the security primitives operating systems provide. A toolkit that provides features such as the role-aware file dialog box in Chameleon (see Figure 17-4) may be able to combine the advantages of operating systems and applications. A toolkit has a higher-level context for what the user is trying to accomplish than does the operating system. Also, a platform may require security features to be included in only one (or a small number of) toolkits, which reduces the number of implementations greatly, compared to the application level.

The disadvantage of the toolkit level is that we do not currently know what the most useful abstractions are for developers of usable, secure applications. Toolkits will still depend on the operating system for enforcing security policies, and they will not automatically make applications usable, but they can be helpful in combining usability and security. We believe that Chameleon will be a useful platform for exploring this issue.