Interaction Design for End-User Security

Interaction Design for End-User Security
Miriam Walker mwalker@cs and Ka-Ping Yee pingster@cs, CS 261, Dec 2000

PRE-PUBLICATION DRAFT
Please do not cite without permission.
Comments are welcome -- thanks!

We introduce principles for usable security that aim to improve the match between users' expectations and system behaviour. The scope of this paper is control by end users of resources on their own personal computers. Case studies are given to illustrate security vulnerabilities and incidents involving violations of the principles. Applying these principles to the design of a hypothetical desktop interface illustrates the ability to provide improved security within a familiar looking environment. Protection is provided against risks such as viruses, malicious applications, window spoofing, and keystroke capture.

Contents

Introduction
Problem Statement
Principles of Secure Interaction Design
Case Studies
Design of a Secure Desktop Interface
Conclusion
Acknowledgements
References

1. Introduction top

The design of many computer systems provides inadequate protection of the privacy and security of users' data and systems. Some systems allow insufficient protection while others are too complex for most computer users. In all cases, but particularly for home users, security must be easy to use to be effective because a human must eventually be responsible for making security decisions. This paper provides a set of principles for usable security, examples of the vulnerabilities that these principles are aimed to address, and a desktop interface designed to provide control and safety for the end user. For the desktop, we chose a framework visually similar to the Microsoft Windows platform familiar to most computer users.

The principles defined herein can be used to evaluate and inform designs for operating system or application security. Although in some cases only an operating system can truly enforce the recommended restrictions, we believe these principles can also be useful in designing more secure applications. Because many end users work without the guidance of system administrators, we have emphasised usability as necessary for enabling users to make good decisions about security. We acknowledge that users need to be able to protect themselves from the consequences of malicious code. Even when system administrators and security experts are available to define a security policy, these principles will still help them to implement effective security.

This paper is strongly aligned with the operational definition of computer security given by Garfinkel and Spafford: "A computer is secure if you can depend on it and its software to behave as you expect" [GS96]. If we tell the system to retrieve some information over the network and in the process it reveals a credit card number to a stranger, this is an inconsistency with our expectations. The term "security violation" is not meaningful without a context of what expectations are being violated. Hence, there is a crucial challenge in communicating these expectations accurately between the human and the computer. The system must then constrain application behaviour to meet those expectations. Because we rely on the user interface to communicate intentions to the system, the interface for controlling security properties must be part of the trusted computing base.

2. Problem Statement top

As a simplifying assumption, we consider the situation of a user who owns and has physical access to a personal computer and its associated peripheral devices. The computer runs trusted operating system software. The user obtains and runs application software that might not be trusted, and wants to control which resources applications can command. Controllable resources include files, devices, memory, and processor cycles.

This paper does not address more complex relationships such as sharing resources with another party. Although assuring the security of any personal computer connected to a network must involve these relationships, the simpler problem we address here remains a relevant and necessary first step. For the remainder of the discussion we will treat the network as just another peripheral device.

3. Principles of Interaction Design top

The following section presents seven basic principles of interaction design for security. Our premise is that someone must make decisions about security privileges, and the system must present that person with the proper information and abilities to control them. Usually this person will be the end user, since he or she owns the resources on the system and is unlikely to hire someone else to act as their personal system administrator.

We begin with a simple statement of each principle, and then provide details and rationale.

Explicit Privilege. Privileges must only be obtained by applications as a result of an explicit action that is understood by the user to cause granting.

Expressiveness. The user interface must provide sufficient expressive power to describe a safe security policy without undue difficulty, and must allow users to express security preferences in terms that fit the purpose.

Cost-benefit. Security measures must be perceived by end-users as providing sufficient effectiveness and ease of use such that users choose to operate securely rather than insecurely.

Discriminability. The system must enforce that distinct objects have unspoofably discriminable representations. Trusted systems must be able to communicate with the user in a way that untrusted systems cannot.

Certainty. The consequences of any privilege-granting action must be apparent and must match the expectations generated by the interface.

Visibility. The interface must allow users to easily review active privilege relationships in the same terms as the granting actions that were taken.

Revocability. Granted privileges must be easily revocable.

3.1. Explicit Privilege top

Explicit privilege is the most basic requirement for controlling privilege in any system. In current systems, applications often have privileges to resources such as the network and filesystem without ever having been explicitly granted these privileges. Explicit privilege is related to Saltzer and Schroeder's principles of Least Privilege and Fail-Safe Defaults [SS75]. Fail-Safe Defaults suggests that objects should start with no privileges. Requiring each privilege to be explicitly granted increases the likelihood that objects will operate with the least privilege necessary. Without such a restriction, the user becomes responsible for finding a potentially unlimited set of implicitly granted privileges to disable before the system is safe.

An objection to explicit privilege might be that the user would be overwhelmed with privilege-granting decisions. We can judge when explicit privilege is necessary on the basis of user's expectations. For example, if there is a window on the screen that clearly belongs to an application, users will expect the application to draw in the window. However, it would certainly be unexpected for the application to delete the user's personal documents. Just as it requires an explicit action for the user to instruct the computer to delete files, so should it require explicit action for any program to acquire from the user the ability to delete them.

The judgement of what privileges should be explicit should be based on the potential consequences, not on the technical difficulty of the decision to be made. Any privilege that could result in unexpected behaviour should be controlled by the user. If the user cannot readily understand the consequences of a privilege, that privilege should never be granted at all, not merely hidden under some "Advanced" section of the interface. If a truly necessary privilege seems to require an unusual degree of technical knowledge, then the model presented to the user should be rethought in terms that can be understood.

3.2. Expressiveness top

If the language used to express security preferences does not match the user's model of the system, then it is hard to share resources in a way that corresponds with intentions. Users should not have to specify preferences at a level of detail that is excessive or inadequate. If the way users must express security preferences is too detailed, there is increased risk of error as users overlap or leave out specifications. On the other hand, if the granularity is too large, users will be forced to give away more authority than they intend.

3.3. Cost-Benefit top

It is critical to emphasise that security be perceived as easy to use by users, not designers, software developers, or system administrators. Actual behaviour is the only definitive metric for whether users perceive the benefits of security to outweigh the costs. Security must be useful enough to warrant the extra learning time and any additional ongoing effort over using a different system with less security, or using the same system insecurely.

This is not as severe a conflict as it sounds, as often it can be possible to make an expression of security preferences a natural part of communicating with the application. For instance, one already has to choose a file when asking an application to open a document; this is a natural expression of file access permission. Opening a file in a secure system need not require more effort than it already does in today's insecure systems.

3.4. Discriminability top

Just as many user interface design guidelines promote consistency among things that are the same, so should different things look different. Being able to tell things apart is a question of identification, and correct identification is a prerequisite for proper communication of intent. When identity is threatened, either by inadvertent collision or by intentional masquerading, the user is vulnerable to error.

A clear distinction between the representations of different privileges makes it less likely that the wrong privilege will be granted. A clear distinction between the appearance of different programs makes it less likely that the wrong program will be executed. A clear distinction between operating system and application windows prevents spoofing of password dialogs and mistaken granting of privileges to the wrong application.

Discriminability applies right up to the level of human perception. For example, the choice of typeface has security consequences. It is not enough for two identifiers to be distinct strings; they must be displayed using visually distinct glyphs. In some fonts, the lowercase "l" appears the same as the digit "1". In Unicode the issue is further complicated by characters that combine to form a single accented letter.

3.5. Certainty top

Once the user is given control to make security decisions, the results must reflect the user's intent in order for the system to be secure. Certainty requires discriminability, but stresses a concrete binding between expectations of outcomes and actual outcomes. The system must ensure that the privileges available to a process exactly match the privileges granted. However, the correctness of the security implementation is irrelevant if the security policy that is being correctly enforced is not the one the user intended. This principle addresses not just actively misleading information, but also ambiguous or incomplete information. If information is missing or vague, then the results are very unlikely to match what we expect.

An interface can be misleading or ambiguous in non-verbal ways. Many graphical interfaces use common widgets and metaphors, conditioning users to expect certain unspoken conventions. For example, round radio buttons usually reflect an exclusive selection of one option from several options, while square checkboxes represent an isolated yes-or-no decision. The presence of an ellipsis at the end of a menu command implies that further options need to be determined before the action takes place, whereas the absence of such an ellipsis implies that the action will occur immediately when the command is selected.

Visual interfaces often rely heavily on association between graphical elements, such as the placement of a label next to a checkbox, or the grouping of items in a list. For example, within a dialog box, we rely on the user to correctly associate text stating which application will get a privilege with the privilege being granted. Since association is so important, the Gestalt principles of grouping [Wer23] can be applied to improve both certainty and discriminability:

Proximity: items close together are seen as belonging together.
Closure: line breaks and form discontinuities are filled in.
Symmetry: symmetrically positioned and shaped objects are perceived as belonging together.
Figure-ground segregation: small objects seen as foreground.
Good continuation: line segments are more likely to be seen as belonging together if they are following a line or curve.
Similarity: similar shapes belong together.

3.6. Visibility top

To control a system the user must be able to see its state. Visibility of system state is advocated by Jakob Nielsen as essential for usability [Nie94]. Likewise, visibility of privileges is necessary for users to understand the security implications of their actions. Such privileges come about as a result of the user's granting actions, so from the user's perspective the system state is defined in terms of those granting actions. For instance, in order to control a printer, a user has to be able to review any actions that granted access to the printer. Past granting actions that have no effect on the current state (such as access given to an application that has since terminated) need not be visible. It should be possible to identify privileges both by inspection of either the holder or the resource to which the privilege offers access. Without visibility of privileges, any application that gains a privilege would be able to retain and use that privilege undetected and indefinitely. In current systems it is possible for applications without windows to run almost invisibly. Only processes belonging to the operating system should be able to run invisibly with privileges.

3.7. Revocability top

Systems should be designed to minimise errors, but people will always make errors and the system should help them to recover from errors. In the context of granting privileges, recovery is analogous to revocation. Users might intentionally grant privileges to an application and later find that the application is malicious, or they might inadvertently grant the wrong privilege. In both of these cases, granting decisions must be reversible. Note that revocation does not undo damage caused by the abuse of a privilege, so interfaces should be careful not to draw too strong an analogy between "revoke" and "undo". Revocability relies on visibility of privileges.

4. Case Studies top

In the following sections, we examine the security problems in real-life applications that arise from usability issues, and apply the foregoing principles to evaluate the cause of the problem.

4.1. Java Security in Internet Explorer top

Figure 1. Java security settings in IE.

Java 1.1 models file access such that applets get access to all files or none, so the granularity of file permissions is not sufficiently expressive. Users have no way to give explicit privilege to only one file. The behaviour of Java applets under Microsoft Internet Explorer 5 violates the principle of certainty by misleading users about the security model. Two completely independent options are provided: "Access to all files" and "Dialogs". "Access to all files" gives universal permission to read and write any file; "Dialogs" permits applets to show a file chooser dialog. Although a perfectly natural way to grant privileges to one file would be to select it for opening in the file chooser, in fact the selection in the file chooser has no bearing on the applet's privileges. The use of a file chooser seems to imply that only the chosen file will be affected, when in fact a malicious applet could abuse its "access to all files" privilege to overwrite any file.

4.2. Unix File Permissions top

Unix file permissions are insufficiently expressive because it is impossible to share a file with a single other user. Files are assigned a single owner and a single group; permissions can be specified for the owner, for the group, or for all users, where group membership can only be defined by the system administrator. If Ngaire wants to share a private file with Ann and Bob, a new group with members Ann, Bob and Ngaire will need to be specially created. The system administrator isn't likely to create a special group each time a user wants to share files with a new combination of people. The alternative to defining a new group for each situation is to share the files with all users on the system, which makes a private file more public than desired. The less secure option of sharing with everyone is more convenient than the secure option of sharing with just Ann and Bob because individual users have insufficient expressive power to describe their security policy.

4.3. Namespace Collisions top

When objects are referenced by name, non-unique names can cause confusion. A global namespace increases the likelihood that multiple objects will have the same name.

Unix system administrators and users are often strongly warned against putting the current directory in their path. Unix has a security vulnerability in the way that commands are specified because commands are not uniquely identified; if there are two commands with the same name on the system and one is malicious, it is possible that the malicious command will be invoked instead of the safe command. To run a command such as "ls", all of the directories in the PATH variable are searched in order for an executable file called "ls". For instance, the directory /bin (which contains "ls") will be part of the path as it contains many commands that are not built into the shell. In order to execute a command such as a shell script located in a directory not in the path, users must explicitly specify the full path of the directory where the command is located.

The contents of directories in the path are usually trusted. To avoid specifying the current directory, the path is sometimes set to include ".". This introduces a vulnerability, since if the user is in a directory that happens to be writable by all users, any file in the current directory may be executable and untrustworthy. A malicious user could create a shell script called "ls" that deletes all files on the system and place it in a writable directory; when a user changes into that directory they may inadvertently execute the malicious version of "ls", erasing every file on the system for which they have write permission. Placing "." last in the path makes it more likely that the correct version of "ls" will be found first, but naming the malicious file "lss" or "dir" can still cause a common data entry error to execute malicious code.

Although this is a specific example in one operating system, it provides motivation for avoiding such discriminability problems in general. This can be achieved by avoiding referencing objects by name at all, or enforcing unique names when names are absolutely necessary. Referencing objects directly, rather than only by name, is preferable from a usability standpoint because recognition is easier than recall.

4.4. E-mail and Macro Viruses top

The "Melissa" virus was first reported on 26 March 1999 and within three days it had infected more than 100 000 computer systems [CA-1999-04]. Despite widespread publicity about Melissa and increased demand for computer security measures, most computers remained unprotected. Over a year later, in May 2000, a similar virus known as "Love Letter" spread even more rapidly; it was estimated to have infected millions of computer systems within just a couple of days [CA-2000-04]. The Love Letter virus did much more damage than Melissa, infecting and destroying most of the image and music files on each machine.

The permissive nature of Windows made it trivially easy for these viruses to infect other files and computers. Here are some of the privileges abused by these viruses, none of which are necessary to the typical operation of an e-mail client:

Upon a request from the user to examine an attachment, the enclosed script or macro was given permission to execute.
The executing script or macro was given permission to discover all the files on the machine and overwrite any of them.
The executing script or macro was given permission to read the Microsoft MAPI address book.
The executing script or macro was given permission to command Microsoft Outlook to send out mail.

Item 1 is a violation of the principle of certainty. The recipient did take explicit action to see the contents of the attachment, but was misled about the potential consequences. In the case of Melissa, the attachment was just a Microsoft Word document, and few users were aware that a document could actively damage the system upon being opened. In the case of the Love Letter worm, the operating system hid the ".vbs" extension on the filename "LOVE-LETTER-FOR-YOU.TXT.vbs" so that the attached file appeared to be a text file; again the recipient had no obvious warning that opening the file could damage the system.

Items 2 through 4 were violations of the principle of explicit privilege. A typical e-mail message never needs to be given the ability to trigger the transmission of further mail, yet the e-mail client granted these permissions freely to the attachment without any explicit action from the user. Neither the e-mail client nor Microsoft Word need permission to overwrite arbitrary files at all, and the operating system should not have granted them this permission without explicit action from the user.

4.5. Software Installation and Maintenance top

Today it is common practice on most end-user systems to treat the installation of device and network drivers as a form of electronic Russian Roulette. After a user downloads software components or purchases hardware with packaged software drivers, the installation process is a complete mystery. There is little or no indication what resources are being given to the new drivers, what global settings are being modified, or how to restore the system to a stable state if the installation fails.

The designers of software are typically most concerned with making their own software work well, and are less worried about damaging the functionality of previously installed (and possibly competing) software. As a result, the installation of new software often destroys configuration parameters that the user may have taken great pains to set up, and can leave the system in a state where some hardware devices can no longer be used with any other applications. Frequently the only recourse that users have is to try to guess what settings might be changed and write them down on paper in advance.

Software packages should not be able to take over hardware control without the user's permission. This is a violation of the principle of explicit privilege. Just as important is the user's ability to audit and revoke privileges so that he or she can confidently restore the system to a working state. It may not be a reasonable option to refuse privileges initially, so the granting of privileges must be reversible. This is the principle of revocability.

Ultimately the user must retain control over the system's resources, and decide which software gets to control what. Multiple software products that want to use the same resources should be able to coexist in such a system, where the user can easily switch from one to another. To do so, the user must be able to know where that control lies, and to revoke and reassign it at will.

4.6. Invisible Background Processes top

All currently popular operating systems make it possible and easy for programs to run "in the background" in a way that is invisible to the typical user. Although there is usually a way to determine the list of running processes, explicit action is required. Hence the user must first suspect the existence of a potentially harmful process before he or she can discover and disable it.

One of the most widely publicised examples of a potentially harmful background process is the "Back Orifice" program released by a group named Cult of the Dead Cow in mid-1998. Back Orifice can be used to remotely control a computer running Windows, including capturing keystrokes and images of the screen and transmitting or modifying its files. Microsoft responded to concerned customers with a security bulletin claiming that Back Orifice "does not expose or exploit any security issue regarding Windows, Windows NT, or the Microsoft BackOffice suite of products" [MS98-010]. The bulletin further implied that the user is responsible for evaluating the security consequences of any software they download or install. This reflects a narrow, developer-centric point of view. The expectation that one will never make any mistakes while installing or configuring software is clearly unreasonable, even for the most experienced system administrators.

Despite the claim in the bulletin, there certainly is a "security issue regarding Windows" demonstrated here. The issue is one of visibility: Windows freely allows programs like Back Orifice to run in the background and offer control of the user's machine to an outside attacker, without ever making the user aware of the program's existence. In the hypothetical situation where a user steps away from their computer for a moment and a prankster installs a program like Back Orifice, or where a user is tricked into installing something unintentionally, a system following the principle of visibility would make apparent that something has changed.

4.7. Java Security in Netscape top

Since version 3.0, Netscape Navigator has managed security for Java applets by allowing the user to grant and deny what are alternately called "privileges" or "capabilities" in the Netscape documentation. Before an applet is allowed to perform potentially dangerous operations, such as connecting to the network or accessing local files, it must first activate an associated privilege with an enablePrivilege(...) call to Netscape's SecurityManager. This usually causes a dialog box to appear asking the user to grant the privilege in question, as in Figure 2.

Figure 2. Applet requests a privilege by calling enablePrivilege("UniversalFileAccess").
Even though in practice the applet may only need to read or write a single file, the user is forced to grant permission to all the files on the entire system or nothing at all. This is a severe lack of expressiveness, for it reduces the user to choosing between uselessness and insecurity.

The dialog is vague about the consequences of the user's decision. What program is going to receive the privilege, and how long will the privilege last? If the user chooses "Remember this decision", exactly what decision will be recorded, and how long will it stay in effect? If the user grants or denies the privilege now, how is the decision reversed later? As it turns out, choosing "Grant" gives the privilege to all scripts and applets from a given source, from now until the end of the Netscape session, without any further permission from the user. If the "Remember this decision" box is checked, the privilege lasts indefinitely, and is automatically granted to all programs from this source in all future Netscape sessions. There is a lack of certainty, because the user can't make a reasonable decision without knowing the results of each choice.

Further, the user can't be certain that the program is really from Bogus Appletwriters Incorporated, as the certification details are obscured at the bottom of the window. Even if the window is resized, the user interface toolkit rearranges the widgets in the window to match, so the text remains obscured. This could be considered merely a programming bug, but it should be noted as a subtle security consequence of cross-platform user interface design.

Figure 3. Editing privileges.

Suppose that the user wishes to change the privilege settings for programs from Bogus Appletwriters Incorporated. After some privileges have been granted, the interface for editing privileges looks like Figure 3. Each privilege can be in one of three lists: "Always" (privileges that are always granted), "For this session only" (privileges that are automatically granted only for the remainder of the session), or "Never" (privileges that are automatically denied).

Figure 4. Deleting a privilege.
If the user selects the "Reading information..." privilege and clicks "Delete", a confirmation dialog appears (Figure 4). The sentence says that the privilege will be deleted "for all applets and scripts from Bogus". Yet the actual effect is to delete this privilege from the list of privileges automatically denied: that is, it will become possible to grant the privilege in future. There is uncertainty about the consequences of this decision -- the interface is unclear and misleading.

4.8. Code Signing top

Some systems aim to provide security by verifying the origin of a piece of untrusted code with a digital signature. Although the cryptography behind code signing is perfectly sound, few users ever check the validity of certificates on downloaded code in practice. This is a case of the cost-benefit principle in action: it is often too much effort to even look at the certificate, let alone attempt to verify the fingerprint to ensure that it matches the correct public key of the claimed certifying authority. Whatever benefit there might be to verifying the source of untrusted code, it is not perceived as significant enough to be worth the trouble. The design of a system cannot be founded on an unsubstantiated assumption that users will always use it conscientiously.

5. Design of a Secure Desktop Interface top

To show how the preceding principles can be applied in practice, we present our design for a hypothetical desktop interface that helps users to manage security privileges in a safe and clear way. The visual appearance of the interface is similar to that of Microsoft Windows in order to minimise the amount of training users would need to move to a new working environment.

The system is designed around a capability-style model for security privileges. Although capability-based operating systems have been previously deployed, the end-user interface has traditionally been the command line [Gnosis CL, KeyKOS CL84]. To our knowledge, this is one of the first attempts to design a graphical interface for a capability-based system. In the design of secure system, the particular abilities that are not present can be just as important as the abilities that are present. The system design is analysed in terms of the usable security principles given above.

5.1. Installing and Launching Applications top

Figure 5. Installing a hypothetical "Jukebox" application.

We draw a clear distinction between running instances of an application, application factories (installed software that has the potential to create running instances), and installers. Before users install an untrusted application, the downloaded code is visible as an installer icon with no privileges at all (Figure 5). Upon activating the installer, the user is asked to provide a directory where the installer will unpack the software files and place a new application factory. Write access to the specified directory is granted to the installer, and read-only access is granted to the application factory.

The system maintains a local mapping of applications to unique names for each user. When software is installed, the user is asked to confirm or provide a name, and names already bound to other applications are rejected. If a user wants to use an application installed by someone else, they must explicitly bring the application into their local namespace and provide a name. Each running instance of an application also gets a new, unique name. (These names are an example of Mark Miller's "Pet Names" concept.)

Figure 6. Launching the unprivileged "Jukebox" application factory for the first time.

Figure 7. Editing the privileges held by Jukebox Factory #1.

Activating an application factory icon is a message to the factory to create a running instance of the application. Because the application factory initially has no capabilities, any capabilities that are needed by the running instance are requested from the user in a dialog box generated by the system (Figure 6). After selecting privileges to grant, the user can create a new factory that carries these privileges and can launch an instance with them in future. The user can also examine and change the privileges associated with a factory (Figure 7). Application installers have distinct icons and names to distinguish them from application factories so that users are aware that the application installer has no capabilities.

Some applications will want to write state to preference files that will persist from session to session, and require a read-write capability to a particular file when launched. By setting up the privileges for different factories, multiple users can use the same application (or a single user can use an application in different contexts) without conflicts. Different factories will instantiate applications with different capabilities and hence different preferences.

Documents can be associated with application factories so that activating a document will instantiate the application factory with a capability to open the document. Running instances of an application have a capability to launch their factory that they can associate with documents that they create. Untrusted documents downloaded from elsewhere must be associated with applications explicitly by user selection from a menu of the local names for application factories.

5.2. Window Management top

Each running application instance has exactly one window, providing a single locus of control. To open two documents simultaneously one simply starts two independent instances of the application. Each application instance only sees one rectangular frame buffer in memory where it can draw, and cannot gain access to the contents of other windows. This protects private data and eliminates a covert channel. The position, size, and overlapping of windows is all managed by the system. The system controls the window borders and provides a close button on each window that terminates the corresponding application instance. The borders on windows provided by the operating system have a special appearance. In order to prevent window spoofing, the system enforces that the local name of the application instance appear in the title bar. Exactly one window is designated at any time to receive keyboard input; windows can only gain the keyboard focus by user request or intervention of the operating system. Hence, application windows are unable to capture sensitive data during typing. If an application wishes to get the focus, the attention of the user can be gained by flashing the related icon on the task bar.

5.3. Granting Privileges top

Figure 8. A running instance of the "Editor" application requests a file capability.

For an application to create new application instances or use sound devices, files, printers, the network, or any other resources, the user must explicitly grant capabilities to the application. To gain capabilities the application makes a request to the system and the system asks the user by presenting a dialog box. Icons representing capabilities can be dragged and dropped onto the capability dialog, or a file chooser style dialog may be used. The system dialog box is graphically linked to the application window so that users do not grant permissions to the wrong application. An attempt to fake a system dialog box isn't sufficient to obtain any capabilities, but since there is the danger of habituating the user to grant privileges without thinking, we enforce a distinct appearance for privilege-granting dialogs.

In order to provide a reasonable granularity of capabilities, read and write access will be controlled to individual files and directories separately. Access to input and output devices can be given individually, or aggregated by function using a proxy object. For example, permission can be given to send documents to a "printing service" object whose job is to forward the document to a selected default printer. This lets users build abstractions that reduce the amount of granting and revocation they have to do.

5.4. Reviewing and Revoking Privileges top

Figure 9. The user has pointed at the speaker device to see the list of holders of audio output privileges, and clicks on the list to get a dialog for editing permissions.

Running applications are represented by icons on the taskbar and devices appear on a pop-up bar at the right edge of the display. Applications are represented on the taskbar even if they do not have windows, in order to prevent resources being used without being visible. Pointing at an object such as a factory, running application, file, or device shows a list of capabilities held by or to that object. Arrows are shown to illustrate the relationship between the holder and the resource. If there is no currently visible icon representing a particular object on one end of the capability, then the arrow indicates the smallest visible folder that contains it.

Clicking on the pop-up list brings up a system dialog for changing or revoking privileges. Revocation and editing of permissions can occur at either the holder or the resource.

6. Conclusion top

Since communication of intent is essential to security, the user interface is a key component for achieving computer security. We have examined the security consequences of usability issues and arrived at a set of seven basic design principles that we hope can guide the development of user interfaces for truly secure systems. We have tried to test these principles in concept by applying them to the design of a secure desktop interface for a capability-based system that aims to achieve security while providing as familiar and convenient a user experience as possible. Possible future work includes usability testing on such an interface to compare its security properties with those of existing interfaces, in particular those for access-control-list-based systems.

7. Acknowledgements top

We would like to thank Verna Arts, Tal Garfinkel, Norm Hardy, Mark Miller, Marc Stiegler, David Wagner, and David Waters for their wisdom and valuable help with this paper.

8. References top

[CA-1999-04] "CERT Advisory CA-1999-04 Melissa Macro Virus", http://www.cert.org/advisories/CA-1999-04.html, 27 March 1999.

[CA-2000-04] "CERT Advisory CA-2000-04 Love Letter Worm", http://www.cert.org/advisories/CA-2000-04.html, 4 May 2000.

[Gnosis CL] Gnosis Command Language Reference, http://www.agorics.com/KeyKos/Gnosis/165.html, KeyKOS design documents.

[GS96] S. Garfinkel and G. Spafford, Practical UNIX and Internet Security: Second Edition, O'Reilly & Associates, Inc., 1996.

[KeyKOS CL84] User's Guide to the CL84 Command Language, http://www.agorics.com/KeyKos/Gnosis/166.html, KeyKOS design documents.

[MS98-010] Information on the "Back Orifice" Program, Microsoft Security Bulletin MS98-010, http://www.microsoft.com/technet/security/bulletin/ms98-010.asp, 12 August 1998.

[Nie94] J. Nielsen, "Enhancing the explanatory power of usability heuristics," Proceedings of the ACM CHI '94 Conference, April 1994, pp. 152-158.

[SS75] J. H. Saltzer and M. D. Schroeder, The Protection of Information in Computer Systems, http://web.mit.edu/Saltzer/www/publications/protection/index.html, Proceedings of the IEEE 63, 9, September 1975, pp. 1278-1308.

[Wer23] Untersuchungen zur Lehre von der Gestalt II , in Psychologische Forschung, 4, pp. 301-350. Translation in Ellis, W. (1938) A source book of Gestalt psychology, pp. 71-88. London: Routledge & Kegan Paul.