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:
`office@usenix.org
`4. WWW URL: http://www.usenix.org/
`
`Blue Coat Systems - Exhibit 1016 Page 1
`
`

`
`Going Beyond the Sandbox: An Overview of the New Security
`Architecture in the JavaTM Development Kit .
`
`Li Gong, Marianne Mueller, Hemma Prafullchandra, and Roland Schemers
`
`JavaSoft, Sun Microsystems, Inc.
`fgong,mrm,hemma,schemersg@eng.sun.com
`
`Abstract
`
` . The Original Security Model
`
`This paper describes the new security architec-
`ture that has been implemented as part of JDK .,
`the forthcoming JavaTM Development Kit. In going
`beyond the sandbox security model in the original
`release of Java, JDK . provides ne-grained ac-
`cess control via an easily congurable security pol-
`icy. Moreover, JDK . introduces the concept of
`protection domain and a few related security prim-
`itives that help to make the underlying protection
`mechanism more robust.
`
`The original security model provided by Java is
`known as the sandbox model, which exists in order
`to provide a very restricted environment in which
`to run untrusted code called applet obtained from
`the open network. The essence of the sandbox
`model, as illustrated by Figure , is that local code is
`trusted to have full access to vital system resources
`such as the le system while downloaded remote
`code is not trusted and can access only the limited
`resources provided inside the sandbox.
`
` Introduction
`
`Since the inception of Java , , 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 :
`
` Provide Java primarily through JDK as a se-
`cure, ready-built platform on which to run Java
`enabled applications in a secure fashion.
`
`imple-
` Provide security tools and services
`mented in Java that enable a wider range of
`security-sensitive applications, for example, in
`the enterprise world.
`
`Figure : JDK ..x Security Model
`
`This paper focuses on issues related to the rst
`aspect, where the customers for such technologies
`include vendors that bundle or embed Java in their
`products such as browsers and operating systems.
`It is worth emphasizing that this work by itself
`does not claim to break signicant new ground in
`terms of the theory of computer security. Instead,
`it oers a real world example where well-known se-
`curity principles , , ,  are put into engi-
`neering practice to construct a practical and widely
`deployed secure system.
`
`This sandbox model is deployed through the Java
`Development Toolkit in versions ..x, and is gen-
`erally adopted by applications built with JDK, in-
`cluding Java-enabled web browsers.
`Overall security is enforced through a number of
`mechanisms. First of all, the language is designed
`to be type-safe, and easy to use. The hope is that
`the burden on the programmer is such that it is less
`likely to make subtle mistakes, compared with using
`other programming languages such as C or C++.
`Language features such as automatic memory man-
`
`Blue Coat Systems - Exhibit 1016 Page 2
`
`

`
`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 verier ensure
`that only legitimate Java code is executed. The
`bytecode verier, together with the Java virtual ma-
`chine, guarantees language type safety at run time.
`Moreover, a class loader denes 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.
`JDK . .x introduced the concept of signed ap-
`plet. In this extended model, as shown in Figure ,
`a correctly digitally signed applet is treated as if it is
`trusted local code if the signature key is recognized
`as trusted by the end system that receives the ap-
`plet. Signed applets, together with their signatures,
`are delivered in the JAR Java Archive format.
`
`Figure : JDK . Security Model
`
`The rest of this paper focuses on the new sys-
`tem security features. Discussion of various lan-
`guage safety issues can be found elsewhere e.g.,
` , , ,  .
`
` . Evolving the Sandbox Model
`
`The new security architecture in JDK ., as illus-
`trated in Figure , is introduced primarily for the
`following purposes.
`
` Fine-grained access control.
`
`This capability has existed in Java from the be-
`ginning, but to use it, the application writer has
`
`Figure : JDK . Security Model
`
`to do substantial programming e.g., by sub-
`classing and customizing the SecurityManager
`and ClassLoader classes.
`
`HotJava is such an example application. How-
`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 congurable 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 congure security
`policies without having to program.
`
` Easily extensible access control structure.
`
`Up to JDK . , to create a new access permis-
`sion, one has to add a new check method
`to the SecurityManager class. The new ar-
`chitecture allows typed permissions and au-
`tomatic handling. No new method in the
`SecurityManager class needs to be created in
`most cases. Actually, we have not encountered
`a situation where a new method must be cre-
`ated.
`
` Extension of security checks to all Java pro-
`grams, including applets as well as applications.
`
`There should not be a built-in concept that all
`local code is trusted. Instead, local code should
`be subjected to the same security controls as
`applets, although one should have the choice
`
`Blue Coat Systems - Exhibit 1016 Page 3
`
`

`
`to declare that the policy on local code or re-
`mote code be the most liberal thus local code
`eectively runs as totally trusted. The same
`principle applies to signed applets and applica-
`tions.
`
`Finally, we also take this opportunity to make
`internal structural adjustment in order to reduce
`the risks of creating subtle security holes in pro-
`grams. This eort involves revising the design
`and implementation of the SecurityManager and
`ClassLoader classes as well as the underlying ac-
`cess control checking mechanism.
`
` . Related Work
`
`The fundamental ideas adopted in the new secu-
`rity architecture have roots in the last  years of
`computer security research, such as the overall idea
`of access control list  . We followed some of the
`Unix conventions in specifying access permissions
`to the le system and other system resources, but
`signicantly, our design has been inspired by the
`concept of protection domains and the work deal-
`ing with mutually suspicious programs in Multics
` , , and right amplication in Hydra  , .
`One novel feature, which is not present in oper-
`ating systems such as Unix or MS-DOS, is that we
`implement the least-privilege principle by automat-
`ically intersecting the sets of permissions granted to
`protection domains that are involved in a call se-
`quence. This way, a programming error in system
`or application software is less likely to be exploitable
`as a security hole.
`Note that although the Java Virtual Machine
`JVM typically runs over another hosting operat-
`ing system such as Solaris, it may also run directly
`over hardware as in the case of the network com-
`puter JavaStation running JavaOS  . To main-
`tain platform independence, our architecture does
`not depend on security features provided by an un-
`derlying operating system.
`Furthermore, our architecture does not override
`the protection mechanisms in the underlying oper-
`ating system. For example, by conguring a ne-
`grained access control policy, a user may grant spe-
`cic permissions to certain software, but this is ef-
`fective only if the underlying operating system itself
`has granted the user those permissions.
`Another signicant character of JDK is that its
`protection mechanisms are language-based, within a
`single address space. This feature is a major distinc-
`tion from more traditional operating systems, but
`is very much related to recent works on software-
`based protection and safe kernel extensions e.g.,
`
`, , , where various research teams have lately
`aimed for some of the same goals with dierent pro-
`gramming techniques.
`
` New Protection Mechanisms
`
`This section covers the concept and implementa-
`tion of some important new primitives introduced in
`JDK ., namely, security policy, access permission,
`protection domain, access control checking, privi-
`leged operation, and Java class loading and resolu-
`tion.
`
`. Security Policy
`
`There is a system security policy, set by the user
`or by a system administrator, that is represented
`by a policy object, which is instantiated from the
`class java.security.Policy. There could be mul-
`tiple instances of the policy object, although only
`one is in eect" at any time. This policy object
`maintains a runtime representation of the policy, is
`typically instantiated at the Java virtual machine
`start-up time, and can be changed later via a secure
`mechanism.
`In abstract terms, the security policy is a mapping
`from a set of properties that characterize running
`code to a set of access permissions that is granted
`to the concerned code.
`Currently, a piece of code is fully characterized
`by its origin its location as specied by a URL
`and the set of public keys that correspond to the
`set of private keys that have been used to sign
`the code using one or more digital signature algo-
`rithms. Such characteristics are captured in the
`class java.security.CodeSource, which can be
`viewed as a natural extension of the concept of a
`code base within HTML. It is important not to con-
`fuse CodeSource with the CodeBase tag in HTML.
`Wild cards are used to denote any location" or
`unsigned".
`Informally speaking, for a code source to match
`an entry given in the policy, both the URL informa-
`tion and the signature information must match. For
`URL matching, if the code source’s URL is a prex
`of an entry’s URL, we consider this a match. For
`signature matching, if one public key corresponding
`to a signature in the code source matches the key of
`a signer in the policy entry, we consider it a match.
`
` In the future, the security policy can be extended to in-
`clude and consider information such user authentication and
`delegation.
`
`Blue Coat Systems - Exhibit 1016 Page 4
`
`

`
`When a code source matches multiple policy en-
`tries, for example, when the code is signed with mul-
`tiple signatures, permissions granted are additive in
`that the code is given all permissions contained in
`all the matching entries. For example, if code signed
`with key A gets permission X and code signed by
`key B gets permission Y, then code signed by both
`A and B gets permissions X and Y.
`Verication of signed code uses a new package of
`certicate java.security.cert that fully supports
`the processing of X. v certicates.
`The policy within the Java runtime is set via a
`programming API. We also specify an external pol-
`icy representation in the form of an ASCII policy
`conguration le. Such a le essentially contains a
`list of entries, each being a pair, consisting of a code
`source and its permissions. In such a le, a public
`key is signied by an alias  the string name of the
`signer  where we provide a separate mechanism to
`create aliases and import their matching public keys
`and certicates.
`
`. Permission
`
`We have introduced a new hierarchy of typed
`and parameterized access permissions that is rooted
`by an abstract class java.security.Permission.
`Other permissions are subclassed either from the
`Permission class or one of its subclasses, and gen-
`erally should belong to their own packages.
`For example, the permission representing le
`system access is located in the Java IO pack-
`age, as java.io.FilePermission. Other permis-
`sion classes that are introduced in JDK . include:
`java.net.SocketPermission for access to network
`resources, java.lang.RuntimePermission for ac-
`cess to runtime system resources such as properties,
`and java.awt.AWTPermision for access to window-
`ing resources. In other words, access methods and
`parameters to most of the controlled resources, in-
`cluding access to Java properties and packages, are
`represented by the new permission classes.
`A crucial abstract method in the Permission
`class that needs to be implemented for each new
`class of permission is the implies method. Basi-
`cally, a.impliesb == true means that, if one is
`granted permission a, then one is naturally granted
`permission b. This is the basis for all access control
`decisions.
`For convenience, we also created abstract classes
`and
`java.security.PermissionCollection
`java.security.Permissions that are subclasses
`of the Permission class. PermissionCollection
`is a collection i.e., a set
`that allows dupli-
`
`for a category
`cates of Permission objects
`such as FilePermission, for ease of grouping.
`Permissions is a heterogeneous collection of col-
`lections of Permission objects.
`Not every permission class must support a corre-
`sponding collection class. When they do, it is crucial
`to implement the correct semantics for the implies
`method in the corresponding permission collection
`classes. For example, FilePermission can get added
`to the FilePermissionCollection object in any
`order, so the latter must know how to correctly com-
`pare a permission with a permission collection.
`Typically, each permission consists of a target and
`an action thus, informally, a permission implies an-
`other if and only if both the target and the action of
`the former respectively implies those of the latter.
`Take FilePermission for example. There are
`two kinds of targets: a directory and a le. There
`are four ways to express a le target:
`path,
`pathfile, path*, and path-. path* denotes
`all les and directories in the directory path, and
`path- denotes all les and directories under the
`subtree of the le system starting at path. The ac-
`tions include read, write, execute, and delete.
`Therefore, read le tmpabc" is a permission,
`and can be created using the following Java code:
`
`p = new FilePermission"tmpabc", "read";
`Permission tmp*, read
`implies permission
`tmpabc, read, but not vice versa. Permission
`homegong-, read,write implies permission
`homegongpublic htmlindex.html, read.
`In the case of SocketPermission, a net target
`consists of an IP address and a range of port num-
`bers. Actions include connect, listen, accept,
`and others. One SocketPermission implies another
`if and only if the former covers the same IP address
`and the port numbers for the same set of actions.
`Applications are free to add new categories of per-
`missions. Note that a piece of Java code can cre-
`ate any number of permission objects, but such ac-
`tions do not grant the code the corresponding access
`rights. What matters is that permission objects the
`Java runtime system associates with the Java code
`through the concept of protection domains.
`
`. Protection Domain
`
`A new class java.security.ProtectionDomain
`is package-private, and is transparent to most Java
`developers.
`It serves as a useful level of indirec-
`tion in that permissions are granted to protection
`domains, to which classes and objects belong, and
`
`Blue Coat Systems - Exhibit 1016 Page 5
`
`

`
`not to classes and objects directly. In other words,
`a domain can be scoped by the set of objects that
`correspond to a principal, where a principal is an
`entity in the computer system to which authoriza-
`tions and as a result, accountability are granted
` . The Java sandbox in JDK .. is one example
`of a protection domain with a xed boundary.
`
`In JDK ., protection domains are created on
`demand", based on code source. Each class belongs
`to one and only one domain. The Java runtime
`maintains the mapping from code classes and ob-
`jects to their protection domains and then to their
`permissions.
`
`Protection domain also serves as a convenient
`point for grouping and isolation between units of
`protection within the Java runtime. For example, it
`is possible to separate dierent domains from inter-
`acting with each other. Any permitted interaction
`must be either through system code or explicitly al-
`lowed by the domains concerned.
`
`The above point brings up the issue of accessibil-
`ity, which is orthogonal to security. In the Java vir-
`tual machine, a class is distinguished by itself plus
`the class loader instance that loaded the class. In
`other words, a class loader denes a distinct name
`space and can be used to isolate and protect code
`within one protection domain if the loader refuses to
`load code from dierent domains and with dierent
`permissions.
`
`On the other hand, it is sometimes desirable to
`allow code from dierent domains to interact with
`each other  for example, in the case of an appli-
`cation made up from Java Beans signed by dier-
`ent public keys, the beans should be able to ac-
`cess each other which is the purpose of the ap-
`plication although the runtime environment may
`insist that dierent beans are loaded into dierent
`domains. The AppletClassLoader class used by
`the appletviewer in JDK . will load classes from
`dierent domains.
`
`One protection domain is special: the system do-
`main, which consists of system code that is loaded
`with a null class loader basically all classes located
`on CLASSPATH and is given special privileges.
`It
`is important that all protected external resources,
`such as the le system, the networking facility, and
`the screen and keyboard, are directly accessible only
`via system code.
`
`In the future, protection domains can be further char-
`acterized by user authentication and delegation so that the
`same code could obtain dierent permissions when running
`on behalf of" of dierent principals.
`
`. Domain-Based Access Control
`
`The decision of granting access to controlled re-
`sources can only be made within the right context,
`which must provide answers to questions such as
`who is requesting what, on whose behalf". Of-
`ten, a thread is the right context for access control.
`Less frequently, access control decisions have to be
`carried out among multiple threads that must co-
`operate in obtaining the right context information.
`This section focuses on the former, as it is the most
`common case encountered in building JDK ..
`A thread of execution may occur completely
`within a single protection domain i.e., all classes
`and objects involved in the thread belong to the
`identical protection domain or may involve multi-
`ple domains such as an application domain and also
`the system domain.
`For example, an application that prints a message
`out will have to interact with the system domain
`that is the only access point to an output stream.
`In this case, it is crucial that at any time the appli-
`cation domain does not gain additional permissions
`by calling the system domain. Otherwise, there can
`be security serious implications.
`In the reverse situation where a system domain in-
`vokes a method from an application domain, such as
`when the AWT system code calls an applet’s paint
`method to display the applet, it is again crucial that
`at any time the eective access rights are the same
`as current rights enabled in the application domain.
`In other words, a less "powerful" domain cannot
`gain additional permissions as a result of calling a
`more powerful domain; whereas a more powerful do-
`main must lose its power when calling a less pow-
`erful domain. This principle of least privilege is ap-
`plied to a thread that transverses multiple protec-
`tion domains.
`Up to JDK . , any code that performs an ac-
`cess control decision relies on explicitly knowing
`its caller’s status i.e., being system code or applet
`code. This is fragile in that it is often insuciently
`secure to know only the caller’s status but also the
`caller’s caller’s status and so on. At this point, plac-
`ing this discovery process explicitly on the typical
`programmer becomes a serious burden, and can be
`error-prone.
`To relieve this burden by automating the ac-
`cess checking process, JDK . introduces a new
`class java.security.AccessController. Instead
`of trying to discover the history of callers and
`their status within a thread, any code can query
`the access controller as to whether a permission
`would succeed if performed right now. This is
`
`Blue Coat Systems - Exhibit 1016 Page 6
`
`

`
`done by calling the checkPermission method of the
`AccessController class with a Permission object
`that represents the permission in question.
`By default,
`the access controller will return
`silently only if all callers
`in the thread his-
`tory e.g., all classes on the call
`stack be-
`long to domains that have been granted the
`said permission.
`Otherwise,
`it
`throws
`a
`java.security.AccessControlException, which
`is a subclass of java.lang.SecurityException,
`usually printing the reason of denial.
`This default behavior is obviously the most se-
`cure but is limiting in some cases where a piece of
`code wants to temporarily exercise its own permis-
`sions that are not available directly to its callers.
`For example, an applet may not have direct access
`to certain system properties, but the system code
`servicing the applet may need to obtain some prop-
`erties in order to complete its tasks.
`For such exceptional cases, we provide a prim-
`itive, via static methods beginPrivileged and
`endPrivileged in the AccessController class. By
`calling beginPrivileged, a piece of code is telling
`the Java runtime system to ignore the status of its
`callers and that it itself is taking responsibility in
`exercising its permissions.
`To summarize, a simple and prudent rule of
`thumb for calculating permissions is the following:
`
` The permission of an execution thread is the
`intersection of the permissions of all protection
`domains transversed by the execution thread.
`
` When some code calls the beginPrivileged
`primitive,
`the permission of the execution
`thread includes a permission if it is allowed by
`the said code’s protection domain and by all
`protection domains that are called or entered
`directly or indirectly subsequently.
`
` When a new thread is created, it inherits from
`its parent thread the current security context
`i.e., the set of protection domains present in
`the parent at child creation time. This inheri-
`tance is transitive.
`
`In following the above rule, the access con-
`troller examines the call history and the permissions
`granted to the relevant protection domains, and to
`return silently if the request is granted or throw a
`security exception if the request is denied.
`There are two obvious strategies for implement-
`ing this access control rule.
`In an eager evalua-
`tion" implementation, whenever a thread enters a
`new protection domain or exits from one, the set of
`
`eective permissions is updated dynamically. The
`benet is that checking whether a permission is al-
`lowed is simplied and can be faster in many cases.
`The disadvantage is that, because permission check-
`ing occurs much less frequently than cross-domain
`calls, a large percentage of permission updates may
`be useless eort.
`JDK . employs a lazy evaluation" implementa-
`tion where, whenever a permission checking is re-
`quested, the thread state as reected by the cur-
`rent thread stack or its equivalent is examined and
`a decision is reached to either deny or grant the
`particular access requested. One potential down-
`side of this approach is performance penalty at per-
`mission checking time, although this penalty would
`have been incurred anyway in the "eager evalua-
`tion" approach albeit at earlier times and spread
`out among each cross-domain call. In our imple-
`mentation, performance of this algorithm is quite
`acceptable , so we feel that lazy evaluation is the
`most economical approach overall.
`
`. Revised SecurityManager
`
`Up to JDK . ., when access to a critical system
`resource such as le IO and network IO is re-
`quested, the resource handling code directly or in-
`directly invokes the appropriate check method on
`the installed java.lang.SecurityManager to eval-
`uate the request and decide if the request should be
`granted or denied.
`JDK . maintains backward compatibility in that
`all check methods in SecurityManager are still
`supported, but we have changed their default im-
`plementations to invoke AccessController, when-
`ever feasible, with the appropriate permission ob-
`ject. This class, which has been abstract up to
`JDK . .x, is made concrete in JDK ..
`To illustrate the usage of the new access con-
`trol mechanism, let us examine a small example for
`checking le access. In earlier versions of the JDK,
`the following code is typical:
`
`ClassLoader loader =
`this.getClass.getClassLoader;
`if loader != null 
`SecurityManager security =
`System.getSecurityManager;
`if security != null 
`security.checkRead"pathfile";
`
`
`
`
`
` For details of the implementation of protection domain,
`and a discussion on performance and optimization tech-
`niques, please refer to .
`
`Blue Coat Systems - Exhibit 1016 Page 7
`
`

`
`Under the new architecture, the check typically
`should be invoked whether or not there is a class-
`loader associated with a calling class. It should be
`simply:
`
`FilePermission p =
`new FilePermission"pathfile", "read";
`AccessController.checkPermissionp;
`
`Note that there are legacy cases for example, in
`some browsers where whether there is an instance
`of the SecurityManager class installed signies one
`or the other security state that may result in dif-
`ferent actions being taken. We currently do not
`change this aspect of the SecurityManager usage,
`but would encourage application developers to use
`the techniques introduced in this new version of the
`JDK in their future programming.
`Moreover, we have not revised system code to
`always call AccessController and not check-
`ing for the existence of a classloader, because
`of the potential of existing software subclassing
`the SecurityManager and customizing these check
`methods.
`To use the privilege primitive, the following code
`sample should be followed:
`
`try 
`AccessController.beginPrivileged;
`some sensitive code
` finally 
`AccessController.endPrivileged;
`
`
`
`Some important points about being privileged.
`Firstly, this concept only exists within a single
`thread. That is, a protection domain being so priv-
`ileged is scoped by the thread within which the call
`to become privileged is made. Other threads are not
`aected.
`Secondly, in this example, the body of code within
`try-nally is privileged. However, it will lose its
`privilege if it calls from within the privileged block
`code that is less privileged.
`Moreover, although it is a good idea to use
`beginPrivileged and endPrivileged in pairs as
`this clearly scopes the privileged code, we have
`to deal with the case when endPrivileged is not
`called, because forgetting to disable a privilege can
`be very dangerous. To reduce or eliminate the risk,
`we have put in additional mechanism to safe guard
`this primitive.
`
`. Secure Class Loading
`
`The class java.security.SecureClassLoader is
`a concrete implementation of the abstract class
`
`java.lang.ClassLoader that loads classes and
`records the protection domains they belong to. It
`also provides methods to load a class from byte-
`code stored in a byte array, an URL, and an
`InputStream. This class can be extended to include
`new methods, but most existing methods are nal,
`as this class is signicant for security.
`All applets and applications except for system
`classes are loaded by a SecureClassLoader either
`directly or indirectly in which case, it is probably
`loaded by another classloader that itself is loaded
`by a SecureClassLoader.
`SecureClassLoader’s loadClass methods en-
`force the following search algorithm where, if the
`desired class by the given name is not found, the
`next step is taken.
`If the class is still not found
`after the last step, a ClassNotFoundException is
`thrown.
`
` . See if the class is already loaded and resolved
`
`. See if the class requested is a system class. if so,
`load the class with the null system classloader.
`
` . Attempt to nd the class in a customizable way,
`using a non-nal method findAppClass, which
`by default will try to nd the class in a second
`local search path that is dened by a property
`named java.app.class.path.
`
`Note that in step , all classes on the search
`path CLASSPATH are treated as system classes,
`whereas in step , all classes on the search path
`java.app.class.path are considered non-system
`classes.
`loaders
`Programmers who must write class
`should, whenever feasible, subclass from the con-
`crete SecureClassLoader class, and not directly
`from the abstract class java.lang.ClassLoader.
`A subclass of SecureClassLoader may choose to
`overwrite the findAppClass method in order to cus-
`tomize class searching and loading. For example,
`the AppletClassLoader caches all raw class mate-
`rials found inside a JAR le. Thus, it is reasonable
`for the AppletClassLoader, which is a subclass of
`the SecureClassLoader, to use findAppClass to
`look into its own cache. A class introduced in such
`a fashion is guaranteed not to be a system class,
`and is subjected to the same security policy as its
`loading class.
`
`The path java.app.class.path is currently specied in
`a platform dependent format. There might be a future need
`to develop a generic Path class that not only provides plat-
`form independent path names but also makes dynamical path
`manipulation easier.
`
`Blue Coat Systems - Exhibit 1016 Page 8
`
`

`
`Often a class may refer to an another class and
`thus cause the second class belonging to another
`domain to be loaded. Typically the second class is
`loaded by the same classloader that loaded the rst
`class, except when either class is a system class, in
`which case the system class is loaded with a null
`classloader.
`
`For a software library developer whose code con-
`trols certain resources, the developer may need to
`extend the existing permission class hierarchy to
`create application-specic permissions. The devel-
`oper may also need to learn to use features provided
`by the AccessController class, such as the privi-
`lege primitive.
`
`. Extending Security to Applications
`
` . Handling Non-Class Content
`
`To apply the same security policy to applications
`found on the local le system, we provide a new class
`java.security.Main, which can be used in the fol-
`lowing fashion in place of the traditional command
`java application to invoke a local application:
`java java.security.Main application
`This usage makes sure that any local applica-
`tion on the java.app.class.path is loaded with
`a SecureClassLoader and therefore is subjected to
`the security policy that is being enforced. Clearly,
`non-system classes that are stored on the local
`le system should all be on this path, not on the
`CLASSPATH.
`
` Discussion
`
`In this section, we discuss a number of open ques-
`tions and possible improvement to the current archi-
`tecture. But we start by discussing how a developer
`or user is impacted by the new architecture.
`
` . Utilizing the New Architecture
`
`For a user of the built-in appletviewer or a new
`version of a browser that deploys this new security
`architecture, the user can continue to do things the
`same way as before, which means that the same
`policy in JDK . .x will apply.
`On the other hand, a power user" can use the
`PolicyTool built-in for JDK . or an equivalent
`one shipped with the browser to customize the se-
`curity policy, thus utilizing the full benet of the
`new security architecture. Such customization may
`involve setting up a certicate store, which can be
`done via the KeyTool.
`in general,
`The typical application developer,
`needs to do nothing special because, when the appli-
`cation is run on top of JDK ., the security features
`are invoked automatically. Except that the devel-
`oper might want to use the built-in