Security Reference Model for
the Java Developer's Kit 1.0.2

Marlena Erdos, Bret Hartman, Marianne Mueller

13 November 1996

Table of Contents

  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


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 as well as the Java language and virtual machine specifications listed at the end of this report.

Security Reference Model

  1. Background
  2. 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

    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.

  3. Classes of Model Components
  4. JDK model components are described in the following diagram. The arrows between components indicate data flows during security transitions.

    Java applet

    Java-enabled application

    Java Virtual Machine (JVM)

    Client/Server Platforms


  5. Principals
  6. The different classes of principals (users) are listed below:

  7. Resources
  8. The different classes of resources are listed below:

  9. Global Security Invariant
  10. 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.

  11. Security Transition Overview
  12. 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: 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:

  13. Security Transition Detail
  14. 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:

    ClassLoader constructor

    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.

    Load Class

    JVM calls the application's loadClass 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.

    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.

    Verify/Link class

    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.

    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.


    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).



  15. Future Directions
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:

Security Functionality

Some potential enhancements to Java security functionality are listed below. See the Java web site 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.

Marlena Erdos
Bret Hartman
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

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

Last Modified: 12/06/96