Section 17.1. Introduction

17.1. Introduction

The Chameleon design philosophy is to put the user, and thus the user interface, first. Frequently, security practitioners design detailed security models and mechanisms, then implement them in software or hardware, then design interfaces to expose the security features to users, or to application programmers who then expose them to users. In contrast, our project began with a very high-level idea of the security model of the system, and then moved straight to the user interface design. Details of the security model and decisions about the implementation are driven by the primary focus of making the interface easy to understand and convenient to use.

In the physical world, we have reasonable security in spite of a lack of fine-grained security mechanisms. For example, we routinely allow only partly-trusted people into homes, such as friends for socializing and repairmen to fix our utilities. We often monitor them only loosely, because that is all that is required to ensure that the plumber is not looking through our CDs instead of fixing the pipes. This level of supervision is easy because CDs and pipes are typically not near one another. In general, the varied locations of different types of objects and activities in the home provide a convenient, albeit coarse, security mechanism.

In information space, no analogous mechanism exists. On typical home computers, all programs run by the user have access to all data, and in some circumstances implement security policies the users do not intend.^[1] Users do not necessarily store files for different purposes in separate places. Even when they do, current security mechanisms do not automatically take advantage of this, and it is too much to expect users to set good permissions on every file or directory (e.g., using permission bits under Unix^[2] or access control lists under modern versions of Microsoft Windows^[3] and other operating systems). However, just as people coarsely sort their possessions in the physical world into separate rooms, they may be willing to coarsely sort their files and applications. This sorting may enable the system to protect data from malware more effectively than it does at present.

^[1] Nathaniel S. Good and Aaron Krekelberg, "Usability and Privacy: A Study of Kazaa P2P File-Sharing," Proc. CHI 2003, CHI Letters 5:1 (April 2003), 137144. See also Chapter 33, this volume.

^[2] Fred T. Grampp and Robert H. Morris, "UNIX operating system security," AT&T Bell Laboratories Technical Journal 63:8 (Oct. 1984), 16491672.

^[3] Karanjit S. Siyan, Windows NT Server4: Professional Reference, 2nd Edition (Indianapolis: New Riders Publishing, 1997).

In Chameleon, users coarsely sort their files and applications by assigning each file to one specific category, called a role,^[4] and installing applications into one or more roles.^[5] Files are put into one role or another based on how secure the file should be or on the types of activities you do with the file.

^[4] For readers familiar with role-based access control (RBAC), note that roles in Chameleon are similar, but not identical to roles in RBAC.

^[5] A program is stored as files, so for a program to be runnable from multiple roles, it must be installed using Chameleon tools that set up this behavior. Regular files are visible only to a single role.

The idea of a role-based system is not new. The Chameleon security model borrows ideas from previous security research, especially compartmented mode workstations,^[6] sandboxing,^[7] and role-based access control.^[8] It is also similar to the WindowBox project.^[9] Chameleon is novel because of its focus on making a role-based system easy to use. To make our interface intelligible and convenient, we keep it extremely simple. Although this entails some sacrifices in flexibility, a simple system that is actually used provides more security than an elaborate one that is not. Another key part of our security philosophy is to give users control over trust decisions. This control does allow users to make insecure decisions, but we believe that users will not adopt a system if it is too restrictive, especially on their home computer.

^[6] Jeffrey L. Berger, Jeffrey Picciotto, John P. L. Woodward, and Paul T. Cummings, "Compartmented Mode Workstation: Prototype Highlights," IEEE Transactions on Software Engineering 16:6 (1990), 608618.

^[7] Vassilis Prevelakis and Diomidis Spinellis, "Sandboxing applications," Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference (Boston, June 2001), 199126.

^[8] David Ferraiolo and Richard Kuhn, "Role-Based Access Controls," 15th NIST-NCSC National Computer Security Conference (1992), 554563.

^[9] Dirk Balfanz and Daniel R. Simon, "WindowBox: A Simple Security Model for the Connected Desktop," Proceedings of the 4th USENIX Windows Systems Symposium (Aug. 2000), 3748.

Based on our research so far, we think that the following set of roles strikes a good balance between security and usability:

• Vault. A safe place to put valuables you want to keep safe. Only trusted programs are given access to the Vault.

• Communications. The role for working with email and the Web. Because email and the Web are the most common ways computers get infected with malware , important files are not stored in this role.

• Default. This role is for files that are not particularly sensitive and for programs that are fairly trustworthy. It is the typical workspace for most files.

• Testing. The role for installing and trying out new, and potentially untrustworthy, programs. No important data is kept here.

• System. The role for files that the system itself requires. Only trusted programs from trusted sources are installed here.

One way for malware to spread and to cause damage is by making applications change files that they would ordinarily never need to change. Chameleon mitigates this problem by keeping each application confined to its own role. An application cannot read or write files that don't belong to its role (and, in fact, the application doesn't even know they exist). For example, the email application might be restricted to run only in the Communications role, so if a virus is received in an email message, it cannot affect files in other roles, such as important financial files stored in the Vault. Although an application can be installed to be available in all roles, installing it in only some roles provides an extra layer of security because it prevents the application from being started accidentally in the "wrong" role. If an application is available in multiple roles, it can be running in more than one of them simultaneously. However, each instance of the application is separate from the others and is confined to its role.

Some security exploits rely on one program to start another application and tell it to do something dangerous. For example, if an email message contains a malicious attachment, the email application launches the attachment application, and that is what causes the damage. In Chameleon, damage from chaining applications together like this is contained because an application can start applications only in its own role, unless specifically given permission by the user. So, for example, an email client running in the Communications role could not automatically start a work processor in the Vault role.

Because of its simplicity, Chameleon's security model does not allow users to express as wide a variety of security policies as traditional systems do. However, Chameleon's ease and convenience mean that it will be used (effectively) more often, and so in practice it will have greater security than traditional systems.

The following sections briefly describe Chameleon's security design for file organization, program communication within the system and outside, and advanced role features. Implementation details are covered in later sections.

17.1.1. File Organization in Chameleon

The additional security Chameleon provides comes largely from protecting files, so an important design decision for Chameleon was how to organize files. The two important issues are ease of use and security.

The most obvious course is to let people continue organizing files however they wish, in whatever directories they wish. Although this seems like the most user-friendly approach, it means that to make roles useful, the user would have to set the role for every file individually. Even though choosing one role from a handful is a lot less work than typical file control mechanismsfor example, Windows lets you set multiple rights (e.g., read, write, create) separately for each user on the systemit is still much more complicated and cumbersome than we wanted Chameleon to be.

Instead, in Chameleon, files are organized by role, based on their security level. For example, the Testing role is for files that are not trusted, and the Vault role is for highly trusted files. Fortunately, most users are already familiar with grouping files together using directories. For these reasons, Chameleon uses directories to group together those files belonging to the same role.

More specifically, there is a home, or top-level, directory for each role, and all files for each role are stored under that directory. Users can organize files within a role by creating directories in the home directory, and subdirectories under those, and so on. The restriction Chameleon has is that all files in the same directory belong to the same role.

This organization has the advantage that it is simple to understand, and we believe that it will be easy for most people to use. There may be people who are used to putting all their files in one directory, and they will have to do some sorting to separate files into different roles to get the advantages of Chameleon's security. However, our testing so far supports our belief that this is not too onerous. If future testing reveals that many people want a more flexible modelfor example, to allow a file to belong to more than one role simultaneouslysuch features could be added to Chameleon.

17.1.2. Interrole Communication and Network Access

Roles affect what files a program can access and what access it has to other programs on the same computer. Programs running in the same role have the same access to each other as programs run by the same user have to each other in existing systems. Programs running in different roles have essentially the same access as programs run by different usersthat is, a program in one role may be able to communicate using network protocols or other interprocess protocols (e.g., shared memory) with a program in another role, but it cannot look into the private memory space of the other program nor kill the other program.

Because different roles in Chameleon contain information of differing sensitivity and can run programs of varying trustworthiness, Chameleon limits communication with external computer systems, based on role:

• Vault. Because the Vault stores the most sensitive documents, it has highly restricted network access . Programs in the Vault can send, but not receive, email, and can connect to web sites, but only sites on the "white list" of trusted sites. If a program in the Vault attempts to connect to a site not on the white list, Chameleon will ask the user for approval before allowing the connection. The user can also add new sites to the white list. The Vault cannot receive incoming network connections (e.g., it cannot run servers).

• Communications. Only email, web, and instant messaging connections are allowed into and out of this role.

• Default. This role has no network restrictions.

• Testing. Programs in this role are not trusted, so they are not allowed any network access without user permission.

• System. This role implements network restrictions so is not itself restricted. However, networking programs should not be installed here because a security breach in this role could be very damaging.

17.1.3. Advanced Role Features

A benefit of the role paradigm in Chameleon is its flexibility. Chameleon allows users to have more roles if they want greater compartmentalization of their files. Chameleon lets users "clone" one of the built-in roles to create a new role with the same security level (e.g., network access). Although the new role has the same type of security as its parent, it is a separate role, so, for example, neither role has access to the other's files. These new roles can also be deleted when no longer needed. For example, important work documents and important personal documents could be kept separate from each other using two separate Vault-level roles. Or a new Testing role could be created to temporarily try out a particular program, and could then be deleted.

An application that was written for Chameleon could take greater advantage of roles. For example, email attachments are a common source of malware. To help protect a user from potentially malicious attachments, a role-aware email client could create a new role on-demand when a user opens an attachment. After the attachment is closed, the email client would then destroy the role.

The main benefit of Chameleon is in helping users protect their own files from programs they themselves run. However, many users have files that are shared with other people, for example, on corporate fileservers. To make other users' files available, Chameleon uses an interface similar to the "Map network drive" dialog in Microsoft Windows. In addition to the existing authentication needed to authorize access to the files, the user also specifies the role in which the files should appear. Note that when the files are mapped and appear to be in a certain role, it does not change the files, for two reasons: the owner of the files may have a different set of roles, and the system the files are stored on may not be running Chameleon and thus not have roles at all.

To share files, the user has to specify what files to share, with whom to share them, and what type of access to give (e.g., read, write). In keeping with the rest of the Chameleon security model, the unit of sharing is the rolethat is, entire roles are shared or not shared. To limit what is shared, users can create new roles. Each role keeps a list of which users it is shared with. Many sharing mechanisms allow sharing with groups of users, but Chameleon does not have groups because, for home users, this would only add complexity and rarely, if ever, be needed. In keeping with Chameleon's philosophy of simplicity, files are shared on an all-or-nothing basis. That is, if a file is shared with another user, that user may perform any operation on it: read, write, delete, and so on.

Only two roles in Chameleon are suitable for sharing files: Default and Testing. Because the Vault and System roles contain the sensitive documents, they cannot be shared, nor can foreign files be mapped to them. The Communications role is specifically for communications applications, so it also cannot be shared nor mapped into.