Java's security architecture

An overview of the JVM's security model and a look at its built-in safety features

This month's "Under The Hood" column is the first of a four-part series about Java's security model. The four articles will focus on the security infrastructure built into the Java virtual machine (JVM) and the java.lang library. This first article gives an overview of the security model and describes the JVM's safety features.

Why security?

Java's security model is one of the language's key architectural features that makes it an appropriate technology for networked environments. Security is important because networks provide a potential avenue of attack to any computer hooked to them. This concern becomes especially strong in an environment in which software is downloaded across the network and executed locally, as is done with Java applets, for example. Because the class files for an applet are automatically downloaded when a user goes to the containing Web page in a browser, it is likely that a user will encounter applets from untrusted sources. Without any security, this would be a convenient way to spread viruses. Thus, Java's security mechanisms help make Java suitable for networks because they establish a needed trust in the safety of network-mobile code.

Java's security model is focused on protecting users from hostile programs downloaded from untrusted sources across a network. To accomplish this goal, Java provides a customizable "sandbox" in which Java programs run. A Java program must play only inside its sandbox. It can do anything within the boundaries of its sandbox, but it can't take any action outside those boundaries. The sandbox for untrusted Java applets, for example, prohibits many activities, including:

  • Reading or writing to the local disk
  • Making a network connection to any host, except the host from which the applet came
  • Creating a new process
  • Loading a new dynamic library and directly calling a native method

By making it impossible for downloaded code to perform certain actions, Java's security model protects the user from the threat of hostile code.

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:

  • 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
1 2 Page 1
Page 1 of 2