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.
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
|
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.
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.
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).
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).
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.
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,
,
where (1) p is a principal, (2) G is a
directed graph, ,
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
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
.
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
.
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
|
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].
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 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,
, which describes a set of operations,
, that the principal can perform on an
of a specific type. The limit specifies
restriction on number of times such an operation can be performed. - Exceptions: A tuple,
, which describes a set of operations,
, that the principal is precluded from
performing on an 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,
, that, when this principal executes an operation in ,
describes a change in the relationship between an object obj and an
object group ( is add or remove)
for all principals. indicates whether the transform is
applied before or after the operation. - Operation transforms: A tuple,
, that, when this principal executes
an operation in , 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.
indicates whether the transform is applied before or after the
operation. - Domain transforms: A tuple,
,
that, when this principal executes an operation in ,
describes a change in the principal's protection domain specified by
(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.
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
|
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.
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
|
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
|
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
- must have been requested by the downloading principal
- must have a description with a valid signature from a trusted CA
- must be from a trusted principal
- must be UARC content
- must be an acceptable version
- 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
- must have an active UARC content executing on the downloading principal's system
- must be from a principal trusted to be a collaborator
- must be a current member of the UARC collaboration
- must be for UARC
- must be unmodified
- 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
|
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
- {url,[read],http://www.uarc.org/ notices.html}
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
|
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 specifies that after the downloading principal
starts a replay of recording x, its file is added to the object
group . All collaborator content obtains access to
the file as specified by its access to the object
group in its current protection domains. In the second case, the
operation transform 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 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 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
( ).
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
|
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
|
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
|
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
|
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 -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 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
|
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
|
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
|
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 -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
|
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
|
|