Sponsored Link •
The sandbox defined
Traditionally, you had to trust software before you ran it. You achieved security by being careful only to use software from trusted sources, and by regularly scanning for viruses just to make sure things were safe. Once some software got access to your system, it had full rein. If it was malicious, it could do a great deal of damage to your system because there were no restrictions placed on the software by the runtime environment of your computer. So, in the traditional security scheme, you tried to prevent malicious code from ever gaining access to your computer in the first place.
The sandbox security model makes it easier to work with software that comes from sources you don't fully trust. Instead of security being established by requiring you to prevent any code you don't trust from ever making its way onto your computer, the sandbox model lets you welcome code from any source. But as it's running, the sandbox restricts code from untrusted sources from taking any actions that could possibly harm your system. The advantage is you don't need to figure out what code you can and can't trust, and you don't need to scan for viruses. The sandbox itself prevents any viruses or other malicious code you may invite into your computer from doing any damage.
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:
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
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.