Flexible Control of Downloaded Executable Content

By Trent Jaeger, Nayeem Islam, Rangachari Anand,
Atul Prakash, and Jochen Liedtke
IBM Research Division

Abstract

We present a system for managing the execution of downloaded content according to flexibly-defined security policies. Downloaded executable content consists of messages downloaded from remote hosts that contain executables that are run on the downloading principal's machine upon receipt. Since executables run by downloading principals have their full protection domain by default, executable content must be controlled to prevent unauthorized access to the downloading principals' resources. Current systems attempt to control content using a fixed security policy designed for standalone content, but these policies are inappropriate for several applications. For example, current content-loading policies do not account for the fact that content from multiple hosts may be combined into one application. In this paper, we describe a downloaded content execution system that can enforce a variety of security policies covering content download, content protection domain derivation, and content authorization. This system enables privileged principals to define the decisions that less-privileged principals are allowed to make. For example, system administrators can define legitimate authentication policies for applications, and application developers can define when the downloading principal's rights can be delegated to other application participants (within limits set by system administrators). We show how policies for collaborative applications can be defined and enforced. Also, we describe and compare three implementations of the system.



Table of Contents


Introduction

The invention of downloaded executable content (messages that contain programs that are executed upon receipt) is enabling the emergence of many new applications. Examples of executable content include Java applets [23], Tcl scripts [42], computational e-mail messages [11], and replicated process messages [31]. In most cases, executable content is implemented using a powerful language that can display user interfaces, engage users in a dialogue, return the results to the content provider, etc. A key feature of these languages is that the content messages can be automatically downloaded to a wide variety of platforms and executed without recompilation. This technology is particularly useful in some emerging distributed applications, such as electronic commerce, network information services, collaborative systems, and workflow systems, where the user might run the application only once or where the application actions are generated dynamically.

As has been noted previously [10], a major problem with executing downloaded content is that, if unchecked, it can enable attackers to gain unauthorized access to the downloading principal's system resources. Thus, content interpreters attempt to enforce control of content operations. However, current content interpreters' security models are either too rigid to build complex systems (e.g., Java-enabled Netscape, ATOMICMAIL, Safe-Tcl, and Java appletviewer [10, 11, 14, 28]) or require the ad hoc development of security infrastructure for each application (e.g., Telescript, Inferno, and Tcl [15, 33, 50, 53]). For example, Java-enabled Netscape prevents all I/O except communication back to the source IP address. On the other hand, Tcl provides the ability to compose systems from safe and trusted interpreters, but much skill is required to compose a secure system from these components.

Recent work attempts to address these shortfalls while also preventing the discovered security flaws [14, 38]. These systems authenticate downloaded content and generate protection domains for them [19, 29, 46, 52]. However, each of these systems provide mechanisms that enforce a specific security policy. Therefore, each system is limited by the restrictiveness of its policy. For example, all these systems assume that content is used as a stand-alone program. Therefore, content from multiple hosts cannot be used in one application, and replay attacks are not detected. If the downloading principal maintains shared state for a content application, then replay attacks are a significant issue. In addition, the derivation of content protection domains is forced either on the user or system administrators. However, users are not likely to be trusted to make all access control decisions. Also, system administrators do not want the extra job of specifying protection domains nor do they understand the semantics of the applications completely. Therefore, downloaded content execution systems need to provide the flexibility to ensure that the security requirements of their applications can be specified properly and that these requirements can be enforced by the system.

The contributions of this paper are to (1) define a flexible representation for security policies that enables control of downloaded content, (2) define general mechanisms that can use these policies, and (3) describe implementations of systems that use such policies to control downloaded content. We first identify the types of security policies that downloaded content execution systems need in order to control content. We define a general policy representation, called a policy graph, to represent such security policies. System administrators can use such a representation to define authentication, execution, and protection domains requirements that limit users and applications. However, users and applications may have some flexibility for defining how the content they use is restricted within those limits. We define general mechanisms that use such policies to control content. We describe how our system can be used to specify and enforce example policies motivated by the requirements of collaborative applications. We then outline three implementations of our system: (1) using Tcl version 7.5, (2) using Java version 1.1, and (3) using a operating system level implementation.

Throughout this paper, we will assume a conventional protection model, where principals (e.g., users, groups, and services) execute processes that perform operations (e.g., read, write, and execute) on objects (e.g., files, URLs, and communication channels). The permissions of a principal to perform operations on objects are called the access rights of the principal or the principal's protection domain.

The structure of this paper is as follows: In Section 2, we define the problems in flexible control of downloaded executable content. In Section 3, we define an architecture and general mechanisms for solving these problems. In Section 4, we detail how policy can be added to the architecture to control a specific application that uses downloaded executable content. In Section 5, we discuss our experiences in building flexible content execution systems into the Tcl interpreter model, the Java virtual machine, and an operating system for controlling downloaded content. In Section 6, we make a comparison of our architecture to related work. In Section 7, we summarize and present future work.

Return to Table of Contents

Problem Definition

We envision distributed applications built using downloaded content to range from (1) simple applications that retrieve input entered by the downloading principal to (2) complex applications in which content conveys individual operations on behalf of its providers. The security requirements of each of these application models vary in significant ways. For example, consider authentication. Traditional applets are small, self-contained applications, so only their source and integrity need to be verified. However, in an application that is implemented by asynchronously-interacting content, the downloading principal may maintain some shared state, so replay attacks must be detected to prevent unauthorized modifications of this state. Also, consider protection domain management. An application's protection domain depends on the application and the way it is being used. For example, collaborators should only have access to the objects that the downloading principal has made available for the collaboration. Therefore, applications need the ability to constrain content protection domains. However, applications implemented by content may still be constrained to enforce least privilege.

figure400
Figure 1: Simple downloaded content execution architecture

We first consider the security requirements of a single interaction using downloaded content as shown in Figure 1. A downloading principal is the principal that receives and executes the content. A content provider is the principal that is responsible for the content. A server is a principal that stores and administers access to a set of objects (e.g., files, communication channels, application objects). A downloaded content execution system works basically as follows: First, the downloading principal gets (e.g., HTTP get) content from the content provider's server (often using an untrusted network, such as the Internet, as indicated by the dotted line). Next, the downloading principal creates a content process. The content process is then executed. It may request operations from various servers. In general, these servers may be local or remote (only a local server is shown).

Servers store protection domains for each downloading principal in order to control the operations that they can perform on server objects. However, downloading principals typically do not trust content providers with all their rights. For example, downloading principals would like to prevent content from (1) reading their private files, (2) writing executable files, (3) monopolizing their system's CPU, and (4) communicating with unauthorized principals. Unfortunately, traditional operating systems do not provide a mechanism for principals to dynamically restrict the access rights of one of their own processes. In addition, recent systems that permit dynamic restriction of rights (e.g., based on Role-based Access Control (RBAC) models [5, 20, 51] or controlled execution systems [21]) require that these limited domains be pre-specified, which can result in larger domains than desired for a single content execution. For example, a RBAC domain for an application would have to encompass all rights that any individual use of the application would ever need. Other systems explore the alternative where users specify protection domains themselves [7, 29], but most users cannot be trusted to make such decisions correctly.

figure416
Figure 2: A more complex application implemented using downloaded content

More complex applications can also be implemented using downloaded content. Consider a collaborative application in Figure 2. Downloading principals retrieve the content for implementing their role in the collaboration (application content) as in the first example. They use this content to access their system objects as necessary to implement the collaboration. For example, a collaborative editor would need access to the files that the downloading principal may permit collaborators to edit. However, in this application, actions are implemented by downloading them to each collaborator. Therefore, collaborator content can interact asynchronously with the downloading principal's collaborative editor to modify documents. The collaborators must be limited to perform only the operations that the downloading principal has permitted them to perform. For example, in a collaborative editor, only the files that the downloading principal has loaded to be collaboratively edited should be writable by other collaborators. Also, different content may use a different protection domain depending on its provider. For example, some collaborators may be permitted only to read the files, but not to write them.

Also, attackers, including content providers themselves, may be present during the computation. We assume an attacker is a powerful adversary that can read, modify, and delete any message sent between the content provider and the downloading principal. Also, attackers can generate new messages. Therefore, it must be possible to verify the source, integrity, and freshness of downloaded content. In addition, privacy and non-repudiability of content messages may be required for some applications, such as electronic commerce.

The flexible control problem is to define and enforce a limited protection domain for downloaded content commensurate with its resource needs and the downloading principal's trust in the content providers. We identify three subproblems of the flexible control problem:

  • Download: Verify that the downloading principal can execute the downloaded content.
  • Protection Domain Derivation: Derive a protection domain for this content.
  • Authorization: Enforce and manage the content's protection domain throughout its execution.

Content download verifies that the content can be executed by the downloading principal. This verification can consist of a verification of the security requirements of the content communication (e.g., integrity and freshness are preserved) to identify the content source and verification that the downloading principal is permitted to execute the content (e.g., is from a trusted provider or has an acceptable PICs rating [43]). Content download must load the content properly, so that it can be controlled.

Next, the protection domain for the content must be derived. For downloaded content, this domain can be dependent on (1) the trust in the actual providers of the content, (2) the application in which the content is used, (3) application status, and (4) the purpose of the content in the application. It is difficult for end users to dynamically derive a protection domain that adequately protects system resources from the myriad of attack possibilities. However, predefined domains (e.g., based on roles) do not provide the flexibility to limit privileges based on the application status.

Finally, the content interpreter and any services it uses must be able to enforce the domain specified above for all downloaded content. First, the system must determine the actions that will be controlled. Next, the controlled operations must be authorized to determine if they are permitted by the derived domain. To prevent denial-of-service attacks, statistics about the usage of services need to be collected. Also, the use of supporting content components supplied by other principals may result in a change in protection domain to reflect the rights entrusted to that component. Downloading principal actions may result in the need to modify the derived protection domain. Lastly, the use of native software may be desired, so the ability to transfer limited protection domains is needed to enable other systems to control native software (e.g., Janus& [21]).

Return to Table of Contents

Architecture

In the design of an architecture for controlling downloaded executable content, we make the following assumptions: First, we assume that content and native software only have access to a well-defined set of commands to perform I/O. Second, the operating system is trusted to properly perform the operations of a trusted computing base (TCB), such as cryptographic operations, address space separation, and system call authorization. Without trust in the operating system's TCB, it is not possible to build trusted applications that run on it. A secure booting mechanism, such as provided in Trusted Mach [49], is designed to satisfy this requirement (among others). However, any means sufficient for this assumption to be made can be used. Lastly, we assume that all system services that content uses can be authenticated (or access is denied).

The trust model of our system is defined from the downloading principal's perspective. The security issues of the content provider are outside the scope of this paper. The downloading principal trusts servers to handle the objects it manages properly. It is assumed that servers never behave maliciously; however, errors are possible. Any certifying authorities are trusted by all principals. The downloading principal trusts the content provider with the rights that the content provider is granted. However, a content provider may try to obtain unauthorized access rights using all methods available to an attacker (e.g., read and modify network traffic).

figure435


Figure 3: Downloaded content execution architecture: (A) download content, (B) derive protection domain, and (C) authorize server operations.

The downloaded content execution architecture (shown in Figure 3) introduces three types of special servers: (1) download servers, (2) protection domain derivation servers, and (3) authorization servers. These three types of servers manage and enforce security policy at three different levels of granularity. The download server is invoked upon each get operation by the downloading principal (Figure 3 (A)) or content provider downloads (as in a collaborative activity). It determines whether to execute the content based on its authentication and execution criteria. The protection domain derivation server is invoked upon a derive operation from the download server or authorization server (Figure 3 (B)). It computes the content protection domain and the policy for managing that domain. The download server selects an authorization server to enforce and manage the content protection domain (Figure 3 (C)). The authorization server is invoked when content calls a server operation. It intercepts these operations, authorizes them using the current content protection domain, and applies any relevant policy (e.g., delegation to the callee).

figure449
Figure 4: Protection domain derivation: Content executes with the current protection domain, but may be delegated rights within transform delegation domains as long as those rights are within the maximal protection domain.

A second view of the architecture is that of a system for managing and enforcing content protection domains. The model of protection domain management is shown in Figure 4. The download server uses its policy to authenticate the content provider and verify that the content meets the requirements for executing it. The protection domain derivation server uses its policy to determine the content's current protection domain and the default maximal protection domain. The derived current protection domain is the content's initial protection domain, and the maximal protection domain defines all the rights that the content can ever be granted. Users can extend the default maximal protection domain of the content they run within limits. The current protection domain can be extended within the limits of the maximal protection domains using transforms, objects that associate an operation with a protection domain modification. Transform delegation domains limit the rights that a transform can delegate. For example, when the downloading principal opens a new file in a collaborative editor, a transform associated with the open operation can add the file to the content provider's protection domain. The authorization server authorizes operations against the current protection domain and executes transforms that are limited by the transform delegation domain and the maximal delegation domain. Note that unlike other approaches (e.g., Netscape signed code [52]), content cannot delegate rights to itself, so the authorization server can enforce least privilege on content.

figure463
Figure 5: Policy graph

The policy of the individual servers is represented using a data structure called a policy graph defined below:

  • Definition 1: A policy graph is a tuple, tex2html_wrap_inline1742 , where (1) p is a principal, (2) G is a directed graph, tex2html_wrap_inline1748 , where N is a set of nodes and V is a set of vertices, (3) tm, the traversal method, describes how the graph is traversed, and (4) cm, the combination method, determines how a node's value is combined with the current result.

A policy graph associates downloading principals with a directed graph that represents policy for handling content. An example policy graph for specifying content protection domains for the protection domain derivation server is shown in Figure 5. In this policy graph, each graph level corresponds to a content attribute (e.g., content provider and application type). Nodes store a mapping between content attribute values and the associated protection domain. Given content attribute values of provider=IBM and application type=games, the protection domain tex2html_wrap_inline1758 is found. The methods describe how the graph is traversed and how the policy values of the traversed nodes are combined. An example traversal method specifies that traversal starts at the root of the graph and repeatedly follows the child link whose node's attribute value includes the content's value for that attribute. The example combination method is the union set operator. A traversal that goes from the root to the IBM node to the games node results in the protection domain tex2html_wrap_inline1760 .

Note that Netscape content shares the same protection domains at the application type level as the IBM content in our example. Therefore, the resulting domain for a content identity of provider=Netscape and application type=games is tex2html_wrap_inline1762 .

This data structure enables the aggregation of policy for content that share a subset of their attribute values. Thus, the specification of policy can be reduced, and previously unseen content may be covered by default policies.

These three special servers are designed to provide general mechanisms for solving the three flexible content control subproblems. The general mechanisms use control policy and are represented using policy graphs to obtain flexibility. In the remainder of this section, we detail these general mechanisms and how they use policy. The goal of this section is to express the full generality of the servers. In Section 4, we demonstrate the servers using a specific policy. Obviously, the full generality of the servers is not needed in all cases, so Section 4 attempts to provide a view of the types of reasonable policies that specialize the servers. It should become clear that many policies, such as those implemented currently (e.g., Java appletviewer [24]) and some proposed by others (e.g. Netscape's signed code proposal [52]), are subsumed by our system.

Return to Table of Contents

Download Server

The download server determines whether to execute the content that it downloads. The content provider sends a content message to the downloading principal that includes the content and a content description. The content description consists of attribute-value pairs that are used (1) to derive the content's download policy from a policy graph stored by the download server and (2) to determine whether the policy is satisfied. A policy graph stores download policy which is expressed as predicates that must be fulfilled for content to be executed on the downloading principal's system. These predicates can express constraints about the execution environment, the description of the content, and the authenticity of the content. Lastly, the download server determines how to load the content to enable the authorization server to control it properly.

Categories Attributes Examples
Authentication Signature
MAC
Digest
Nonce
DSA [39]
MMH [26]
SHA-1 [40]
Sequence number
Descriptive Provider
Type
Name
PICs
IBM
Collaborative
UARC
category
Application Protection Domain
Transforms
Key distribution
Authentication
Access rights
Load grants read to P
Needham-Schroeder [41]
Require sign, digest, nonce
Table 1: Example content attributes and values for a content description

The download server receives content messages from the providers or content servers. They contain the content and a content description. The structure of a content description is shown in Figure 1. The content description is a list of attribute-value pairs that may include authentication information, such as digests and signatures, descriptive information (such as content provider and content names), and application-specific information (such as the protection domain request used in Section 3.2 and security requirements for other content).

Categories Predicates Arguments
Execution Requested_P
Running_P
Time_P
(d.content, dp)
(n, dp)
(current_time)
Descriptive Trusted_Provider
Content
Version
(d.provider, n)
(d.content, dp)
(d.version, n)
Authentication Signer
Verify
Digest
Fresh
(d.signer, n)
(d.signature, d.signer, d)
(d.digest, MD5, c)
(d.nonce, d.provider)
Table 2: Download policy predicates: d = the content description (with attributes content, version, signer, signature, digest, nonce, provider); c = the content; dp = downloading principal; n = content name; dc = content provider performing download on behalf of dp.

Download policy is a set of predicate sets where one set must be fulfilled (i.e., all predicates in the set evaluate to true) for the content to be executed. The structure of the predicates (i.e., number of arguments) can vary. Examples of such predicates are shown in Figure 2. There are three categories of predicates (these can be verified independently): execution, description, and authentication. Execution predicates indicate the conditions in which the downloading principal can execute the content. Description predicates determine the acceptable descriptions of the content (e.g., providers and versions). Authentication predicates indicate the criteria for determining the source, integrity, freshness, etc. of the content. This model can be combined with a trust management model for keys, such as PolicyMaker [9].

figure530
Figure 6: Download server protocol

The download server uses the content and content description to determine if it can execute the content and to identify the principal responsible for the content. The protocol implemented by the download server is shown in Figure 6. First, the download server retrieves the download policy using the content description as input to a policy graph traversal. The download server applies the authentication policy to the content description to determine whether the principal responsible for the content message can be identified. Note that an authentication policy may specify that content with no authentication information in its description is from a special principal called untrusted. The execution and descriptive policy are compared to the content description to determine whether the content can be executed. If both tests pass, the content download is successful. Otherwise, the download server signals an error to the application associated with the download.

Upon a successful download, the download server loads the content for execution. Loading policy indicates whether the downloaded content can be co-located with other content and indicates the impact on the protection domain of the combination. For example, a library component may be downloaded by content and co-located with it. Another example is that content from the same provider and for the same application may be co-located. The policy graph specifies the compatible content descriptions for the downloaded content. The resultant protection domain can be an intersection or union of the two components' protection domains.

Return to Table of Contents

Protection Domain Derivation Server

Protection domain derivation is a negotiation between the content provider and downloading principal to determine the rights that the content needs to complete its task without compromising the downloading principal's system. However, downloading principals may not be trusted to perform such a negotiation properly, so the protection domain derivation server can perform it on their behalf. First, it defines a common language for evaluation of protection domain requirements (i.e., access control model). The content providers are not expected to understand the organization of the downloading principal's system, so they express their protection domain requirements using logical objects. The protection domain derivation server maps logical objects to objects on the downloading principal's system prior to evaluation. The downloading principal's protection domain requirements are stored in a policy graph by the protection domain derivation server. The protection domain derivation server determines whether the requirements are compatible. Otherwise, the principals may need to modify their positions. At present, it is assumed that the content providers' positions are fixed, so only the downloading principals may modify their positions. User intervention may be required at this point, so restriction on the ways that users can modify their positions is necessary to prevent spoofing attacks.

The protection domain derivation server provides flexibility by (1) permitting protection domains to be specified in terms of logical objects and (2) defining ways in which protection domains may be modified. The use of logical objects in protection domains enables providers to define protection domain requests without knowing the exact organization of the downloading principal's system, and it enables downloading principals to limit the objects accessible to content. For example, a downloading principal can grant users of a collaborative editor access to loaded files. The downloading principal can decide which files have been loaded. In addition, the content's current protection domain can be expanded or contracted as specified by objects called transforms. A transform associates an operation with a protection domain modification. For example, when the downloading principal opens a new file in the collaborative editor, the file can be added to the set of loaded files. Like protection domain requests from content providers, transforms can also be limited to enforce least privilege.

A principal's protection domain is specified using the access control model defined below:

  • Definition 2: An object group is a set of objects of the same type (it may be a supertype of all objects).
  • Definition 3: Access rights of a principal are defined by a set of domain rights and exceptions defined below:
    • Domain rights: A tuple, tex2html_wrap_inline1766 , which describes a set of operations, tex2html_wrap_inline1768 , that the principal can perform on an tex2html_wrap_inline1770 of a specific type. The limit specifies restriction on number of times such an operation can be performed.
    • Exceptions: A tuple, tex2html_wrap_inline1776 , which describes a set of operations, tex2html_wrap_inline1778 , that the principal is precluded from performing on an tex2html_wrap_inline1770 of a specific type.
  • Definition 4: A transform is one of three types of tuples, object group transforms, operation transforms, or domain transforms:
    • Object group transforms: A tuple, tex2html_wrap_inline1784 , that, when this principal executes an operation in tex2html_wrap_inline1786 , describes a change in the relationship between an object obj and an object group tex2html_wrap_inline1770 ( tex2html_wrap_inline1792 is add or remove) for all principals. tex2html_wrap_inline1794 indicates whether the transform is applied before or after the operation.
    • Operation transforms: A tuple, tex2html_wrap_inline1796 , that, when this principal executes an operation in tex2html_wrap_inline1786 , describes a new domain right (if ops are allowed) or exception (if ops are precluded) to be added to the principal rcvr's current protection domain. tex2html_wrap_inline1794 indicates whether the transform is applied before or after the operation.
    • Domain transforms: A tuple, tex2html_wrap_inline1808 , that, when this principal executes an operation in tex2html_wrap_inline1786 , describes a change in the principal's protection domain specified by tex2html_wrap_inline1792 (one of intersect, union, or replace) relative to another principal's protection domain. These transforms are always applied before the operation.

In this model, objects can be aggregated into groups called object groups for expression of a common access control requirement. The access rights of a principal to these object groups are described by its domain rights and exceptions. A domain right describes the permission to perform a set of operations on an object group, and an exception precludes a set of operations from being performed on an object group. This model permits access rights to be defined concisely for a large set of objects while permitting some objects in the group to override those rights. Principals are authorized to perform an operation on an object if their protection domain contains (1) at least one domain right that permits the operation and whose limit has not been exceeded and (2) no exceptions that preclude the operation.

Also, developers can specify transforms that associate protection domain modifications with operations. These enable a principal's action to delegate rights to another principal, revoke rights from another principal, or revoke rights from itself. Transforms are motivated by Foley and Jacob's association of rights with collaborative activities [18]. A transform can be executed only if (1) the principal executing the transform has all the rights that are being granted or revoked by the transform and (2) the receiving principal is allowed to obtain the rights granted (within its maximal protection domain; see below). Object group transforms add or remove an object from an object group. This results in the other principals rights being modified based on their access to the object group. Operation transforms can add domain rights and exceptions to the receiving principal's protection domain. Domain transforms combine the domains of two principals when they interact. For example, the protection domain of untrusted principals can be intersected before they interact.

Content protection domains are derived using the protocol displayed in Figure 7. The protocol consists of three stages: (1) mapping the content provider's protection domain request to the downloading principal's system, (2) verifying that the request is satisfactory and can be controlled by the authorization server, and (3) resolving any conflicts.

figure575
Figure 7: Domain derivation protocol: (1) map the content provider's protection domain request to a mapped protection domain request, (2) retrieve maximal protection domain from policy database and intersect, and (3) users can grant additional rights from their transform delegation domains.

First, the content provider specifies a protection domain request for the content. The content provider should not be expected to know the structure of the downloading principal's system, so mapping functions are defined to convert logical objects in the request to physical objects on the downloading principal's system. For example, application files can be located anywhere in the downloading principal's file system. A mapping function derives their location when the application's content is downloaded. Mapping functions are stored in a policy graph that associates the content description with the mapping functions by object type and/or logical object name. The resulting domain is called the mapped protection domain request.

Next, the mapped protection domain request is compared to the maximal protection domain to verify that the domain request is acceptable. The maximal protection domain is the maximal set of rights that can be granted to the content. The protection domain derivation server derives the default maximal protection domain using the protection domain policy stored in a policy graph and the content description. If the mapped protection domain request is a subset of the content's maximal protection domain, then it is verified as acceptable. An acceptable, mapped protection domain request is the initial current protection domain. This is the domain that content operations are authorized against. Since the current content domain is a subset of the maximal content domain, access control model transforms can be used to add new rights as the actions of the downloading principal make them available.

If the mapped protection domain request is not acceptable, then the downloading principal may be permitted to grant the additional rights requested (i.e., expand the maximal protection domain). The protection domain derivation policy is queried using both the content description and the downloading principal as a delegator to derive the protection domain for the user to expand the maximal protection domain. The downloading principal may grant any rights to content within this protection domain.

The protection domain derivation server is designed to support a wide variety of security policies for downloaded content. However, this server does not require a large number of complex policies to be specified. For example, to implement the Java appletviewer security policy, a single content domain limit representing the properties file is specified. All content uses this limit, and there are no user delegation limits. Thus, we believe that policy graphs can be constructed incrementally, as content applications with new security requirements are added.

Return to Table of Contents

Authorization Server

  The authorization server authorizes operations destined for controlled servers using the content's current protection domain. Authorization servers obtain flexibility by (1) enabling content to be associated with an arbitrary protection domain, (2) representing the semantics of controlled operations, (3) collecting operation statistics for preventing denial-of-service attacks, and (4) managing the delegation of rights by and to content. Authorization servers use policy to obtain such flexibility. The current protection domains are the policy used to authorize content operations, and these domains can be associated with content dynamically. The authorization server stores the semantics of the controlled operations to enable it to authorize them appropriately. The limits in the current protection domain are used to prevent denial-of-service attacks, and the authorization server maintains usage statistics to compare to these limits. Transforms specify the policy for modifying current protection domains as operations are executed. Transform delegation domains and the maximal content protection domain limit the extent to which transforms can delegate rights.

figure592
Figure 8: Domain enforcement protocol: Content operations are intercepted by the authorization server that obtains the operation's authorization requirements from its operation object and authorizes it against its current protection domain. Any transforms are limited by the maximal protection domain and its transform delegation domain.

The authorization server mechanism is shown in Figure 8. When the content performs a controlled operation, the authorization server is triggered. Authorization servers map protection domains (including transforms) to content when the content is loaded, so they can authorize operations and manage protection domains. Note that protection domains may be derived in advance or lazily depending on the implementation. The authorization server maintains a representation of operations that it uses to map operation syntax to semantics, so authorization is possible. If authorized, operation data is collected, and transforms that must be executed prior to the operation are run. The operation is then executed by the authorization server. The authorization server receives the results of the operation. Before returning the results to the content, the authorization server executes any transforms that are to be executed upon completion of the operation. The domain in which a transform can delegate rights can be limited by its transform delegation domain. The results of the operation are then returned to the content. The authorization server may return handles (i.e., descriptors) to the results rather than the actual results to control future access.

The authorization of an operation depends on analysis syntax to determine its semantics. For example, a file open operation actually specifies the types of operations that are to be performed on the file (e.g., read, write, and append). It is these operations that must be authorized because all subsequent uses of the descriptor may only involve these operations. Therefore, we define a structure for representing the mapping from operation syntax to semantics called the operation object.

  • Definition 5: An operation object defines the authorization information for an object using the following fields:
    • Operation: operation reference (e.g., function pointer)
    • Server: Interpreter that executes the operation
    • Operand count: Number of operands
    • O Type: Object type for the operation
    • A Type: The authorization type of the operation
    • Authorization vector: A vector of function pointers for special authorization of operands (e.g., pointer values for read buffers)
    • Ops operand: Index of the operand that defines the operations to be authorized
    • Op vector: A vector of operations to be authorized indexed by the ops operand value above or the default value
    • Copy vector: A vector of function pointers for special copying of associated operands (default is an integer copy)
    • Size vector: A vector of function pointers for determining the size of operands for special copying (default is 4 bytes)
    • Transform vector: A vector of transforms to be applied when the operation is authorized

The operation field indicates a reference for executing the operation (e.g., string name and function pointer). The server field specifies the destination server of the operation. For example, a file system server supplies operations that enable access to file system objects. The operand count is necessary to create stub operations. The o type specifies the type of the first argument to the operation. The a type indicates the mechanism for authorizing the operation. Some operations may use our access rights for authorization, whereas others may use capabilities. Subsequent operands that need to be authorized are specified in the authorization vector (with their types and operations). The ops operand specifies the operand that determines the operation that is to be executed. For example: in an open, the second argument determines whether the open is for read, write, and/or append. At present, only one operand can specify the operations. The op vector maps the op operand's value to the operations to be authorized. The copy vector and size vector enable the authorization server to copy arguments into the server, so they cannot be modified after authorization. The transform vector stores all the transforms that are associated with the operation.

Once the arguments and operations requested upon them are identified, they can be authorized. The authorization mechanism is shown in Figure 9. The authorization method is called with a list of operation arguments (args) and the operations ( arg_ops) that are to be authorized for each argument. Typically, only the right to perform the operation itself on the first argument is authorized (i.e., the first argument in a method indicates the object for which the operation is intended). However, additional argument/operation pairs may protect the application from bugs or later, less graceful failures, particularly if the operation results in the execution of native software. To authorize this operation, the authorization server must be able to find the following for each object in args: (1) domain rights that grant the permissions to perform all its arg_ops, (2) that no exception exists which precludes any of arg_ops from being performed on that arg, and (3) that the operation limit has not been exceeded. Domain rights and exceptions are specified in terms of object groups, so it must be determined whether an arg belongs to an object group before the operations can be compared.

4=

authorize(args arg_ops)

     For arg in args, arg_type = arg.type(),

                                     ops in arg_ops

                 Find object_groups for arg and arg_type

                 Find domain_rights for arg_type

                 Find exceptions for arg_type

                 For d in domain_rights

                                     For o in object_groups

                                               If (d.object_group().includes(o))

                                                     If d.limit_exceeded() return FALSE

                                                     Add intersection of d.ops() and

                                                             ops to found_ops

                 If found_ops != ops

                           return FALSE

                 For e in exceptions

                           For o in object_groups

                                 If (e.object_group().includes(o)) {

                                        Add intersection of d.ops() and

                                               ops to found_ops

                                 If found_ops return FALSE

     return TRUE

Figure 9: Authorization mechanism

For operations that can be executed only a limited number of times, the authorization server must maintain statistics on that operation. Each entry in the current content protection domain may be annotated with a field that maintains the current usage count. Only the authorization server can modify this field.

An operation or principal may have a transform associated with it. A transform specifies a change in a principal's current content protection domain. The authorization server restricts transforms by only executing them if (1) the domain rights granted and exceptions revoked by the transform are within the calling principal's current protection domain, (2) any domain rights granted to the receiving principal are within that principal's maximal content protection domain, and (3) the transform's delegation domain. Only the authorization servers can modify the current content protection domains of content.

Return to Table of Contents

Example Policies

figure705


Figure 10: Implementation of Example Collaborative Activity (UARC): (1) download UARC content, (2a,b) derive protection domain and create authorization server, (3) register with UARC server, (4) inform collaborators, (5) collaborators download content for UARC, (6a,b) derive protection domain for collaborator content and create its authorization server, (7) grant rights to collaborator content based on downloading principal actions, and (8) authorize server operations of collaborator content.

In this section, we describe the policies required by an example application and how those policies are represented and enforced using our system. The example application is called the Upper Atmospheric Research Collaboratory (UARC) [17, 32]. UARC is a collaborative system for viewing, annotating, recording, and chatting about atmospheric test data. Our system supports the UARC application as shown in Figure 10. The downloading principal downloads the UARC content from a server (Number 1 in Figure 10). The UARC content is authenticated, a protection domain is derived for it, and an authorization server is created to control its use of system resources (2). The UARC content connects to a UARC collaboration server, so the downloading principal can join the UARC session (3). Other collaborators are informed of the downloading principal's presence in the collaboration, so they can send content to the downloading principal (4). Content from UARC collaborators is received by the download server and authenticated; it has a protection domain derived for it, and an new authorization server is created to control its operations (5 and 6). Future content from the same collaborator (or collaborators with the same role) is executed in the same collaborator "interpreter." An operation by the downloading principal to replay a recording results in that recording becoming available for collaborators to read and annotate (7). In addition, UARC content may execute an analysis package or read and write recording annotations on the downloading principal's system (8).

This application uses policy for (1) authenticating the UARC content, (2) authenticating collaborator content, (3) selecting the content interpreter to execute content, (4) limiting the UARC content and collaborators protection domains, and (5) limiting the domain in which the downloading principal can delegate rights to the collaborators content. We expect that system administrators specify the policy for authenticating UARC content, selecting the content interpreter and limiting the protection domains. Policy graphs are used to represent these policies. The policy selected is based on the content provider and application name. The UARC developers select the policy for authenticating collaborator content from a set of approved policies and specify the protection domains requirements for collaborator content based on categories of collaborators. This policy is expressed in the content description provided with the content. In the following subsections, we detail the policy required by the application and the way in which it is used by the servers.

All the servers use the same policy graph model. Each policy graph is a three-level graph with the following content attributes defining the levels: (1) content provider, (2) content type, and (3) content name. A policy graph query retrieves the policy of the policy graph node that most closely matches the values of the three attributes for our content (i.e., UARC and UARC-collaborator). The traversal method starts at the root (default policy) to find the node to which the content provider belongs. If no such child node exists, the traversal is complete. Of this node's children, the one to which the content type belongs (if any)is found next. Of the content provider node's children, the one to which the content belongs (if any)is found. The combination method overrides the current policy with the new node's policy, so the policy for the node that most closely matches the content description is used.

Return to Table of Contents

Download Server

The download server must verify that the UARC and collaborator content can be executed without compromising the downloading principal's system. For the UARC content, the download server must ensure that it

  1. must have been requested by the downloading principal
  2. must have a description with a valid signature from a trusted CA
  3. must be from a trusted principal
  4. must be UARC content
  5. must be an acceptable version
  6. must be unmodified.

The download server should not accept UARC content and execute it automatically. UARC content is only executed when requested. The content must be associated with a description that has a valid signature from a trusted CA. The valid content description must specify that the content is (1) from a principal trusted to provide UARC content, (2) named UARC content, (3) an acceptable version, and (4) unmodified.

For collaborator content to be executed, the download server must ensure that it

  1. must have an active UARC content executing on the downloading principal's system
  2. must be from a principal trusted to be a collaborator
  3. must be a current member of the UARC collaboration
  4. must be for UARC
  5. must be unmodified
  6. must be fresh (i.e., not a replay).

Content from UARC collaborators is executed only if the UARC content is being run. Otherwise, the downloading principal is not interested in the content. The collaborator content must be for UARC and must be from a trusted and current collaborator. Also, the content must be unmodified and fresh.

We use BETSI certificates [45] to verify the download policy of content, but other techniques can be used (e.g., PEM [6] as in FlexxGuard [4]) with a slightly different policy. When content is downloaded, an associated BETSI certificate and certificate signature are retrieved (e.g., using cert and sign keywords in the HTML file to identify remote certificate and signature URLs). BETSI certificates are generated by a trusted certification authority that is able to bind authors to certificates, so the information in the certificate can be assumed to be valid if the signature verification succeeds. We use a BETSI certificate with the following fields:

  • Identity of CA (signer)
  • Author Name
  • Application Name
  • Cryptographic Digest
  • Version
  • Authentication Requirements (per principal)
  • Protection Domain Requests (per principal)

The first five fields are used by the download server to verify that the UARC content satisfies its download policy. The last two fields are used to express policy for other content executed as part of the UARC application. Trusted UARC content providers are permitted to define authentication and protection domain requirements for UARC collaborator content. The specification of these requirements is limited, however. For authentication, one of a set of legitimate authentication policies must be specified. For protection domains, all collaborators' protection domains must be a subset of the UARC content's maximal protection domain (checked before entry into the policy graph).

The download policy for UARC content is specified by the following policy (using the predicates specified in Figure 2):

  • Requested_P(d.content, dp): Content is requested by the downloading principal (dp)
  • Trusted_Provider(d.provider, n): Content name (n) has been provided by a trusted provider (d.provider)
  • Content(d.content, n): Content (d.content) must have the same name as expected for the content (n)
  • Version(d.version, n): The content version provided (d.version) is an acceptable version for the content (n)
  • Signer(d.signer, n): The signer (d.signer) is authorized to sign content descriptions for the content (n)
  • Verify(d.sign, d.signer, DSA, d): The signature (d.sign) from the CA (d.signer) using DSA is valid for the content description (d)
  • Digest(d.digest, MD5, c): The downloaded content's (c) MD5 digest equals the description's digest (d.digest)

The seven predicates verify the six UARC content download requirements above in the following order (1, 3, 4, 5, 2, 2, 6).

Collaborator content for UARC is verified differently. In Lee et al [32], we define a service that returns session keys to content providers for sending content messages in UARC. If symmetric session keys are used, the following policy expresses the download requirements for collaborator content (using the predicates from Figure 2):

  • Running_P(UARC, dp): The UARC content is currently executing on behalf of the downloading principal (dp)
  • Trusted_Provider(d.provider, n.collaborators): Content provider (d.provider) is a trusted provider of collaborator content (UARC.collaborators)
  • MAC(d.MAC, d.provider, SHA-1, c, d): The message authentication code (d.MAC) from the provider (d.provider) using SHA-1 [40] is valid for the content (c) and description (d)
  • Content(d.content, UARC): Content (d.content) must have the same name as expected for the content (UARC)
  • Fresh(d.nonce, d.provider, UARC): The next sequence number for the provider (d.provider) and content (UARC) is the nonce (d.nonce)

The five predicates verify the six download requirements above in the following order (1, 2, 3 and 5, 4, 6). The MAC also verifies that the collaborator is current because the current session key must be used in the generation of the MAC. The UARC content specifies all but the first download requirement.

The download server uses the content principal authenticated to select an authorization server for the content. Either an existing or new authorization server is used. UARC content is always associated with a new authorization server. On the other hand, collaborators reuse their authorization servers, and the protection domain remains unchanged.

Return to Table of Contents

Protection Domain Derivation Server

Suppose that UARC content has already been downloaded. We will examine the derivation of a protection domain for UARC collaborators that belong to the Chief Scientists principal (i.e., role). Below is the protection domain request for this principal provided by the UARC content (for authenticated channels, files, and URLs only using the notation of Definition 4):

  • Chief Scientists
    • tex2html_wrap_inline1818
    • tex2html_wrap_inline1820
    • tex2html_wrap_inline1822
    • {url,[read],http://www.uarc.org/ notices.html}
    • tex2html_wrap_inline1824
    • tex2html_wrap_inline1826
    • tex2html_wrap_inline1828

This protection domain specifies the permissions of the collaborators that belong to the Chief Scientists to perform operations on logical objects. For example, Chief Scientists are permitted to communicate with the UARC servers (uarc) to download data and with the UARC registration server (uarc_register) to communicate administrative requests.

With the exception of the URL (which refers to a specific system object), the protection domain request is specified in terms of logical objects, not specific system objects, so they must be mapped. First, the protection domain derivation server determines if the logical object name corresponds to a object group. For example, this is the case for the uarc object which corresponds to an object group consisting of a UARC data server and a UARC administrative server. It then applies mapping functions to any unresolved logical objects. Mapping functions are retrieved from a policy graph for mapping functions using the content description. Mapping functions are specific to the object type and/or logical object name as shown below (where x is the object group specification and y is the application):

  • Channels: uarc_scientists = uarc_register. get_members(x)
  • Files: which x
  • URLs: none

The mapping function for uarc_scientists channels asks the UARC registration server (uarc_register) to specify the mapping. Files are mapped first using the UNIX program which to determine if they are known executables. Otherwise, the mapping depends on the set of objects that belong to a object group named by the logical object. This is the same for URLs as well.

Using these mapping functions, the access rights for the UARC chief scientists principal (i.e., all principals that are executing using this role) are as follows(communication channel host and port for the authenticated channels are omitted):

  • {achannel,[connect],{uarc_server, uarc_admins}}
  • {achannel,[connect],{sci1@gsp.grp.de, sci2@stanford.edu, ...}\}}
  • {url,[read],http://www.uarc.org/ notices.html}
  • {file,[read|write],annotations,10}
  • {file,[read],replaying_files}
  • {file,[exec],/usr/local/bin/analysis_pkg}

The remaining problem is to determine whether the mapped protection domain request is acceptable. The mapped protection domain request is compared to the maximal protection domain derived from the default maximal protection domain policy graph (see Section 3.2). The maximal protection domains are retrieved from the default maximal protection domain policy graph as described in Section 4. In this case, the maximal protection domain permits all the rights requested above except access to the recording1.ann file that is located in the downloading principal's home directory.

If the resultant maximal protection domain is not a superset of the requested protection domain (as is the case here), then the downloading principal may be permitted to grant the additional rights necessary to fulfill the request. The downloading principal's maximal protection domain policy graph is used to retrieved the domain in which the downloading principal may grant rights to the maximal protection domain. This enables the downloading principal to grant additional rights within limits set by a system administrator. The same policy is used to retrieve the downloading principal's maximal protection domain.

The resulting content domain is the maximal protection domain that can be granted to the content. If this domain is still not a superset of the protection domain request, the downloading principal or UARC content must decide whether to execute the content with fewer rights than requested or to reject it.

Return to Table of Contents

Authorization Server

The authorization server uses (1) the operation objects to identify the operations that need to be authorized and (2) the protection domain to authorize these operations and guide any protection domain management. In this section, we describe examples of operation objects for file system operations used by UARC. The operation objects identify the actual operations that need to be authorized. The authorization mechanism defined in Section 3.3 uses the current protection domain to authorize the requested operations. In addition, the current protection domain specifies management tasks for the authorization server. First, if limits are to be enforced on a domain right, the authorization will perform update usage data. Also, any transforms will be executed. In UARC, we use two kinds of transforms: (1) a delegation to other collaborators and (2) a delegation to a service that can control native software.

Operation objects (defined in Section 3.3) specify a mapping between operation syntax and authorization requirements. For authorization purposes, operations are grouped into two categories: (1) bind operations and (2) post-bind operations. Bind operations establish a link between a principal and an object that permits the principal to perform certain operations on that object (e.g., using a capability). The term bind is taken from the term secure bind, a term employed by the designers of the Exokernel for the same concept [16] (although the concept is much older). A common example is the file open operation in UNIX that creates a file descriptor for a file that permits the operations requested in the open (i.e., if authorized). Post-bind operations use the capability (e.g., file descriptor) to perform subsequent operations on the object (e.g., file).

For example, file open is a bind operation with three operands: (1) a pointer to a file name string, (2) a flag indicating the operations for which the open is intended, and (3) the open mode. A bind operation initiates use of an object and returns a capability for efficient authorization of subsequent operations. The operation object specifies the handling of arguments and identifies the subsequent operations. For example, the file name string must be copied to prevent the content from modifying it after authorization. The copy vector function specifies the mechanism for copying, and the size vector function determines the size of the string to copy (in an environment where copy operations do not know the object's size, such as in C). The flag and mode must also be copied, but they are integer values, so the default copy mechanism is used. The operations to authorize are determined by using the second operand's (the ops operand) value to index into the op vector.

On the other hand, read is a post-bind operation with three operands: (1) a file descriptor, (2) a buffer, and (3) the maximum number of bytes to be read. Post-bind operations may be authorized because the authorization server may not trust the object server to authorize the operation. This is also indicated by the a type field in the operation object. The integer copy is used for all operands. This is only controversial for the buffer argument which is a pointer. As long as the pointer value plus the maximum number of bytes is within the content's address space, the operation is valid. This is specified in the authorization vector. Since the authorization server determines the content's address space, it can limit the content to a specific address range.

Data collection is triggered when operations are authorized by domain rights that have limits specified. For example, chief scientists content is limited to reading and/or writing no more than 10 annotation files. Each time this domain right is used to authorize an operation, its usage count is incremented. To prevent limits from being reached prematurely, the domain rights without limits are checked before those that have limits. Other limited domain rights may also be checked to determine if they also would authorize the operation, so their usage count can be updated as well. Because this affects performance, overlapping domain rights for each domain right should be identified in advance, and only those domain rights should be examined.

Transforms are used in three ways in UARC: (1) delegation of downloading principal rights to other collaborator content, (2) delegation of UARC and collaborator content rights to object servers, and (3) restriction of UARC and collaborator content rights given interactions with untrusted servers or content. In the first case, the object group transform tex2html_wrap_inline1830 specifies that after the downloading principal starts a replay of recording x, its file is added to the object group tex2html_wrap_inline1834 . All collaborator content obtains access to the file as specified by its access to the tex2html_wrap_inline1834 object group in its current protection domains. In the second case, the operation transform tex2html_wrap_inline1838 specifies that analysis_pkg's server (i.e., native O/S server) limits it to reading the file specified by argument y only. analysis_pkg's authorization server enforces this delegation. This type of transform can be used to delegate limited rights to executable content (e.g., native code) controlled by other servers. In the third case, the domain transform tex2html_wrap_inline1840 intersects the current content protection domain with that of the principal p (who supplied the untrusted operation). This prevents malicious content from spoofing other content into granting unauthorized rights to it.

We examine a transform that enables the downloading principal to delegate rights to other content providers. An example transform is shown in Figure 11. This example specifies that access to a recording file and its associated annotation file are delegated when the start_replay operation is executed. This transform is associated with the UARC content which is used by the downloading principal. Four transforms are specified: (1) an operation transform for the chief_scientists domain, (2) an operation transform for the scientists's domain, and (3) a pair of object group transforms that apply to all principals that can access them. Each operation transform grants rights for the principals to access the recording x returned by start_replay. The transforms for x.file() and x.annotations_file() place these objects in the replaying_files and annotations object groups, respectively. These transforms enable content providers to perform operations on these object groups as specified by their protection domains. For example, a chief scientist can both read and write the annotations and the recording. In this case, the UARC content developer is trusted with the rights that are delegated in the transforms. Therefore, the authorization server permits the other principals to obtain these rights.

4=

Op: Recordings x = Recordings.start_replay()

{Op, chief_scientists, a, x, [read tex2html_wrap_inline1850 write]}

{Op, scientists, a, x, [read], 1}

{Op, add, a, x.file(), replaying_files}

{Op, add, a, x.annotation_file(), annotations}

Figure 11: Transform specification: Upon start_replay operation, delegate access to a recording being replayed (x), its file (x.file()), and its associated annotation file ( tex2html_wrap_inline1856 ).

Operation objects with transforms can also be used to specify the criteria to execute native software and the rights to be delegated to it. For example, we define an operation object for executing the analysis_pkg. In Figure 12, we define the operation object. analysis_pkg has one argument, which is a file that contains the data to be analyzed. The caller must have read permission for this file in order to execute the software. The transform vector specifies the rights to be granted to the server that can control analysis_pkg (called O/S), namely read access to the specified file. The authorization server retrieves the transform delegation domain for the transform to determine whether the specified rights can be granted for the content, operation, and receiver.

4=

Op: analysis_pkg(fileX)

Operation: analysis_pkg

Server: O/S

Operand Count: 1

O Type: Native

Auth Vector: {{File, read}}

Transform Vector: {{O/S, b, files, read, fileX, 1}}

Figure 12: Operation object specification: Execute the analysis_pkg program

Return to Table of Contents

Implementations

In the following sections, we describe our experiences implementing this system using Tcl version 7.5 and Java version 1.1. Also, we examine a system we are developing that can control arbitrary downloaded executables efficiently and can enable flexible sharing.

Return to Table of Contents

Tcl 7.5 System

figure859
Figure 13: Downloaded content execution system implemented using Tcl version 7.5.

We have built a prototype of our downloaded content system in Tcl 7.5 [30]. This implementation uses the interpreter hierarchy model provided by Tcl 7.5 to construct interpreters with limited rights. The download server is an interpreter that implements the download policy on behalf of the downloading principal. The protection domain derivation server is a separate interpreter that the download server calls to derive the content's protection domain. Each content is controlled by its own authorization server interpreter. Content itself is executed in a "safe" interpreter that lacks I/O operations. All I/O operations are provided by the authorization server interpreter.

Tcl 7.5 introduces an interpreter hierarchy model [33]. The hierarchy can consist of two basic types of interpreters: trusted and untrusted. A trusted interpreter is a complete interpreter, and an untrusted interpreter has all the I/O operations removed from it. To enable an untrusted interpreter to perform some I/O operations, the alias operation is defined. The alias operation assigns the name of an operation in one interpreter to an operation in another interpreter. For example, the open operation in an untrusted interpreter can be aliased to the safe_open operation in a trusted interpreter. The safe version authorizes the untrusted interpreter's request, and, if authorized, forwards the request to the appropriate server interpreter. Note that only the interpreter with the aliased operation can create such aliases.

The Tcl 7.5 downloaded content system is shown in Figure 13. Content is obtained by the download server interpreter. It implements the download policy and loads content-specific requirements (e.g., authentication). If the download server permits content execution, it requests the protection domain derivation server to derive the current and maximal protection domains for content. The download server then creates an authorization server interpreter that enforces the content's protection domain. The authorization server then generates a content interpreter for executing the content. For each controlled operation that the content interpreter can perform, an alias to an operation in the authorization server is created. Also, transform operations are linked to alias operations in the authorization server, so that the rights associated with the transform can be granted or revoked.

Recall that security policy is stored in policy graphs. In Tcl, policy graphs are implemented using the arrays where the indices are the concatenation of the attribute values. The indices used are the name of the content provider and the name of the application or application group. For example, content from IBM that belongs to a group called games has the index "IBM:games."

This implementation uses extended BETSI certificates for verifying the two download policies described in Section 4.1. BETSI certificates are signed by a certificate CA using DSA [39]. The content digests are generated using MD5 [44]. Sequence numbers are used as nonces.

Content is loaded into a content interpreter that is selected based on the application and provider. Some applications may permit providers to reuse interpreters. For example, all content from a provider (or set of providers with the same role) in a synchronous collaborative application (e.g., UARC) are loaded into the same interpreter. Otherwise, a new interpreter is generated for downloaded content.

The protection domain derivation server implements the policy described in Section 4.2. The protection domains are represented using arrays of protection domain entries (i.e., domain rights or exceptions) indexed by object type. For example, requesting the file entry results in obtaining all file protection domain entries.

Content interpreters and their authorization servers are generated for each content. Content interpreters are created that have an alias to each controlled operation that they execute (as defined in their current protection domain). For example, the open operation is aliased to the master_open operation in their authorization servers. The authorization server creates each aliased operation. The authorization server's aliased operations implement authorization, data collection, transforms, and they call the controlled operation. The download server stores the specifications for these aliased operations, and they are loaded into the authorization server. Operation objects are used to generate aliased operations, including their authorization requirements. For example, the master_open operation requires authorization of the first argument as a file. The operations to be authorized are derived from the second argument. The protection domain determines the requirements for data collection and transforms. The domain rights that specify limits and apply for the object and operation have their counts updated. Transforms operations are generated and called from the aliased operation.

Once authorized, the authorization server can execute the operation. Tcl is not type-safe, so we cannot return an object whose access must be controlled. For these objects, the authorization server returns an object descriptor rather than the object itself to the content interpreter (much like the present open command). The authorization server maintains a mapping of descriptors to actual objects.

Return to Table of Contents

Java 1.1 System: FlexxGuard

figure883
Figure 14: Downloaded content execution system implemented using JDK 1.1.

Figure 14 shows how a Java's virtual machine (JVM) can be modified to implement our model. We describe an extension of the Java Development Kit (JDK) version 1.1 [4, 3]. This implementation controls unauthenticated applets using the standard Java applet security policy (e.g., the applet is not allowed to access files on the downloading principal's machine, and socket connections to the applet's host are permitted), but flexible protection domains can be associated with authenticated applets. Protection domains are derived for authenticated applets based on their provider and applet names.

Policy graphs are implemented using PolicyDB and Policy classes. The policy graph data is stored in instances of the PolicyDB class and is interpreted by an instance of subclasses of an abstract Policy class. The PolicyDB class enables policy graphs with arbitrary structure to be defined. Therefore, content descriptions can be extended without the need to create a new PolicyDB class. The traversal and combination methods are implemented in the Policy class. Therefore, a new Policy class is needed to interpret a policy graph in a new way.

The Java AppletClassLoader is responsible for downloading applets from the server (i.e., serves as the download server). In this implementation, authenticated applets are stored on the server using the JAR (Java Archive) format. In addition to the usual Java object files, our JAR files also contain requested domain files. The JAR file is signed using the javakey facility (i.e., using DSA [39]). At present, the AppletClassLoader enforces a single authentication policy: verify the integrity of the content message and load the content into a new name space. The PEM [6] certificate model is used in this implementation (i.e., manufacturers rather than CAs sign JAR files, and CAs sign public key certificates for manufacturers).

For authenticated JAR files, the AppletClassLoader derives the content's protection domain using the requested protection domain of the applet and the downloading principal's policy graph. The downloading principal's policy database associates protection domains with applet attributes (manufacturer name and applet name). The protocol described in Section 3.2 is used to derive the applet's protection domain. The policy database is stored in disk files that must be protected from access by other principals and applets.

We use SecurityTokens to map threads to protection domains. If the user decides to continue with the execution of the applet, the AppletSecurity manager object stores a mapping of the applet's protection domain to the applet's SecurityToken. When an applet starts executing, it is assigned a unique, unmodifiable, unforgeable SecurityToken. Any threads created by the applet inherit the SecurityToken. In Java, system threads execute applet code, so when applet code is run, the system temporarily assigns the associated applet's SecurityToken to the thread (from the AppletPanel and AWT objects). The applet selected depends on the identity of the applet being loaded by the AppletPanel or the applet that created the AWT object.

The AppletSecurity object uses the SecurityToken of the thread that invokes it to determine whether or not to allow an access to a system resource (i.e., serves as the authorization server for all applets). Using the Securitytoken, AppletSecurity retrieves the associated protection domain and authorizes the operation. If the authorization fails, a security exception is thrown. Any calls to AppletSecurity that originated from an unauthenticated applet will be authorized using the default Java applet security policy. System threads (i.e., threads with the System token) are allowed full access to the system.

In Java, it is the responsibility of the controlled method to intercept calls and have them authorized, to collect data, and to execute transforms (by the AppletSecurity object), but this presents some problems in performing transforms. First, the execution of transforms after the operation is completed requires a second call to the authorization server. While this certainly possible, it is cumbersome and requires that the operation writer know about this. Bischof and Kaiserswerth define a selective operation interception mechanism that enables auxiliary methods to be executed when a method is invoked [8]. This mechanism enables the access control requirements to be separated from the method's functionality requirements, as is done in the Tcl implementation. We believe that this is preferable for implementing operation objects.

Second, a transform that is the result of an unsafe interaction is hard to catch. For example, suppose that content executes a method of a malicious class that attempts to spoof it into providing it with unauthorized object descriptors. This is prevented in our architecture by intersecting the protection domain of the content with that of the untrusted content. However, in Java it is difficult to tell when these interactions occur. Applets' name spaces are not necessarily separate because static variables are global. Scanning the call stack is limited because it does not indicate methods that have returned nor methods prior to the creation of a new thread. We do not want to have to check every method invocation, so we only permit such interactions using remote method invocation (RMI). These RMIs can be annotated to perform transforms that limit the calling content's protection domain.

Return to Table of Contents

Arbitrary Executables: L4 Lava

figure922
Figure 15: Downloaded content execution system implemented using L4.

In general, what we want is a language-independent authorization server with (1) the process separation afforded by address spaces, (2) fast IPC between separated processes, and (3) the ability to share data in a flexible manner. The L4 tex2html_wrap_inline1862 -kernel provides such functionality, so we are developing a system called Lava that defines security policy for flexibly controlling arbitrary executables [27, 37]. L4 provides address spaces, so Lava can assign content to individual address spaces and control their IPC. Unlike JDK 1.1, naming boundaries can be completely administered, so we can identify boundary crossings and prevent leakage of data (e.g., through statics in JDK 1.1). L4 IPC can perform a round-trip IPC in as little as 0.7 tex2html_wrap_inline1862 s, so boundary crossings can be efficient. In addition, L4 defines a flexible paging mechanism, so unlike the Tcl interpreter model, data can be shared between processes. Below, we discuss our current implementation of operation interception and authorization.

Figure 15 shows the system components. A download server is defined that uses the HTTP 1.1 interface to download content (e.g., get and put operations to read and write objects, respectively). Content is downloaded from a large cache server, if it is in the cache, or from the remote server. Authentication is performed on the cache server (according to the download policy stored there), and the object is placed in the cache. The protection domain derivation server is split between the cache server and the client. The cache server provides the logical maximal protection domain for any object types whose domains are derived in advance with the object upon download. The client maps the logical protection domain based on the mapping functions for that downloading principal. Content messages from the cache server are authenticated using a MAC of the message. To make MAC generation more efficient, digests of each object packet are pre-created using the SHA-1 hash algorithm [40] and stored in the packet header. Each downloading principal shares a secret symmetric key with the server, so MACs are generated from the digests upon download using a 1 Gb/s MAC algorithm MMH [26].

The content execution system on the downloading principal's client is implemented on the L4 microkernel [35]. The Clans & Chiefs model provided by L4 [34] is used to control content. In this model, a chief task (i.e., the authorization server) controls the IPC of one or more clan tasks (i.e., the content interpreter). Clan tasks may communicate freely with other tasks in the same clan, but any IPC to a task outside the clan is redirected to the chief task.

Content is assigned to a clan task administered by a trusted chief task that is its authorization server. System resources are provided by server tasks that are outside the clan. Therefore, any operation by the controlled content on system resources is redirected to the authorization server.

L4 provides a flexible paging mechanism that enables processes to share arbitrary regions of memory [25]. Thus, unlike the multiple interpreter model of Tcl, processes can use shared state. The authorization server must authorize such sharing and must unmap pages once sharing is no longer necessary.

Protection domains are represented by three types of capabilities based on (1) object group names, (2) object descriptors, and (3) handles. Authorization servers store domain rights and exceptions for content in capabilities that map object group names to access rights (see Definition 3). These are transferred to the authorization server in the clear (but authenticated for integrity and freshness) because they do not enable eavesdroppers to obtain rights, but only are used by authorization servers to authorize content IPCs. Object group names are pointers to strings. The access rights value is either a bit vector or a pointer to sequence of triples: bit vector, limit, and count. Rights triples are used to prevent denial-of-service attacks by the content [36].

Upon an authorized operation, a destination server may return a traditional capability based on an object descriptor. These capabilities must be unforgeable and strongly-typed, but their composition is dependent on the server. For example, servers executing on the client's machine (e.g., file systems) can provide file descriptors, but remote servers need to associate authentication information with the capability (e.g., MAC of capability using a key secret to the server) [22, 47]. The authorization server has the option of being able to revoke such capabilities, so it returns a handle to the content rather than the capability itself. The handle is an index to the server capability and the access rights that the authorization server grants from that capability. Therefore, the authorization server can restrict the rights provided in a capability, if necessary.

The operation interception protocol is implemented as follows: First, an emulation library attached to the content task copies its registers to a structure shared by the authorization server and the content. Next, this library sends a system call message to the authorization server. The authorization server first copies the operands to an array for authorization using the copy vector and size vector. Next, the authorization server determines the operations to be authorized using the ops operand and op vector. These operations and any indicated by the authorization vector for other arguments are authorized. Any authorized operation is then forwarded from the authorization server using an IPC to the destination server. If the operation is a bind, a capability is returned to the authorization server. A handle (small integer) is created by the authorization server as a reference to this capability and is returned to the content for subsequent operations.

Return to Table of Contents

Performance Comparison

The performance of interception and authorization of open and read operations for the three implementations is shown in Table 3 on a 166 MHz Pentium (using a 30 byte object name). The open operation is a bind operation, so the authorization server must compare the object name and requested operation to those in the protection domain entries. In addition, the L4 implementation requires that the arguments be copied (in particular, the object name string). This is not necessary in Tcl or Java because Tcl is single-threaded and Java strings are immutable. Despite the extra work, the L4-based implementation authorizes the open operation 100 times faster than either the Java or Tcl implementations. Of course, lack of pointers in either Java or Tcl and the type-safety in Java provide additional safety for programs not available in a bare executable. Therefore, an interesting alternative that achieves high security and safety with high authorization performance is a system that executes safe code partitioned into L4 processes managed by the L4-based authorization server.

The open operation returns a file descriptor that can be used by the content for read operations. In the Java and Tcl, the descriptor enables direct access to the read operation without further authorization. However, revocation of the descriptor from the content is not supported. The L4-based implementation provides handles to the content rather than the file descriptor, so the authorization server can revoke the descriptor. The Tcl and L4-based implementations provide system call interception prior to directing the operations to the actual server. This is not done by Java, but this makes it more difficult to determine the proper protection domain for an operation. The cost of system call interception in the L4-based system is about 300 times faster than the Tcl implementation.

Operation Open µs Read µs
Registers copy in
Operand copy
Get Handle (Authorize)
IPC to server
Register copy out
0.14
5.12
3.65
0.35
0.07
0.14
0.47
0.34
0.35
0.07
Lava intercept cost 9.33 1.37
Tcl intercept cost 1030 470
Java intercept cost 1000 0
Table 3: Authorized IPC performance for open and read: create descriptor on open to use in read operation. Revocable handle returned to content in Lava case only.

Return to Table of Contents

Related Work

None Realm-based Principal-based Arbitrary Reqs
ATOMICMAIL [10]
Safe-Tcl [11]
Tcl [33]
Java appletviewer[24]
Java-enabled Netscape [48]
Grail [50]
Telescript [53] Penguin [19]
Inferno [15]
ActiveX [12]
Netscape signed code [52]
E [2]
Lava
Tcl-system
FlexxGuard

Table 4: Few downloaded content systems support even authentication policy. Only our systems support general download policies, including execution, loading, and authentication.


Fixed Provider Only Application (ad hoc) Application (model)
ATOMICMAIL [10]
ActiveX [12]
Safe=Tcl [11]
Java appletviewer [24]
Java-enabled Netscape [48]
Telescript [53]
Tcl [33]
Inferno [15]
Grail [50]
Penguin
Netscape signed code [52]
FlexxGuard
Lava
Tcl system
E [2]

Table 5: Downloaded content systems derive access rights for content based on (1) fixed domains, (2) the content provider only, (3) the content provider and application using ad hoc access specification, or (4) the content provider and application using content access control models.


One Name Space Two Name Space Multiple Name Spaces Evolving Domains
ATOMICMAIL [10]
Telescript [53]
Java appletviewer[24]
Java-enabled Netscape[48]
ActiveX
Safe-Tcl [11] Tcl [33]
Inferno [15]
Grail [50]
Penguin [19]
FlexxGuard
E [2]
Tcl-system
Lava
Netscape signed code [52]

Table 6: Downloaded content systems enforce protection domains using (1) a single interpreter, (2) user and a single privileged interpreter, (3) multiple user and privileged interpreters, and (4) multiple user and privileged interpreters whose domains can be updated during content execution.


In this section, we review related efforts to control downloaded executable content. In particular, we want to assess the flexibility of these systems to solve the three problems in building downloaded content execution systems: (1) content download, (2) protection domain derivation, and (3) protection domain authorization. If a system permits little flexibility, then fewer applications can be constructed using that system. However, if no security model is provided upon a flexible base, then application developers must develop ad hoc security models, which is not acceptable either.

In Table 4, we show the variety of support for enforcing download requirements. A few systems provide support for authenticating content providers. For example, JDK 1.1 includes a security infrastructure (javakey) that can be used to sign applets as we have described. Also, Telescript [53] content is authenticated based on the source realm of the content. ActiveX and Netscape propose the use of digital signatures of content to authenticate its source [12, 52]. Inferno [15] uses the station-to-station protocol for authentication. Flexible download mechanisms permit content to be annotated with attribute-value pair descriptions that can be used to determine whether content can be executed and how content should be loaded, in addition to authentication. Other systems provide an infrastructure for associating authenticated content descriptions with content [1, 13], but they do not provide a model for describing and enforcing such requirements.

In Table 5, the systems' flexibility in derivation of protection domains is shown. Early systems used the same protection domain for all content. For example, ATOMICMAIL [10]) does not permit any access to system resources and Safe-Tcl [11] permits access only to a public directory. ActiveX permits all-or-nothing access. A second category of systems permits protection domains to be defined based on the content provider only. We include Java-enabled Netscape [48] and Java appletviewer [24] in this category, although they distinguish only between source IP addresses and not between individual principals. The third category of systems permits flexible association of protection domains with content, but does not provide a model for deriving such domains (i.e., it requires ad hoc security models to be constructed). For example, Telescript [53], Tcl [33], and Grail [50] require the developers to specify and enforce access rights within their programs. In the fourth category, systems provide access control models to specify access rights for content from specific principals and for specific applications. Netscape's signed code proposal permits content to select a protection domain within a limit [52]. Our systems permit downloading principals to specify arbitrary protection domains for content using our access control model.

Protection domain authorization techniques are shown in Table 6. The key issues are the number of independent content name spaces that may be created and the ability to evolve the content's protection domain as conditions change. In early systems [10], content is executed in a single interpreter with a single, fixed protection domain. Java-based systems are also categorized as a single interpreter system, although they emulate a user and privileged interpreter within a single supervisor task by authorizing operations based upon whether the content is untrusted or not [24, 48, 53]. Some operations, such as the creation of static variables, affect all content name spaces, because there is no one real address space. The second category of systems includes Safe-Tcl [11]. These systems use the traditional two name spaces: user and privileged. The third category of systems permits multiple name spaces with the possibility of different user and privileged domains [15, 33, 50]. The fourth category of systems uses multiple name spaces and permits content access rights to evolve in limited ways during execution. The use of logical access control specifications and transforms enables our systems to control the set of objects in a protection domain based on the application state. While Netscape's signed code proposal permits content to work with only the objects they need, the content determines the protection domain (within limits), not the authorization server [52]).

Return to Table of Contents

Conclusions and Future Work

We have presented a system that flexibly controls the execution of downloaded content. The system consists of three components: (1) a download server that determines whether the content can be executed by its downloading principal, (2) a protection domain derivation server that derives the content's protection domain and protection domain management policy, and (3) an authorization server that enforces the content's protection domain throughout its execution and administers the protection domain using the management policy. The system's servers provide general mechanisms for implementing their purposes and a policy representation model for their policy. Flexibility is obtained because principals can define their own security policies, which can then be implemented by the servers.

Control is obtained by enabling principals to specify policy limits upon other, less-privileged principals. For example, system administrators can specify the acceptable ways in which applications can authenticate messages. Application developers can then choose from one of the techniques. In addition, system administrators can define what rights users and application developers can delegate to content. We demonstrate the definition of such policies for a collaborative application.

Three implementations of our system are outlined. The first is an implementation using Tcl 7.5 that uses its hierarchical interpreter model. The system is implemented in a straightforward manner in Tcl 7.5 because independent content interpreters can be defined where all controlled operations can be monitored by a trusted interpreter. The second implementation uses JDK 1.1. JDK provides support for authentication, but no security model for downloading is provided. Also, authorization is complicated because it is difficult to identify where protection domain boundaries are without introducing significant expense. Analysis of the call stack reduces this expense, but does not catch all significant protection domain crossings, so attacks are possible. The third implementation uses system services built upon the L4 tex2html_wrap_inline1862 -kernel. In this implementation, any executable can be controlled by a monitor that intercepts all operations destined for controlled servers. L4 provides address spaces, fast IPC, and a flexible model for sharing. Thus, content can be assigned to its own address space with only minor penalties for inter-space communication and with the ability to share objects in a controlled manner.

In the future, we will extend the L4-based implementation and will experiment with security policies. We plan to port JDK to the L4-based implementation, with the goal of associating protection domains with L4 tasks so that they can use the underlying security mechanisms. This would also provide a programming environment to the L4-based system, which is also lacking at the moment. Upon this system, we can experiment with policies for downloading content, deriving protection domains, and managing these domains. Experimentation with policies will include the development and testing of various policies to determine an acceptable trade-off of system administrator, application developer, and user control and management effort. We expect that security experts will be active in defining such policies and better ways to use them.

Return to Table of Contents

Acknowledgments

We would like to thank Frederique Giraud, Patrick McDaniel, Seva Panteleenko, and J. R. Rao for their help in the design and development of the implementations. Also, we would like to thank Ed Felten, Peter Honeyman, Paul Karger, Jim Roskind, Avi Rubin, and Dan Wallach for their enlightening discussions that helped us crystallize the ideas presented in this paper.

Return to Table of Contents



References

1
"Cryptolope containers have arrived." May 1996. http://www.infomkt.ibm.com/ht3/ prcrypto.html.

2
"Using the EC Trust Manager to secure Java." April 1997. http://www.communities.com/company/papers/trust/index.html.

3
R. Anand, N. Islam, T. Jaeger, and J. R. Rao. "A flexible security model for using Internet content." IEEE Software, 1997. To appear.

4
R. Anand, N. Islam, and J. R. Rao. "A capability-based security model for using Internet content." Technical Report 20664, IBM Research, 1996.

5
L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. "Practical domain and type enforcement for UNIX." IEEE Symposium on Security and Privacy, pages 66-77, 1995.

6
D. Balenson. "Privacy enhancement for Internet electronic mail: Part III: algorithms, modes, and identifiers." Internet RFC 1423, February, 1993.

7
A. Berman, V. Bourassa, and E. Selberg. "TRON: Process-specific file protection for the UNIX operating system." Proceedings of the 1995 USENIX Winter Technical Conference, pages 165-175, 1995.

8
J. Bischof and M. Kaiserswerth, December 1996. Personal communication.

9
M. Blaze, J. Feigenbaum, and J. Lacy. "Decentralized trust management." Proceedings of the IEEE Symposium on Security and Privacy, pages 164-173, 1996.

10
N. S. Borenstein. "Computational mail as a network infrastructure for computer-supported cooperative work." Proceedings of the Fourth ACM Conference on Computer-Supported Collaborative Work, pages 67-74, 1992.

11
N. S. Borenstein. "Email with a mind of its own: The Safe-Tcl language for enabled mail." ULPAA '94, pages 389-402, 1994.

12
T. Coombs, J. Coombs, and D. Brewer. ActiveX Sourcebook. Wiley Computer Publishing, 1996.

13
D. Dardailler, J. Miller, and R. Khare. "Digital signature initiative proposal." April 1997. http://www.w3.org/pub/WWW/Security/DSig/ DsigProj.html.

14
D. Dean, E. Felten, and D. Wallach. "Java security: From HotJava to Netscape and beyond." Proceedings of the IEEE Symposium on Security and Privacy, 1996.

15
S. Dorward, R. Pike, and P. Winterbottom. "Inferno: la commedia interattiva." 1996. http://inferno.bell-labs.com/inferno/ infernosum.html.

16
D. Engler, F. Kaashoek, and J. O'Toole. "Exokernel: An operating system architecture for application level resource management." Proceedings of the 15th Symposium on Operating Systems Principles, pages 251-266, December 1995.

17
R. Clauer et. al. "A prototype upper atmospheric collaboratory (UARC)." AGU Monograph: Visualization Techniques in Space and Atmospheric Sciences. In press.

18
S. Foley and J. Jacob. "Specifying security for CSCW systems." Proceedings of the 8th IEEE Computer Security Foundations Workshop, pages 136-145, 1995.

19
F. S. Gallo. "Penguin: Java done right." The Perl Journal, 1(2):10-12, 1996.

20
M. Gasser and E. McDermott. "An architecture for practical delegation in a distributed system." IEEE Symposium on Security and Privacy, pages 20-30, 1990.

21
I. Goldberg, D. Wagner, R. Thomas, and E. Brewer. "A secure environment for untrusted helper applications." Proceedings of the 6th USENIX Security Symposium, pages 1-14, July 1996.

22
L. Gong. "A secure identity-based capability system." IEEE Symposium on Security and Privacy, pages 56-63, 1989.

23
J. Gosling, B. Joy, and G. Steele. The Java Language Specification. Addison-Wesley, 1996.

24
J. Gosling and H. McGilton. "The Java language environment: A white paper." May 1996. http://www.javasoft.com/docs/language_ environment/.

25
H. Haertig, J. Wolter, and J. Liedtke. "Flexible-sized page-objects." Proceedings of the Fifth International Workshop on Object Orientation in Operating Systems, October 1996.

26
S. Halevi and H. Krawczyk. "MMH: Software message authentication in the Gbit/s rates." Proceedings of the Fourth Fast Encryption Workshop, 1997. To appear in Lecture Notes in Computer Science, Springer-Verlag, E. Biham, ed.

27
T. Jaeger, N. Islam, J. Liedtke, and V. Panteleenko. "An authorization system for downloaded content on l4." 1997. Internal IBM Technical Document.

28
T. Jaeger and A. Prakash. "Support for the file system security requirements of computational e-mail systems." Proceedings of the 2nd ACM Conference on Computer and Communications Security, pages 1-9, 1994.

29
T. Jaeger and A. Prakash. "Implementation of a discretionary access control model for script-based systems." Proceedings of the 8th IEEE Computer Security Foundations Workshop, pages 70-84, 1995.

30
T. Jaeger, A. Rubin, and A. Prakash. "Building systems that flexibly control downloaded executable content." Proceedings of the 6th USENIX Security Symposium, pages 131-148, July 1996.

31
M. Knister and A. Prakash. "Issues in the design of a toolkit for supporting multiple group editors." Computing Systems - The Journal of the Usenix Association, 6(2):135-166, 1993.

32
J. Lee, A. Prakash, T. Jaeger, and G. Wu. "A software architecture to support open distributed collaboratories." Proceedings of the Sixth ACM Conference on Computer-Supported Cooperative Work, November 1996. To appear.

33
J. Levy and J. Ousterhout. "Safe Tcl: A toolbox for constructing electronic meeting places." The First USENIX Workshop on Electronic Commerce, pages 133-135, 1995.

34
J. Liedtke. "Clans & chiefs." Architektur von Rechensystemen. Springer-Verlag, March 1992. In English.

35
J. Liedtke. "On -kernel construction." Proceedings of the 15th Symposium on Operating Systems Principles, December 1995.

36
J. Liedtke, N. Islam, and T. Jaeger. "Preventing denial-of-service attacks on a -kernel for WebOSes." Proceedings of the Sixth Workshop on Hot Topics in Operating Systems, May 1997.

37
J. Liedtke, N. Islam, T. Jaeger, and V. Panteleenko. "Fast and flexible intranet servers, March 1997." Internal IBM Technical Document submitted for publication.

38
G. McGraw and E. Felten. Java Security: Hostile applets, holes, and antidotes. Wiley Computer Publishing, 1997.

39
National Institute of Standards and Technology, U.S. Department of Commerce. NIST FIPS PUB 186, Digital Signature Standard, May 1994.

40
National Institute of Standards and Technology, U.S. Department of Commerce. NIST FIPS PUB 180-1, Secure Hash Standard, April 1995.

41
R. Needham and M. Schroeder. "Using encryption for authentication in large networks." Communications of ACM, 21(12):993-999, December 1978.

42
J. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, 1994.

43
P. Resnick and J. Miller. "PICS: Internet access controls without censorship." Communications of the ACM, 39(10):87-93, 1996.

44
R. Rivest. "The MD5 message digest algorithm." Internet RFC 1321, April, 1992.

45
A. D. Rubin. "Trusted distribution of software over the internet." Proceedings of the Internet Society Symposium on Network and Distributed System Security, 1995.

46
D. F. Sterne, T.V. Benzel, L. Badger, K. M. Walker, K. A. Oostendorp, D. L. Sherman, and M. J. Petkac. "Browsing the web safely with Domain and Type Enforcement." IEEE Symposium on Security and Privacy, 1996. Abstract for a 5-minute presentation.

47
A. S. Tannenbaum, R. van Renesse, H. van Staveren, G. Sharp, S. Mullender, J. Jansen, and G. van Russom. "Experiences with the Ameoba distributed operating system." Communications of ACM, 33(12):46-63, December 1990.

48
S. Thomas. "The Navigator Java environment: current security issues." January 1996. http://developer.netscape.com/library/ documentation/ javasecurity.html.

49
Trusted Information Systems, Inc. Trusted Mach System Architecture, TIS TMACH Edoc-0001-94A edition, August 1994.

50
G. van Rossum. "Grail: The browser for the rest of us." (Draft.) 1996. http://monty.cnri.reston.va.us/grail/.

51
S. T. Vinter. "Extended discretionary access controls." IEEE Symposium on Security and Privacy, pages 39-49, 1988.

52
D. Wallach, November 1996. Personal communication.

53
J. E. White. Telescript Language Reference Manual. October 1995. http://www.genmagic. com/Telescript/TDE/TDEDOCS_HTML/telescript. html.

About the Authors:

Trent Jaeger is a Research Staff Member at the IBM T. J. Watson Research Center in Yorktown Heights, NY where he is involved in the development of systems security and operating systems architectures for downloaded executable content. His research interests include systems security, security policy models, operating systems, and collaborative systems. He has published over a half-dozen conference papers on security infrastructure for downloaded executable content. Mr. Jaeger received M.S and Ph.D. degrees in computer science from the University of Michigan in 1993 and 1997, respectively. His e-mail address is jaegert@watson.ibm.com.

Nayeem Islam is a manager at IBM's T.J. Watson research center in Hawthorne, NY where he directs several projects on secure Web operating systems and resource management for servers. He has built a commercial windowing system, an object-oriented operating system and extensions to Java to provide a security model for the Java virtual machine.

Islam has also authored a book Distributed Objects: Methodologies for Customizing Systems Software that is used in graduate courses at several universities. Islam holds a Ph.D. from the University Illinois Urbana Champaign, an M.S. from Stanford University and a B.S.E. from Princeton University, all in Computer Science. His e-mail address is nayeem@watson.ibm.com.






JavaTM is a trademark of Sun Microsystems, Inc.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright   Trademark




  Java Feature Java Education Java Home  
IBM HomeOrderEmployment