next up previous
Next: First Approach: Capabilities Up: Approaches Previous: Approaches

Subsections

Common Underpinnings

  Security mechanisms can be defined by how they implement interposition: the ability to protect a component by routing all calls to it through a reference monitor. The reference monitor either rejects each call, or passes it through to the protected component; the reference monitor can use whatever policy it likes to make the decision. Since a wide variety of policies may be desirable, it would be nice if the reference monitor were structured to be extensible without being rewritten. As new subsystems need to be protected, they should be easy to add to the reference monitor.

Traditionally, extensible reference monitors are built using trusted subsystems. For example, the Unix password file is read-only, and only a setuid program can edit it. In a system with domain and type enforcement [2], the password database would have a type that is only editable by programs in the appropriate domain. In either case, the operating system has no a priori knowledge of the password database or password-changing utilities, but instead has security mechanisms general enough to protect the data by only allowing a small number of programs access to it. Clark and Wilson [7] offer a particularly cogent argument in favor of the use of trusted subsystems and abstraction boundaries in the security of commercial systems.

Digital Signatures as Principals

  To implement any security policy, Java needs a notion of principal. In a traditional operating system, every user is a principal[*]. For Java, we wish to perform access control based on the ``source'' of the code, rather than who is running it. This is solved by digitally signing the applet code. These signatures represent endorsements of the code by the principal who signed it[*] asserting that the code is not malicious and behaves as advertised. When a signature is verified, the principal may be attached to the class object within the JVM. Any code may later query a class for its principal. This allows a group of classes meant to cooperate together to query each others' principal and verify that nothing was corrupted.

There is no reason a program cannot have multiple signatures, and hence multiple principals. This means we must be able to combine potentially conflicting permissions granted to each principal, much as a traditional operating system must resolve permissions when a user belongs to multiple groups. One way to solve this problem is to choose a dominating principal, generally the principal about whom the user has the strongest feelings, and treat the program as though it were signed only by the dominating principal. Some systems also define an algebra for combining policies.

Policies and Users

  Each system needs a policy engine which can store security policy decisions on stable storage, answer questions about the current policy, and query the user when an immediate decision is necessary. The details of what is stored, and what form user queries take, depend on the specific abstractions defined by each system.

To clarify the policy engine's role, consider the file system protection mechanisms in Unix. The ``policy decisions'' in a Unix file system are the file permission bits for each directory and file; these are stored on disk. The role of policy engine is played by code in the kernel that maintains the permission bits and uses them to decide which file access requests to allow.

In Java, a critical issue with the policy engine is how to help non-technical users make security-relevant decisions about who they trust to access particular resources. To simplify the user interface, we want to pre-define groups of common privileges and given them user-friendly names. For example, a ``typical game privileges'' group might refer to specific limited file system access, full-screen graphics, and network access to the game server. Such groupings allow a single dialog box to be presented to a user which does not burden the user with a long series of individual privilege decisions and their corresponding dialog boxes.

Site Administration

  Another way to remove complexity from users is to move the work to their system administrators. Many organizations prefer to centrally administrate their security policy to prevent users from accidentally or maliciously violating the policy.

These organizations need hooks into the Web browser's policy mechanism to either pre-install and ``lock down'' all security choices or at least to pre-approve applications used by the organization. If an organization purchases a new product, all users should not be burdened with dialogs asking them to grant it privileges. Likewise, if a Web site is known to be malicious, an administrator could block it from ever asking any user for a privilege.

Both Netscape and Microsoft have extensive support for centralized policy administration in their Web browsers. While malicious users may not necessarily be prevented from reinstalling their Web browser (or operating system) to override the centralized security policies, normal users can at least benefit from their site administrators' work to pre-determine which applications should and should not be trusted.


next up previous
Next: First Approach: Capabilities Up: Approaches Previous: Approaches
Dan Wallach
7/26/1997