The following paper was originally published in the

Proceedings of the USENIX Symposium on Internet Technologies and Systems

Monterey, California, December 1997

Going Beyond the Sandbox: An Overview of the New Security

Architecture in the Java Development Kit 1.2

Li Gong, Marianne Mueller, Hemma Prafullchandra, and Roland Schemers

JavaSoft, Sun Microsystems, Inc.

For more information about USENIX Association contact:

1. Phone: 510 528-8649
2. FAX: 510 548-5738
3. Email: [email protected]
4. WWW URL: http://www.usenix.org/
 Going Beyond the Sandbox: An Overview of the New Security
Architecture in the Java Development Kit 1.2 TM

Li Gong, Marianne Mueller, Hemma Prafullchandra, and Roland Schemers

JavaSoft, Sun Microsystems, Inc.
fgong,mrm,hemma,[email protected]

Abstract 1.1 The Original Security Model

This paper describes the new security architec- The original security model provided by Java is
ture that has been implemented as part of JDK1.2, known as the sandbox model, which exists in order
the forthcoming JavaTM Development Kit. In going to provide a very restricted environment in which
beyond the sandbox security model in the original to run untrusted code (called applet) obtained from
release of Java, JDK1.2 provides ne-grained ac- the open network. The essence of the sandbox
cess control via an easily con gurable security pol- model, as illustrated by Figure 1, is that local code is
icy. Moreover, JDK1.2 introduces the concept of trusted to have full access to vital system resources
protection domain and a few related security prim- (such as the le system) while downloaded remote
itives that help to make the underlying protection code is not trusted and can access only the limited
mechanism more robust. resources provided inside the sandbox.

1 Introduction
Since the inception of Java [8, 11], there has been
strong and growing interest around the security of
Java as well as new security issues raised by the
deployment of Java. From a technology provider's
point of view, Java security includes two aspects [6]:
 Provide Java (primarily through JDK) as a se-
cure, ready-built platform on which to run Java
enabled applications in a secure fashion.
 Provide security tools and services imple-
mented in Java that enable a wider range of
security-sensitive applications, for example, in
the enterprise world. Figure 1: JDK1.0.x Security Model
This paper focuses on issues related to the rst This sandbox model is deployed through the Java
aspect, where the customers for such technologies Development Toolkit in versions 1.0.x, and is gen-
include vendors that bundle or embed Java in their erally adopted by applications built with JDK, in-
products (such as browsers and operating systems). cluding Java-enabled web browsers.
It is worth emphasizing that this work by itself Overall security is enforced through a number of
does not claim to break signi cant new ground in mechanisms. First of all, the language is designed
terms of the theory of computer security. Instead, to be type-safe, and easy to use. The hope is that
it o ers a real world example where well-known se- the burden on the programmer is such that it is less
curity principles [5, 12, 13, 16] are put into engi- likely to make subtle mistakes, compared with using
neering practice to construct a practical and widely other programming languages such as C or C++.
deployed secure system. Language features such as automatic memory man-
agement, garbage collection, and range checking on
strings and arrays are examples of how the language
helps the programmer to write safer code.
Second, compilers and a bytecode veri er ensure
that only legitimate Java code is executed. The
bytecode veri er, together with the Java virtual ma-
chine, guarantees language type safety at run time.
Moreover, a class loader de nes a local name
space, which is used to ensure that an untrusted
applet cannot interfere with the running of other
Java programs.
Finally, access to crucial system resources is me-
diated by the Java virtual machine and is checked in
advance by a SecurityManager class that restricts
to the minimum the actions of untrusted code.
JDK1.1.x introduced the concept of signed ap- Figure 3: JDK1.2 Security Model
plet. In this extended model, as shown in Figure 2,
a correctly digitally signed applet is treated as if it is to do substantial programming (e.g., by sub-
trusted local code if the signature key is recognized classing and customizing the SecurityManager
as trusted by the end system that receives the ap- and ClassLoader classes).
plet. Signed applets, together with their signatures, HotJava is such an example application. How-
are delivered in the JAR (Java Archive) format. ever, such programming is extremely security
sensitive and requires sophisticated skills and
in-depth knowledge of computer security. The
new architecture makes this exercise simpler
and safer.
 Easily con gurable security policy.
Once again, this feature exists in Java but is
not easy to use. This design goal implies that
the security and its implementation or enforce-
ment mechanism should be clearly separated.
Moreover, because writing security code is not
straightforward, it is desirable to allow appli-
cation builders and users to con gure security
policies without having to program.
 Easily extensible access control structure.
Figure 2: JDK1.1 Security Model Up to JDK1.1, to create a new access permis-
sion, one has to add a new check() method
The rest of this paper focuses on the new sys- to the SecurityManager class. The new ar-
tem security features. Discussion of various lan- chitecture allows typed permissions and au-
guage safety issues can be found elsewhere (e.g., tomatic handling. No new method in the
[3, 4, 19, 21]). SecurityManager class needs to be created in
most cases. (Actually, we have not encountered
1.2 Evolving the Sandbox Model a situation where a new method must be cre-
ated.)
The new security architecture in JDK1.2, as illus-
trated in Figure 3, is introduced primarily for the  Extension of security checks to all Java pro-
following purposes. grams, including applets as well as applications.
There should not be a built-in concept that all
 Fine-grained access control. local code is trusted. Instead, local code should
This capability has existed in Java from the be- be subjected to the same security controls as
ginning, but to use it, the application writer has applets, although one should have the choice
 to declare that the policy on local code (or re- [2, 1, 18]), where various research teams have lately
mote code) be the most liberal (thus local code aimed for some of the same goals with di erent pro-
e ectively runs as totally trusted). The same gramming techniques.
principle applies to signed applets and applica-
tions.
Finally, we also take this opportunity to make 2 New Protection Mechanisms
internal structural adjustment in order to reduce
the risks of creating subtle security holes in pro- This section covers the concept and implementa-
grams. This e ort involves revising the design tion of some important new primitives introduced in
and implementation of the SecurityManager and JDK1.2, namely, security policy, access permission,
ClassLoader classes as well as the underlying ac- protection domain, access control checking, privi-
cess control checking mechanism. leged operation, and Java class loading and resolu-
tion.
1.3 Related Work
The fundamental ideas adopted in the new secu-
2.1 Security Policy
rity architecture have roots in the last 40 years of There is a system security policy, set by the user
computer security research, such as the overall idea or by a system administrator, that is represented
of access control list [10]. We followed some of the by a policy object, which is instantiated from the
Unix conventions in specifying access permissions class java.security.Policy. There could be mul-
to the le system and other system resources, but tiple instances of the policy object, although only
signi cantly, our design has been inspired by the one is \in e ect" at any time. This policy object
concept of protection domains and the work deal- maintains a runtime representation of the policy, is
ing with mutually suspicious programs in Multics typically instantiated at the Java virtual machine
[17, 15], and right ampli cation in Hydra [9, 20]. start-up time, and can be changed later via a secure
One novel feature, which is not present in oper- mechanism.
ating systems such as Unix or MS-DOS, is that we In abstract terms, the security policy is a mapping
implement the least-privilege principle by automat- from a set of properties that characterize running
ically intersecting the sets of permissions granted to
protection domains that are involved in a call se- code to a set of access permissions that is granted
quence. This way, a programming error in system to the concerned code.1
or application software is less likely to be exploitable Currently, a piece of code is fully characterized
as a security hole. by its origin (its location as speci ed by a URL)
Note that although the Java Virtual Machine and the set of public keys that correspond to the
(JVM) typically runs over another hosting operat- set of private keys that have been used to sign
ing system such as Solaris, it may also run directly the code using one or more digital signature algo-
over hardware as in the case of the network com- rithms. Such characteristics are captured in the
puter JavaStation running JavaOS [14]. To main- class java.security.CodeSource, which can be
tain platform independence, our architecture does viewed as a natural extension of the concept of a
not depend on security features provided by an un- code base within HTML. (It is important not to con-
derlying operating system. fuse CodeSource with the CodeBase tag in HTML.)
Furthermore, our architecture does not override Wild cards are used to denote \any location" or
the protection mechanisms in the underlying oper- \unsigned".
ating system. For example, by con guring a ne- Informally speaking, for a code source to match
grained access control policy, a user may grant spe- an entry given in the policy, both the URL informa-
ci c permissions to certain software, but this is ef- tion and the signature information must match. For
fective only if the underlying operating system itself URL matching, if the code source's URL is a pre x
has granted the user those permissions. of an entry's URL, we consider this a match. For
Another signi cant character of JDK is that its signature matching, if one public key corresponding
protection mechanisms are language-based, within a to a signature in the code source matches the key of
single address space. This feature is a major distinc- a signer in the policy entry, we consider it a match.
tion from more traditional operating systems, but 1 In the future, the security policy can be extended to in-
is very much related to recent works on software- clude and consider information such user authentication and
based protection and safe kernel extensions (e.g., delegation.
 When a code source matches multiple policy en- cates) of Permission objects for a category
tries, for example, when the code is signed with mul- (such as FilePermission), for ease of grouping.
tiple signatures, permissions granted are additive in Permissions is a heterogeneous collection of col-
that the code is given all permissions contained in lections of Permission objects.
all the matching entries. For example, if code signed Not every permission class must support a corre-
with key A gets permission X and code signed by sponding collection class. When they do, it is crucial
key B gets permission Y, then code signed by both to implement the correct semantics for the implies
A and B gets permissions X and Y. method in the corresponding permission collection
Veri cation of signed code uses a new package of classes. For example, FilePermission can get added
certi cate java.security.cert that fully supports to the FilePermissionCollection object in any
the processing of X.509v3 certi cates. order, so the latter must know how to correctly com-
The policy within the Java runtime is set via a pare a permission with a permission collection.
programming API. We also specify an external pol- Typically, each permission consists of a target and
icy representation in the form of an ASCII policy an action thus, informally, a permission implies an-
con guration le. Such a le essentially contains a other if and only if both the target and the action of
list of entries, each being a pair, consisting of a code the former respectively implies those of the latter.
source and its permissions. In such a le, a public Take FilePermission for example. There are
key is signi ed by an alias { the string name of the two kinds of targets: a directory and a le. There
signer { where we provide a separate mechanism to are four ways to express a le target: path,
create aliases and import their matching public keys path/file, path/*, and path/-. path/* denotes
and certi cates. all les and directories in the directory path, and
path/- denotes all les and directories under the
2.2 Permission subtree of the le system starting at path. The ac-
tions include read, write, execute, and delete.
We have introduced a new hierarchy of typed Therefore, \read le /tmp/abc" is a permission,
and parameterized access permissions that is rooted and can be created using the following Java code:
by an abstract class java.security.Permission.
Other permissions are subclassed either from the p = new FilePermission("/tmp/abc", "read");
Permission class or one of its subclasses, and gen- Permission (/tmp/*, read) implies permission
erally should belong to their own packages. (/tmp/abc, read), but not vice versa. Permission
For example, the permission representing le (/home/gong/-, read,write) implies permission
system access is located in the Java I/O pack- (/home/gong/public html/index.html, read).
age, as java.io.FilePermission. Other permis- In the case of SocketPermission, a net target
sion classes that are introduced in JDK1.2 include: consists of an IP address and a range of port num-
java.net.SocketPermission for access to network bers. Actions include connect, listen, accept,
resources, java.lang.RuntimePermission for ac- and others. One SocketPermission implies another
cess to runtime system resources such as properties, if and only if the former covers the same IP address
and java.awt.AWTPermision for access to window- and the port numbers for the same set of actions.
ing resources. In other words, access methods and Applications are free to add new categories of per-
parameters to most of the controlled resources, in- missions. Note that a piece of Java code can cre-
cluding access to Java properties and packages, are ate any number of permission objects, but such ac-
represented by the new permission classes. tions do not grant the code the corresponding access
A crucial abstract method in the Permission rights. What matters is that permission objects the
class that needs to be implemented for each new Java runtime system associates with the Java code
class of permission is the implies method. Basi- through the concept of protection domains.
cally, a.implies(b) == true means that, if one is
granted permission a, then one is naturally granted 2.3 Protection Domain
permission b. This is the basis for all access control
decisions.
For convenience, we also created abstract classes A new class java.security.ProtectionDomain
java.security.PermissionCollection and is package-private, and is transparent to most Java
java.security.Permissions that are subclasses developers. It serves as a useful level of indirec-
of the Permission class. PermissionCollection tion in that permissions are granted to protection
is a collection (i.e., a set that allows dupli- domains, to which classes and objects belong, and
not to classes and objects directly.2 In other words, 2.4 Domain-Based Access Control
a domain can be scoped by the set of objects that
correspond to a principal, where a principal is an The decision of granting access to controlled re-
entity in the computer system to which authoriza- sources can only be made within the right context,
tions (and as a result, accountability) are granted which must provide answers to questions such as
[16]. The Java sandbox in JDK1.0.2 is one example \who is requesting what, on whose behalf". Of-
of a protection domain with a xed boundary. ten, a thread is the right context for access control.
In JDK1.2, protection domains are created \on Less frequently, access control decisions have to be
demand", based on code source. Each class belongs carried out among multiple threads that must co-
to one and only one domain. The Java runtime operate in obtaining the right context information.
maintains the mapping from code (classes and ob- This section focuses on the former, as it is the most
jects) to their protection domains and then to their common case encountered in building JDK1.2.
permissions. A thread of execution may occur completely
Protection domain also serves as a convenient within a single protection domain (i.e., all classes
point for grouping and isolation between units of and objects involved in the thread belong to the
protection within the Java runtime. For example, it identical protection domain) or may involve multi-
is possible to separate di erent domains from inter- ple domains such as an application domain and also
acting with each other. Any permitted interaction the system domain.
must be either through system code or explicitly al- For example, an application that prints a message
lowed by the domains concerned. out will have to interact with the system domain
that is the only access point to an output stream.
The above point brings up the issue of accessibil- In this case, it is crucial that at any time the appli-
ity, which is orthogonal to security. In the Java vir- cation domain does not gain additional permissions
tual machine, a class is distinguished by itself plus by calling the system domain. Otherwise, there can
the class loader instance that loaded the class. In be security serious implications.
other words, a class loader de nes a distinct name In the reverse situation where a system domain in-
space and can be used to isolate and protect code vokes a method from an application domain, such as
within one protection domain if the loader refuses to when the AWT system code calls an applet's paint
load code from di erent domains (and with di erent method to display the applet, it is again crucial that
permissions). at any time the e ective access rights are the same
On the other hand, it is sometimes desirable to as current rights enabled in the application domain.
allow code from di erent domains to interact with In other words, a less "powerful" domain cannot
each other { for example, in the case of an appli- gain additional permissions as a result of calling a
cation made up from Java Beans signed by di er- more powerful domain; whereas a more powerful do-
ent public keys, the beans should be able to ac- main must lose its power when calling a less pow-
cess each other (which is the purpose of the ap- erful domain. This principle of least privilege is ap-
plication) although the runtime environment may plied to a thread that transverses multiple protec-
insist that di erent beans are loaded into di erent tion domains.
domains. The AppletClassLoader class used by Up to JDK1.1, any code that performs an ac-
the appletviewer in JDK1.2 will load classes from cess control decision relies on explicitly knowing
di erent domains. its caller's status (i.e., being system code or applet
One protection domain is special: the system do- code). This is fragile in that it is often insuciently
main, which consists of system code that is loaded secure to know only the caller's status but also the
with a null class loader (basically all classes located caller's caller's status and so on. At this point, plac-
on CLASSPATH) and is given special privileges. It ing this discovery process explicitly on the typical
is important that all protected external resources, programmer becomes a serious burden, and can be
such as the le system, the networking facility, and error-prone.
the screen and keyboard, are directly accessible only To relieve this burden by automating the ac-
via system code. cess checking process, JDK1.2 introduces a new
class java.security.AccessController. Instead
2 In the future, protection domains can be further char-
of trying to discover the history of callers and
acterized by user authentication and delegation so that the their status within a thread, any code can query
same code could obtain di erent permissions when running the access controller as to whether a permission
\on behalf of" of di erent principals. would succeed if performed right now. This is
done by calling the checkPermission method of the e ective permissions is updated dynamically. The
AccessController class with a Permission object bene t is that checking whether a permission is al-
that represents the permission in question. lowed is simpli ed and can be faster in many cases.
By default, the access controller will return The disadvantage is that, because permission check-
silently only if all callers in the thread his- ing occurs much less frequently than cross-domain
tory (e.g., all classes on the call stack) be- calls, a large percentage of permission updates may
long to domains that have been granted the be useless e ort.
said permission. Otherwise, it throws a JDK1.2 employs a \lazy evaluation" implementa-
java.security.AccessControlException, which tion where, whenever a permission checking is re-
is a subclass of java.lang.SecurityException, quested, the thread state (as re ected by the cur-
usually printing the reason of denial. rent thread stack or its equivalent) is examined and
This default behavior is obviously the most se- a decision is reached to either deny or grant the
cure but is limiting in some cases where a piece of particular access requested. One potential down-
code wants to temporarily exercise its own permis- side of this approach is performance penalty at per-
sions that are not available directly to its callers. mission checking time, although this penalty would
For example, an applet may not have direct access have been incurred anyway in the "eager evalua-
to certain system properties, but the system code tion" approach (albeit at earlier times and spread
servicing the applet may need to obtain some prop- out among each cross-domain call). In our imple-
erties in order to complete its tasks. mentation, performance of this algorithm is quite
For such exceptional cases, we provide a prim- acceptable3 , so we feel that lazy evaluation is the
itive, via static methods beginPrivileged and most economical approach overall.
endPrivileged in the AccessController class. By
calling beginPrivileged, a piece of code is telling 2.5 Revised SecurityManager
the Java runtime system to ignore the status of its
callers and that it itself is taking responsibility in Up to JDK1.1., when access to a critical system
exercising its permissions. resource (such as le I/O and network I/O) is re-
To summarize, a simple and prudent rule of quested, the resource handling code directly or in-
thumb for calculating permissions is the following: directly invokes the appropriate check method on
the installed java.lang.SecurityManager to eval-
 The permission of an execution thread is the uate the request and decide if the request should be
intersection of the permissions of all protection granted or denied.
domains transversed by the execution thread. JDK1.2 maintains backward compatibility in that
 When some code calls the beginPrivileged all check() methods in SecurityManager are still
primitive, the permission of the execution supported, but we have changed their default im-
thread includes a permission if it is allowed by plementations to invoke AccessController, when-
the said code's protection domain and by all ever feasible, with the appropriate permission ob-
protection domains that are called or entered ject. This class, which has been abstract up to
directly or indirectly subsequently. JDK1.1.x, is made concrete in JDK1.2.
To illustrate the usage of the new access con-
 When a new thread is created, it inherits from trol mechanism, let us examine a small example for
its parent thread the current security context checking le access. In earlier versions of the JDK,
(i.e., the set of protection domains present in the following code is typical:
the parent at child creation time). This inheri-
tance is transitive. ClassLoader loader =
this.getClass().getClassLoader();
if (loader != null) {
In following the above rule, the access con- SecurityManager security =
troller examines the call history and the permissions System.getSecurityManager();
granted to the relevant protection domains, and to if (security != null) {
return silently if the request is granted or throw a security.checkRead("path/file");
security exception if the request is denied. }
There are two obvious strategies for implement- }
ing this access control rule. In an \eager evalua- 3 For details of the implementation of protection domain,
tion" implementation, whenever a thread enters a and a discussion on performance and optimization tech-
new protection domain or exits from one, the set of niques, please refer to [7].
 Under the new architecture, the check typically java.lang.ClassLoader that loads classes and
should be invoked whether or not there is a class- records the protection domains they belong to. It
loader associated with a calling class. It should be also provides methods to load a class from byte-
simply: code stored in a byte array, an URL, and an
InputStream. This class can be extended to include
FilePermission p =
new FilePermission("path/file", "read");
new methods, but most existing methods are nal,
AccessController.checkPermission(p);
as this class is signi cant for security.
All applets and applications (except for system
Note that there are legacy cases (for example, in classes) are loaded by a SecureClassLoader either
some browsers) where whether there is an instance directly or indirectly (in which case, it is probably
of the SecurityManager class installed signi es one loaded by another classloader that itself is loaded
or the other security state that may result in dif- by a SecureClassLoader).
ferent actions being taken. We currently do not SecureClassLoader's loadClass methods en-
change this aspect of the SecurityManager usage, force the following search algorithm where, if the
but would encourage application developers to use desired class (by the given name) is not found, the
the techniques introduced in this new version of the next step is taken. If the class is still not found
JDK in their future programming. after the last step, a ClassNotFoundException is
Moreover, we have not revised system code to thrown.
always call AccessController (and not check-
ing for the existence of a classloader), because 1. See if the class is already loaded and resolved
of the potential of existing software subclassing
the SecurityManager and customizing these check 2. See if the class requested is a system class. if so,
methods. load the class with the null system classloader.
To use the privilege primitive, the following code
sample should be followed: 3. Attempt to nd the class in a customizable way,
using a non- nal method findAppClass, which
try { by default will try to nd the class in a second
AccessController.beginPrivileged(); local search path that is de ned by a property
(some sensitive code)
} finally {
named java.app.class.path.
}
AccessController.endPrivileged();
Note that in step 2, all classes on the search
path CLASSPATH are treated as system classes,
Some important points about being privileged. whereas in step 3, all classes on the search path
Firstly, this concept only exists within a single java.app.class.path are considered non-system
thread. That is, a protection domain being so priv- classes.4
ileged is scoped by the thread within which the call Programmers who must write class loaders
to become privileged is made. Other threads are not should, whenever feasible, subclass from the con-
a ected. crete SecureClassLoader class, and not directly
Secondly, in this example, the body of code within from the abstract class java.lang.ClassLoader.
try- nally is privileged. However, it will lose its A subclass of SecureClassLoader may choose to
privilege if it calls (from within the privileged block) overwrite the findAppClass method in order to cus-
code that is less privileged. tomize class searching and loading. For example,
Moreover, although it is a good idea to use the AppletClassLoader caches all raw class mate-
beginPrivileged and endPrivileged in pairs as rials found inside a JAR le. Thus, it is reasonable
this clearly scopes the privileged code, we have for the AppletClassLoader, which is a subclass of
to deal with the case when endPrivileged is not the SecureClassLoader, to use findAppClass to
called, because forgetting to disable a privilege can look into its own cache. A class introduced in such
be very dangerous. To reduce or eliminate the risk, a fashion is guaranteed not to be a system class,
we have put in additional mechanism to safe guard and is subjected to the same security policy as its
this primitive. loading class.
2.6 Secure Class Loading 4 The path java.app.class.path is currently speci ed in
a platform dependent format. There might be a future need
to develop a generic Path class that not only provides plat-
The class java.security.SecureClassLoader is form independentpath names but also makes dynamical path
a concrete implementation of the abstract class manipulation easier.
 Often a class may refer to an another class and For a software library developer whose code con-
thus cause the second class belonging to another trols certain resources, the developer may need to
domain to be loaded. Typically the second class is extend the existing permission class hierarchy to
loaded by the same classloader that loaded the rst create application-speci c permissions. The devel-
class, except when either class is a system class, in oper may also need to learn to use features provided
which case the system class is loaded with a null by the AccessController class, such as the privi-
classloader. lege primitive.
2.7 Extending Security to Applications 3.2 Handling Non-Class Content
To apply the same security policy to applications When running applets or applications with signed
found on the local le system, we provide a new class content, the JAR and Manifest speci cations on
java.security.Main, which can be used in the fol- code signing allow a very exible format. Recall
lowing fashion in place of the traditional command that classes within the same archive can be un-
java application to invoke a local application: signed, signed with one key, or signed with multiple
java java.security.Main application keys. Other resources within the archive, such as
This usage makes sure that any local applica- audio clips and graphic images, can also be signed
tion on the java.app.class.path is loaded with or unsigned.
a SecureClassLoader and therefore is subjected to This exibility brings about the issue of inter-
the security policy that is being enforced. Clearly, pretation. The following questions need to be
non-system classes that are stored on the local answered, especially when not all signatures are
le system should all be on this path, not on the granted the same privileges. Should images and au-
CLASSPATH.
dio clips be required to be signed with the same key
if any class in the archive is signed? If images and
audio les are signed with di erent keys, can they
be placed in the same appletviewer (or browser
3 Discussion page), or should they be sent to di erent viewers?
These questions are not easy to answer, and re-
In this section, we discuss a number of open ques- quire consistency across platforms and products to
tions and possible improvement to the current archi- be most e ective. Our intermediate approach is
tecture. But we start by discussing how a developer to provide a simple answer { all images and audio
or user is impacted by the new architecture. clips are forwarded to be processed whether they
are signed or not. This temporary solution will be
3.1 Utilizing the New Architecture improved once a consensus is reached.
For a user of the built-in appletviewer or a new 3.3 Enabling Fine-Grained Privileges
version of a browser that deploys this new security
architecture, the user can continue to do things the The privileged primitive discussed earlier in a
same way as before, which means that the same sense \enables" all permissions granted to a domain.
policy in JDK1.1.x will apply. We can contemplate to enrich the construct so that
On the other hand, a \power user" can use the a protection domain can request to enable privi-
PolicyTool built-in for JDK1.2 (or an equivalent lege for only some of its granted permissions. This
one shipped with the browser) to customize the se- should further reduce the security impact of making
curity policy, thus utilizing the full bene t of the a programming mistake. For example, the code seg-
new security architecture. Such customization may ment below illustrates how to turn on the privilege
involve setting up a certi cate store, which can be of only reading everything in the "/tmp" directory.
done via the KeyTool.
The typical application developer, in general, FilePermission p =
new FilePermission("/tmp/*", "read");
needs to do nothing special because, when the appli- try {
cation is run on top of JDK1.2, the security features AccessController.beginPrivileged(p);
are invoked automatically. Except that the devel- some sensitive code
oper might want to use the built-in tools to package } finally {
the resulting application into JAR les, and may AccessController.endPrivileged(p);
choose to digitally sign them. }
3.4 Extending Protection Domains ditional features such as arbitrary grouping of per-
missions, the composition of security policies, and
The rst possibility is to subdivide the system do- resource consumption management, which is rela-
main. For convenience, we can think of the system tively easy to implement in some cases, e.g., when
domain as a single, big collection of all system code. limiting the number of windows any application can
For better protection, though, system code should pop up at any one time, but more dicult in other
be run in multiple system domains, where each do- cases, e.g., when limiting memory or le system us-
main protects a particular type of resource and is age.
given a special set of rights. For example, if le sys-
tem code and network system code run in separate
domains, where the former has no rights to the net-
working resources and the latter has no rights to the
Acknowledgments
le system resources, the risks and consequence of Additional members of the JavaSoft security
an error or security aw in one system domain is group, including Gigi Ankeny, Charlie Lai, Jan
more likely to be con ned within its boundary. Luehe, and Je Nisewanger, made signi cant con-
Moreover, protection domains currently are cre- tributions during the course of the design and im-
ated transparently as a result of class loading. It plementation of new security features in JDK1.2.
might be desirable to provide explicit primitives to Other members of the JavaSoft community, no-
create a new domain. Often, a domain supports in- tably Josh Bloch, Sheng Liang, Roger Riggs, Nakul
heritance in that a sub-domain automatically inher- Saraiya, and Bill Shannon, provided invaluable in-
its the parent domain's security attributes, except sight, detailed reviews, and much needed technical
in certain cases where the parent further restricts or assistance.
expands the sub-domain explicitly. We are grateful for support from Dick Neiss, Jon
Finally, each domain (system or application) may Kannegaard, and Alan Baratz, for technical guid-
also implement additional protection of its internal ance from James Gosling, Graham Hamilton, and
resources within its own domain boundary. Because Jim Mitchell, and for indispensable collaboration
the semantics of such protection is unlikely to be from the testing and documentation groups. We
predictable by the JDK, the protection system at received numerous suggestions from our corporate
this level is best left to the application develop- partners and licensees, whom we could not fully list
ers. Nevertheless, JDK1.2 provides SignedObject, here.
Guard, and GuardedObject classes that simplify a
developer's task.
References
4 Summary and Future Work [1] B. N. Bershad, S. Savage, P. Pardyak, E. G.
This paper gives an overview of the motivation Sirer, M. Fiuchynski, D. Becker, S. Eggers, and
and the new security architecture implemented in C. Chambers. Extensibility, Safety, and Per-
JDK1.2. Although we do not break new theo- formance in the SPIN Operating System. In
Proceedings of the 15th ACM Symposium on
retical ground in computer security, we attempt Operating Systems Principles, pages 251{266,
to distill the best practices from research in the Colorado, December 1995. Published as ACM
past four decades, such as clear separation between Operating System Review 29(5):251{266, 1995.
security policy and implementation, and engineer
them into a widely deployed programming platform. [2] J.S. Chase, H.M. Levy, M.J. Feeley, and E.D.
Our implementation has a number of novel aspects Lazowska. Sharing and Protection in a Single-
that demonstrate beyond the doubt the eciency Address-Space Operating System. ACM Trans-
of language-based protection mechanisms. The suc- actions on Computer Systems, 12(4):271{307,
cess of this development e ort also highlights the November 1994.
excellent extensibility of the Java platform.
In future releases, we are investigating user au- [3] D. Dean. The Security of Static Typing with
thentication techniques, an explicit principal con- Dynamic Linking. In Proceedings of the 4th
cept, a general mechanism for cross-protection- ACM Conference on Computer and Communi-
domain authorization, and the \running-on-behalf" cations Security, pages 18{27, Zurich, Switzer-
style delegation. We are also working towards ad- land, April 1997.
 [4] D. Dean, E.W. Felten, and D.S. Wallach. Java [17] M.D. Schroeder. Cooperation of Mutually
Security: From HotJava to Netscape and Be- Suspicious Subsystems in a Computer Utility.
yond. In Proceedings of the IEEE Symposium Ph.D. dissertation, Massachusetts Institute of
on Research in Security and Privacy, pages Technology, Cambridge, MA 02139, September
190{200, Oakland, California, May 1996. 1972.
[5] M. Gasser. Building a Secure Computer Sys- [18] M. I. Seltzer, Y. Endo, C. Small, and K. A.
tem. Van Nostrand Reinhold Co., New York, Smith. Dealing with Disaster: Surviving Mis-
1988. behaved Kernel Extensions. In Proceedings of
the 2nd USENIX Symposium on Operating Sys-
[6] L. Gong. Java Security: Present and Near tems Design and Implementation, pages 213{
Future. IEEE Micro, 17(3):14{19, May/June 227, Seattle, Washington, October 1996. Pub-
1997. lished as ACM Operating Systems Review, 30,
[7] L. Gong and R. Schemers. Implementing Pro- special winter issue, 1996.
tection Domains in the JavaTM Development Kit [19] T. Thorn. Programming Languages for Mobile
1.2. In Proceedings of the Internet Society Sym- Code. ACM Cumpting Surveys, 29(3):213{239,
posium on Network and Distributed System Se- September 1997.
curity, San Diego, California, March 1998.
[20] W.A. Wulf, R. Levin, and S.P. Harbison. HY-
[8] J. Gosling, Bill Joy, and Guy Steele. The DRA/C.mmp { An Experimental Computer
Java Language Speci cation. Addison-Wesley, System. McGraw-Hill, 1981.
Menlo Park, California, August 1996.
[21] F. Yellin. Low Level Security in Java. In Pro-
[9] A.K. Jones. Protection in Programmed Sys- ceedings of the 4th International World Wide
tems. Ph.D. dissertation, Carnegie-Mellon Uni- Web Conference, Boston, Massachusetts, De-
versity, Pittsburgh, PA 15213, June 1973. cember 1995.
[10] B.W. Lampson. Protection. In Proceedings
of the 5th Princeton Symposium on Informa-
tion Sciences and Systems, Princeton Univer-
sity, March 1971. Reprinted in ACM Operating
Systems Review, 8(1):18{24, January, 1974.
[11] T. Lindholm and F. Yellin. The Java Virtual
Machine Speci cation. Addison-Wesley, Menlo
Park, California, 1997.
[12] P.G. Neumann. Computer-Related Risks.
Addison-Wesley, Menlo Park, California, 1995.
[13] U.S. General Accounting Oce. Information
Security: Computer Attacks at Department
of Defense Pose Increasing Risks. Technical
Report GAO/AIMD-96-84, Washington, D.C.
20548, May 1996.
[14] S. Ritchie. Systems Programming in Java.
IEEE Micro, 17(3):30{35, May/June 1997.
[15] J.H. Saltzer. Protection and the Control of In-
formation Sharing in Multics. Communications
of the ACM, 17(7):388{402, July 1974.
[16] J.H. Saltzer and M.D. Schroeder. The Pro-
tection of Information in Computer Systems.
Proceedings of the IEEE, 63(9):1278{1308,
September 1975.