The sandbox is pervasive

If you have a properly skeptical mind, you'll need to be convinced that a sandbox has no leaks before you trust it to protect you. To make sure the sandbox has no leaks, Java's security model involves every aspect of its architecture. If there were areas in Java's architecture in which security was weak, a malicious programmer (a "cracker") potentially could exploit those areas to "go around" the sandbox. To understand the sandbox, therefore, you must look at several different parts of Java's architecture and understand how they work together.

The fundamental components responsible for Java's sandbox are:

Safety features built into the Java virtual machine (and the language)
The class loader architecture
The class file verifier
The security manager and the Java API

The sandbox is customizable

One of the greatest strengths of Java's security model is that two of the four components shown in the above list, the class loader and the security manager, are customizable. To customize a sandbox, you write a class that descends from java.lang.SecurityManager. In this class, you override methods declared in the superclass that decide whether or not to allow particular actions, such as writing to the local disk. You will want to establish a custom SecurityManager when you are using custom class loaders to load class that you don't fully trust.

As a developer, you may never need to create your own customized sandbox -- you can often make use of sandboxes created by others. When you write and run a Java applet, for instance, you make use of a sandbox created by the developers of the Web browser that hosts your applet.

The remainder of this article will discuss the Java virtual machine's safety features. Subsequent articles in this series will describe the other three prongs of Java's security architecture: class loaders, class verification, and the security manager.

Safety features built into the JVM

Several built-in security mechanisms are operating as Java virtual machine bytecodes. You have likely heard these mechanisms listed as features of the Java programming language that make Java programs robust. They are, not surprisingly, also features of the Java virtual machine. The mechanisms are:

Type-safe reference casting
Structured memory access (no pointer arithmetic)
Automatic garbage collection (can't explicitly free allocated memory)
Array bounds checking
Checking references for null

Whenever you use an object reference, the JVM watches over you. If you attempt to cast a reference to a different type, the JVM makes sure the cast is valid. If you access an array, the JVM ensures the element you are requesting actually exists within the bounds of the array. If you ever try and use a null reference, the JVM throws an exception.

Safety features and security

Because of the safety features built into the Java virtual machine, running programs can access memory only in safe, structured ways. This helps make Java programs robust, but also makes their execution more secure. Why? There are two reasons.