1. Background
2. Classes of Model Components
3. Principals
4. Resources
5. Global Security Invariant
6. Security Transition Overview
7. Security Transition Detail
   1. Secure Initial State
   2. ClassLoader constructor
   3. Load Class
   4. Verify/Link class
   5. Class Initialization
   6. Applet Access Device Attempt
   7. Applet Manipulate Thread Attempt
   8. Applet Manipulate Thread Group
   9. Applet Manipulate Process Attempt
   10. Applet Modify NameSpace Attempt
   11. Applicatoin Access Device Attempt
   12. Application Manipulate Process Attempt
   13. Server Platform to Client Platform Data Stream
   14. Client Platform to Server Platform Data Stream
   15. Server Platform to Server
8. Future Directions

The reference model is based on the security requirements described in http://java.sun.com/security/ as well as the Java language and virtual machine specifications listed at the end of this report.

Background

The model first defines the classes of model components; that is, a Java applet, Java-enabled application, Java Virtual Machine (JVM), client platform, server platform, and server. Each of these components is trusted in varying degrees to preserve overall system security. The model describes the global security invariant that defines the overall system security property. The model then describes the security transitions that occur during system operation in terms of the security invariants and the resources that are used. We conclude with a discussion of future directions for Java security.

The model is intentionally very abstract, only describing behavior that is visible at the external interface of each system component. That is, the model describes what the JDK security properties are, not how the JDK implements security. The intent is not to provide an in-depth view of the system security mechanisms, but instead to give a view from the user's perspective of the security services to be provided by the architecture. To keep the model simple, we concentrate solely on security-relevant transactions and omit descriptions of functional behavior. The resulting model can provide guidance to

• developers of Java-enabled applications, aiding in correct design and implementation of their applications
• system administrators and sophisticated end-users, helping them correctly configure the Java-enabled applications they deploy in the networks
• security auditors, serving as a foundation for assurance analysis of each system component
• licencees, aiding in correct design and implementation of their JDK

Because the reference model security requirements are abstract, the model should be applicable to any valid JDK implementation, regardless of the security of the underlying operating system, hardware, or network configuration. For example, we make no assumptions about whether different components run in different address spaces. Security trade-offs of the underlying mechanisms would appear during a security assurance analysis, which is the assessment of whether a particular implementation meets the security requirements of the reference model. JDK security depends on the security of the underlying platform. Platforms with stronger security enforcement mechanisms are likely to give better support for meeting the JDK reference model requirements.

The model also is flexible with respect to the Java application security policy. The reference model in fact is a meta-policy because it states constraints on the set of allowed policies that may be implemented within the Java application. The JDK allows a Java application to extend the Java application programming interface (API) by subclassing. In particular, a Java application (such as a browser or other web client) customizes its security policy by subclassing the SecurityManager class, which confines the behavior of applets.

The model is thus equally relevant for the security policies defined by different applications. Note that Netscape Navigator and Hot Java already implement different security policies with respect to the access (e.g. file system and network) allowed to applets. We expect that future Java-enabled applications will have increasingly rich security policy options (along with sophisticated security mechanisms such as digital signature verification). The meta-policy stated in this model should still be applicable as the security functionality available in Java-enabled applications evolves.

In addition to JVM enforcement of Java language safety features, the model underscores the requirement for trustworthy Java-enabled applications, such as Navigator and Hot Java. Demonstration and documentation of security assurance for Java-enabled client applications has received little attention to date, and there is much room for improvement in this area. Section 8.1 describes this issue further.

Classes of Model Components

JDK model components are described in the following diagram. The arrows between components indicate data flows during security transitions.


Java applet

• The executable Java program that is downloaded from the server.
• Applet loading and security is under the control of the application

Java-enabled application

• A trusted, statically configured web-client program.
• The application includes Java-supplied class code plus application-defined extensions to non-final methods.
• The application is not necessarily a Java program.

Java Virtual Machine (JVM)

• The runtime environment for Java applications and applets.

Client/Server Platforms

• The combination of middleware, operating system, hardware, and network that is supporting the executing JVM, Java application, and server.

Server

• The source of web data, including applets.
• The server is not necessarily a Java program.

Principals

The different classes of principals (users) are listed below:
• Client Administrator - configures the Java-enabled application.
• End-user - invokes and uses Java-enabled application; may make some choices about applet access.
• Server administrator - controls Java applets.
• Application provider - creates and implements security policy model and mechanisms.

Resources

The different classes of resources are listed below:
• Client device - A device residing on the client platform; may include files, terminals, and networks.
• Server device - A device residing on the server platform; may include files, terminals, and networks.
• Object - An object defined within the Java environment.
• Data - Arbitrary binary data transmitted between client and server.

Global Security Invariant

The security reference model is a layered definition of security. The global security invariant defines at the highest-level the abstract security property preserved by the system. The JDK global security invariant is:
• Downloaded applets are constrained by the application policy as configured by the client system administrator or end user.
The abstract definition of JDK security is in turn supported by lower-level (more concrete) security properties enforced by other system components, such as the JVM and client platform. These lower-level security properties are defined in the next section as the security invariants for each transition.

To demonstrate security assurance for the JDK, an analysis must show that the lower level properties compose together to imply the global security invariant. In addition, the analysis must show that the implementation of each component meets its individual transition security invariants.

Security Transition Overview

This section provides a brief overview of the security interactions between the components listed in section 2. We describe the first six interactions in terms of an example control flow during download and execution of an applet that is attempting to access the local file system:
• Secure Initial State - Before applets are loaded, the user or administrator must ensure that the application, JVM, and platform are configured properly to enforce the desired security policy.
• ClassLoader constructor - The application calls its ClassLoader's constructor to create an instance of the class loader object. The class loader defines the application's policy describing where and how to download applets, and will be used to load any classes while the application is running.
• Load Class - During execution of the application, the JVM calls the application's loadClass method to download an applet from a server, to find a system class, or to locate a previously downloaded class.
• Verify/Link class - During loadClass, the application in turn calls the JVM to verify and link the code. It is at this point that the JVM checks to ensure that the applet obeys the type system rules.
• Class Initialization - Before a method in the downloaded code is invoked for the first time, the JVM ensures that the class is properly initialized.
• Applet Access Device Attempt - While an applet method is executing, it may attempt to call a method within the application, such as an access on the local file system. The application ensures that requested access is mediated by the application's Security Manager policy. Previous steps in the setup have ensured that the applet cannot bypass the Security Manager policy by violating Java type safety properties, or by tampering with application code.

The security invariants summarized above are described in more detail in the next section. In addition to the above transitions, the next section also describes the following transitions:
• Applet Manipulate Thread Attempt - Applet calls the application to attempt to manipulate a thread.
• Applet Manipulate Thread Group - Applet calls the application to attempt to manipulate a thread group.
• Applet Manipulate Process Attempt - Applet calls the application to attempt to exec a new process or cause the JVM to halt.
• Applet Modify NameSpace Attempt - Applet calls the application to attempt to dynamically link in libraries or define methods in packages.
• Application Access Device Attempt - Application calls the Client Platform to attempt to access a device. ``Device Access'' includes access to files, communications ports, displays etc.
• Application Manipulate Process Attempt - Application calls the Client Platform to attempt to manipulate a process.
• Server Platform to Client Platform Data Stream - Server Platform calls the Client Platform to transmit a data stream.
• Client Platform to Server Platform Data Stream - Client Platform calls the Server Platform to transmit a data stream.
• Server Platform to Server - The Server Platform calls the Server to access server data (e.g. html files).

Security Transition Detail

This section describes all potential security interactions between the components listed in section 2. Subsections describe security transitions caused by pairwise interactions of the components. For each security transition we describe the security invariants that define how and why each component is trusted as well as any environmental assumptions required for security. Note that this section should describe all possible security transitions of the JDK implementation. Security-relevant events in the actual implementation that are not described here may invalidate this model.

Secure Initial State

Before applets are loaded, the user or administrator must ensure that:
• code installed in the application's CLASSPATH does not violate the security policies that are defined by the Security Manager and the JVM. In particular, care must be taken with 'native code' since verification on such code is not possible, and native code could potentially allow applets to bypass the usual Java and Security Manager's control on device access.
• other processes running on the user's machine prior to start-up of the Java-enabled application, will not interfere with it.
• device (e.g. file, port) access controls are configured so as to grant only appropriate access to the Java-enabled application.
• the Java-enabled application will run with an appropriate system identity (e.g. that of the user, and not 'root').
• the Java-enabled application comes from a reputable source (to avoid viruses and malicious code).
• the security policy mechanisms exported by the Java-enabled application (e.g. a switch to allow downloading of applets) are correctly configured/set.

ClassLoader constructor

Application calls its ClassLoader's constructor.

Invariants

• During construction, the Security Manager object is called to see if this thread can create a class loader.
A class loader object is responsible for mapping class names to class code -- loading a class and calling the verifier when necessary. These actions of mapping, loading, and verifying are critical to the enforcement of Java language semantics and the application's security policy. Hence, a classLoader object should generally be under the control of the application and not untrusted code (e.g. most applets). In any case, it is imperative that the security manager be invoked at the attempt to create a new class loader object to see if the creation is permitted under the application's security policy.

(Currently, the JDK's classLoader class provides a constructor that does in fact call the Security Manager.)

• Constructor doesn't catch and ignore (or otherwise improperly handle) a Security Exception.

The JDK's ClassLoader class is an abstract class: only subclasses can be instantiated as objects. While the JDK provides implementations of most of ClassLoader's methods including the constructor, the subclass implementor is free to provide a constructor for the subclass. This subclass constructor must not improperly handle a Security Exception caused by a call to the Security Manager either by itself or by a superclass constructor.

Load Class

JVM calls the application's loadClass method.

Invariants

• System classes are found by using the Java-supplied classLoader::findSystemClass method (and not by a home-grown method).

``System Classes'' are those classes found in the local file system (constrained by CLASSPATH and other environmental controls). The loadClass method must acquire these classes in the manner defined by the JDK. Failure to do so risks mapping of system class names to code that doesn't properly implement the System Classes' specified behavior.
• Calls the Java-supplied Verifier/Linker (accessed through classLoader::defineClass and classloader::resolveClass) to validate non-system classes.

The JDK's Verifier/Linker ensures that the class code is syntactically and structurally correct, and that object accesses specified in the class code conform to the type discipline of Java and the target class's definition.

• Maps names to class code correctly.
It is the class loader's responsibility to maintain the mapping of the class's name to the class object that represents the class. (This class object is initially acquired by the class loader object by either a call to findSystemClass or defineClass (in the case of loading a binary representation of a class). Failure to perform the mapping correctly risks execution of code that violates the type definitions of the class and/or that code doesn't implement the class's specified behavior.

• Doesn't catch and ignore (or otherwise improperly handle) exceptions thrown during linking/verifying.

loadClass must not create mappings for classes that have not passed linking/verifying.

Verify/Link class

Application (i.e. the class Loader object) calls the JVM's Verifier/Linkage code.

Invariants

• Verifier/Linker ensures that the binary representation of a class is correct, and throws an exception if it is not.
• Verifier/Linker ensures that the class being defined obeys the type system rules regarding access to data and methods in referenced classes.
• Verifier/Linker initializes class statics to Java-defined default values.

Note: The Verifier/Linker's initialization of class statics (so-called ``preparation'') is a different matter than the initialization specified as part of a class's definition. Class-defined initializations occur when the class if first actively used. Such active use can never precede preparation.

Class Initialization

Application calls the JVM to initialize a class.

Class initialization consists of executing the initialization code for the static fields declared in the class, and the initializers for the class overall.

Invariants

• JVM performs initialization of the first active use of the class.

A reference to a class is considered an ``active use'' if a method declared in the class (rather than a superclass) is invoked, the constructor for the class is invoked, or a non-constant field declared in the class (as opposed to a superclass or superinterface) is used or assigned.

• JVM initializes superclasses (recursively).

• JVM correctly locks and unlocks the class object, and correctly manipulates the information about initialization contained therein.
Multiple threads could seek to initialized a class 'at the same time'. Since there is only one object that represents the class, it must be protected against concurrent access.
• JVM ensures that initialization completes fully.

Assumptions

• Class is already verified and prepared. (Preparations consists of creating the static fields defined in the class/interface and initializing these fields to standard default values.)

Applet Access Device Attempt

Applet calls the application to access a device. ``Device access'' covers access to files, communications resources, etc.

Invariants

• Application always calls the Security Manager Object to see if the requested access is permitted. (For example, the implementation of File::canRead() must call SecurityManager::checkRead.)

Note that the JDK provides default implementation for many device access methods. These currently call the Security Manager, however the application is free to subclass these device classes, and override the default implementations.

• Application doesn't catch and ignore or otherwise improperly handle Security Manager exceptions and return values.

Assumptions

• Applet cannot access devices by any means other than by calling the application.
• Security Manager code implements the application's policy as configured by the system administrator.

Applet Manipulate Thread Attempt

Applet calls the application to attempt to manipulate a thread.

Invariants

• Application always calls the Security Manager Object to see if the requested access is permitted. (For example, Thread::suspend() must call SecurityManager::checkAccess() .)

Note that many 'sensitive' methods (e.g. 'suspend') in class Thread are declared 'final': They are provided by the JDK and are not overridable by the application.

Assumptions

• Applet cannot access threads by any means other than by calling the Thread API.
• Security Manager code implements the application's policy as configured by the system administrator.

Applet Manipulate Thread Group

Applet calls the application to attempt to manipulate a thread group.

Invariants

• Application always calls the Security Manager Object to see if the requested access is permitted. (For example, ThreadGroup::resume() must call SecurityManager::checkAccess() .)

Note that many 'sensitive' methods (e.g. 'resume') in class ThreadGroup are declared 'final': They are provided by the JDK and are not overridable by the application.

Assumptions

• Applet cannot access threadgroups by any means other than by calling the ThreadGroup API.
• Security Manager code implements the application's policy as configured by the system administrator.

Applet Manipulate Process Attempt

Applet calls the application to attempt to exec a new process or cause the JVM to halt.

Invariants

• Application always calls the Security Manager Object to see if the requested access is permitted. (For example, Runtime::exec() must call SecurityManager::checkExec() .)

Note: Only one Runtime object is permitted in an application, and applications may not instantiate it. In other words, a Runtime object is provided by the Java runtime environment. Class Runtime methods currently call the Security Manager.

Assumptions

• Applet cannot manipulate processes by any means other than by calling the application.
• Security Manager code implements the application's policy as configured by the system administrator.

Applet Modify NameSpace Attempt

Applet may calls the application to attempt to dynamically link in libraries or define methods in packages.

Invariants

• The application always calls the Security Manager Object to see if the requested access is permitted. (For example, Runtime::loadLibrary() must call SecurityManager::checkLink .)

Assumptions

• Applet cannot modify the namespace by any means other than by calling the application.
• Security Manager code implements the application's policy as configured by the system administrator.

Application Access Device Attempt

Application calls the Client Platform to attempt to access a device. ``Device Access'' includes access to files, communications ports, displays etc.

Invariants

• Client Platform checks that the Application has permission for the requested access.

These checks are dependent on the security support provided on the Client Platform, and could consist of reading file ACLs or permissions, determining membership on an authorized user list, etc.

Assumptions

• Client Platform code implements the security policy of the system as configured by the platform's system administrator.
• Application cannot bypass or modify Client Platform security policy.

Application Manipulate Process Attempt

Application calls the Client Platform to attempt to manipulate a process.

Invariants

• Client Platform checks that the Application has permission for the requested access.

Assumptions

• Client Platform code implements the security policy of the system as configured by the platform's system administrator.
• Application cannot bypass or modify Client Platform security policy.

Server Platform to Client Platform Data Stream

Server Platform calls the Client Platform to transmit a data stream.

Invariants

• Data arrives at correct destination.
• Data integrity preserved.

Client Platform to Server Platform Data Stream

Client Platform calls the Server Platform to transmit a data stream.

Invariants

• Data arrives at correct destination.
• Data integrity preserved.

Server Platform to Server

Server Platform calls the Server to access server data (e.g., html files).

Invariants

None.

Future Directions

Assurance

To provide a demonstration of trustworthiness for a given JDK configuration, the following properties would need to be shown:

• Global security invariant is met - The combination of the security transition invariants and assumptions are sufficient to demonstrate the global security invariant.
• Security transitions correctly implement invariants - The JDK implementation correctly implements the secure initial state and the invariants specified in the security transitions. Note that this demonstration of correctness imposes requirements on the Java-enabled application, JVM, and platform.
• Security transition assumptions satisfied - The JDK environment preserves the assumptions specified in the security transitions.

Depending on the level of assurance required, there are a number of different approaches for providing JDK assurance evidence. These approaches include:

• Informal analysis - Informal analysis of implementation correctness. For example, the JDK APIs should be carefully examined to ensure that all security-related methods that should not be modified are declared as 'final', so that applications and applets are forced to use JDK code where appropriate.
• Testing - Compliance testing of the JVM and system classes based on the invariants defined in this model. JDK security tests would provide baseline evidence of security across all JDK implementations.
• Formal implementation proof - Mathematical analysis that portions of the JDK correctly implement a formal definition of the security invariants. This approach is particularly worthwhile in highly critical portions of the JDK that are unlikely to change often, such as the JVM language safety properties.
• Underlying platform security - Support of JDK security using high assurance operating systems and/or hardware. For example, the Java chip set could be used to enforce some language safety properties in hardware.
• Application guidelines - Assurance of Java-enabled applications is more problematic because they are likely to be highly complex and frequently updated. A suitable first step would be set of guidelines to help developers write high-quality secure applications.
• Application integrity - Demonstration that the application has the proper pedigree. Java could supply integrity mechanisms that would allow a user/administrator to verify that the system classes about to be used are in fact the same system classes distributed by the vendor.
• Applet authentication and integrity - Demonstration that the applet comes from a friendly source. Support for ``signed applets'' will remove the threat of malicious applets in many environments, thus reducing the need for further assurance evidence. In some environments, signed applets from appropriate sources would be considered trustworthy and allowed to run with fewer security restrictions.

Flexible policies - The Security Manager could enforce different policies on different applets, based on applet authentication and the level of trust for a particular applet.

Cryptographic APIs - These APIs would allow applications to sign and/or encrypt data before transmission over a network, thus supporting integrity and confidentiality.

Auditing - Audit APIs and JDK auditing support would provide a basis for accountability.

Firewalls - Because firewalls frequently filter out applet downloads due to the perceived threat, firewalls and applets usually don't mix. If sophisticated firewalls authenticated the source of applets, this constraint could be relaxed, thus allowing selected applets to pass through the firewall according to policy.

Optimizations - Just-in-time (JIT) compilers are being widely deployed as a means to improve applet performance. JIT inlining of methods or fields shouldn't violate any of the above assumptions or invariants.

References

The Java Language Specification, James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, Reading, Massachusetts, 1996.

The Java Virtual Machine Specification, Tim Lindholm and Frank Yellin, Addison-Wesley, Reading, Massachusetts, 1996.

Marianne Mueller
JavaSoft
Sun Microsystems, Inc.
Mailstop CUP01-202
2550 Garcia Avenue
Mountain View, California 94043-1100
voice: (408) 343-1451
fax: (408) 343-1553
mrm@eng.sun.com

Last Modified: 12/06/96