Security Reference Model for
the Java Developer's Kit 1.0.2
Marlena Erdos, Bret Hartman, Marianne Mueller
email@example.com firstname.lastname@example.org email@example.com
13 November 1996
Table of Contents
- Classes of Model Components
- Global Security Invariant
- Security Transition Overview
- Security Transition Detail
- Secure Initial State
- ClassLoader constructor
- Load Class
- Verify/Link class
- Class Initialization
- Applet Access Device Attempt
- Applet Manipulate Thread Attempt
- Applet Manipulate Thread Group
- Applet Manipulate Process Attempt
- Applet Modify NameSpace Attempt
- Applicatoin Access Device Attempt
- Application Manipulate Process Attempt
- Server Platform to Client Platform Data Stream
- Client Platform to Server Platform Data Stream
- Server Platform to Server
- Future Directions
This report provides the security reference model for the Java
Developer's Kit (JDK) version 1.0.2. The model defines the fundamental
security requirements for the Java environment, serves as a basis for
a security test plan, and is a first step toward further assurance
documentation and analysis.
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.
Security Reference Model
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
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 Virtual Machine (JVM)
The different classes of principals (users) are listed below:
The different classes of resources are listed below:
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:
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
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:
- 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.
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:
Application calls its ClassLoader's constructor.
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.)
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.
``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.
JVM calls the application's loadClass method.
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.
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.
loadClass must not create mappings for classes that have not passed linking/verifying.
Application (i.e. the class Loader object) calls the JVM's Verifier/Linkage code.
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.
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.
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.
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.
Applet Access Device Attempt
Applet calls the application to access a device. ``Device access'' covers access to files, communications resources, etc.
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.
Applet Manipulate Thread Attempt
Applet calls the application to attempt to manipulate a thread.
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.
Applet Manipulate Thread Group
Applet calls the application to attempt to manipulate a thread group.
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.
Applet Manipulate Process Attempt
Applet calls the application to attempt to exec a new process or cause the JVM to halt.
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.
Applet Modify NameSpace Attempt
Applet may 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.
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.
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
Server Platform calls the Server to access server data (e.g., html files).
In this section we discuss a number of potential future directions for Java security. We first discuss approaches for providing improved security assurance. We then give a brief overview of potential enhancements to Java security functionality.
Users, security administrators, and enterprise management will need to assess whether their data will be adequately protected by a particular JDK configuration. Individuals must be convinced that the JDK configuration is sufficiently trustworthy to meet the security needs of the user's or enterprise's environment. JDK trustworthiness is thus the ability of a configuration of Java-enabled application, JVM, and platform to protect resources from exposure and misuse through malicious or inadvertent means.
To provide a demonstration of trustworthiness for a given JDK configuration, the following properties would need to be shown:
Assurance is the confidence that a system is trustworthy. For the JDK, assurance is based on a body of evidence that demonstrates the trustworthiness properties listed above. The qualitative nature of assurance means that users and enterprises may have different assurance requirements. Some may require an extensive evaluation, while others need very little evidence of trustworthiness. The key issue is to balance the level of assurance needed by using assurance evidence that is appropriate to the level of risk involved.
Depending on the level of assurance required, there are a number of different approaches for providing JDK assurance evidence. These approaches include:
Some potential enhancements to Java security functionality are listed
below. See the Java web site http://java.sun.com/security
for further details.
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.
Common Criteria for Information Technology Security Evaluation, Version 1.0, Part 2: Annex B, Guidance for selecting functional security requirements, January 1996.
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.
BlackWatch Technology, Inc.
2-212 Center for Science & Technology
CASE Center, Syracuse University
Syracuse, NY 13244-4100
voice: (315) 443-3171
fax: (315) 443-4745
Sun Microsystems, Inc.
2550 Garcia Avenue
Mountain View, California 94043-1100
voice: (408) 343-1451
fax: (408) 343-1553
Last Modified: 12/06/96