Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Security and the class loader architecture

A look at the role played by class loaders in the JVM's overall security model

By Bill Venners, JavaWorld.com, 09/01/97

  • Print
  • Feedback
.

Page 4 of 6

Since the primordial class loader was able to find the class, your class loader doesn't attempt to download it across the network; it merely passes to the virtual machine the String class returned by the primordial class loader. From that point forward, the virtual machine uses that String class whenever class Volcano references a class named String.

Class loaders in the sandbox

In Java's sandbox, the class loader architecture is the first line of defense against malicious code. It is the class loader, after all, that brings code into the JVM -- code that could be hostile.

The class loader architecture contributes to Java's sandbox in two ways:

  1. It prevents malicious code from interfering with benevolent code.
  2. It guards the borders of the trusted class libraries.


The class loader architecture guards the borders of the trusted class libraries by making sure untrusted classes can't pretend to be trusted. If a malicious class could successfully trick the JVM into believing it was a trusted class from the Java API, that malicious class potentially could break through the sandbox barrier. By preventing untrusted classes from impersonating trusted classes, the class loader architecture blocks one potential approach to compromising the security of the Java runtime.

Name-spaces and shields

The class loader architecture prevents malicious code from interfering with benevolent code by providing protected name-spaces for classes loaded by different class loaders. As mentioned above, name-space is a set of unique names for loaded classes that is maintained by the JVM.

Name-spaces contribute to security because you can, in effect, place a shield between classes loaded into different name-spaces. Inside the JVM, classes in the same name-space can interact with one another directly. Classes in different name-spaces, however, can't even detect each other's presence unless you explicitly provide a mechanism that allows the classes to interact. If a malicious class, once loaded, had guaranteed access to every other class currently loaded by the virtual machine, that class potentially could learn things it shouldn't know, or it could interfere with the proper execution of your program.

Creating a secure environment

When you write an application that uses class loaders, you create an environment in which the dynamically loaded code runs. If you want the environment to be free of security holes, you must follow certain rules when you write your application and class loaders. In general, you will want to write your application so that malicious code will be shielded from benevolent code. Also, you will want to write class loaders such that they protect the borders of trusted class libraries, such as those of the Java API.

Name-spaces and code sources

To get the security benefits offered by name-spaces, you need to make sure you load classes from different sources through different class loaders. This is the scheme, described above, used by Java-enabled Web browsers. The Java application fired off by a Web browser usually creates a different applet class loader object for each source of classes it downloads across the network. For example, a browser would use one class loader object to download classes from http://www.niceapplets.com, and another class loader object to download classes from http://www.meanapplets.com.

  • Print
  • Feedback

Resources
  • Previous "Under The Hood" articles:
  • The Lean, Mean Virtual Machine -- Gives an introduction to the Java virtual machine.
  • The Java Class File Lifestyle -- Gives an overview of the Java class file, the file format into which all Java programs are compiled.
  • Java's Garbage- Collected Heap -- Gives an overview of garbage collection in general and the garbage-collected heap of the Java virtual machine in particular.
  • Bytecode Basics -- Introduces the bytecodes of the Java virtual machine, and discusses primitive types, conversion operations, and stack operations in particular.
  • Floating Point Arithmetic -- Describes the Java virtual machine's floating-point support and the bytecodes that perform floating point operations.
  • Logic and Arithmetic -- Describes the Java virtual machine's support for logical and integer arithmetic, and the related bytecodes.
  • Objects and Arrays -- Describes how the Java virtual machine deals with objects and arrays, and discusses the relevant bytecodes.
  • Exceptions -- Describes how the Java virtual machine deals with exceptions, and discusses the relevant bytecodes.
  • Try-Finally -- Describes how the Java virtual machine implements try-finally clauses, and discusses the relevant bytecodes.
  • Control Flow -- Describes how the Java virtual machine implements control flow and discusses the relevant bytecodes.
  • The Architecture of Aglets -- Describes the inner workings of aglets, IBM's autonomous Java-based software agent technology.
  • The Point of Aglets -- Analyzes the real-world utility of mobile agents such as aglets, IBM's autonomous Java- based software agent technology.
  • Method Invocation and Return -- Describes the four ways the Java virtual machine invokes methods, including the relevant bytecodes.
  • Thread Synchronization -- Shows how thread synchronization works in the Java virtual machine. Discusses the bytecodes for entering and exiting monitors.
  • Java's Security Architecture -- Gives an overview of the security model built into the JVM and looks at the JVM's built-in safety features.