Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

Building a bigger sandbox

Security in JDK 1.2 gives developers more control. Find out how to take advantage of this flexible new model

By Todd M. Greanier, JavaWorld.com, 08/01/98

T he sandbox. Discussions of Java's security model always seem to involve mention of the so-called sandbox security model. This article won't delve deeply into this topic; instead, we'll discuss how new additions to the Java API in the 1.2 release let us expand the original sandbox idea, create our own sandboxes, and even eliminate the sandbox entirely.

The security manager and the sandbox

Java has always had many different faces to its security model. It has a strongly typed compiler to eliminate programming bugs and help enforce language semantics, a bytecode verifier that makes sure the rules of Java are followed in compiled code, a classloader that's responsible for finding, loading, and defining classes and running the verifier on them, and the security manager -- the main interface between the system itself and Java code.

We'll be concentrating on the age-old security manager and the new addition to the JDK, the access controller. To refresh our memories, the security manager in Java is composed of a series of checkXXX methods that we can override, defining the logic we desire. In JDK 1.1, this logic either disallows the request (by throwing a java.lang.SecurityException) or allows the request (either via some ornate logic scheme or by simply returning).

Security managers exist to enforce the rules of the sandbox. The sandbox concept is fairly simple: When you run a piece of Java code, you may want the sandbox to provide an area for the code to do what it needs to do. But in many situations, you need to restrict the bounds of this area. Code that is trusted resides outside the sandbox; code that is untrusted is confined within it. Trusted code is the code in the Java API and code loaded from the classpath. Untrusted code is code loaded from outside the classpath, usually from the network. So Java applications, by default, live outside the sandbox and Java applets, by default, are confined within it.

The need for this "play area" is obvious when you think of an applet. Suppose a site called www.badpeople.com decided to create an applet that ostensibly showed slides of Sunday cartoons. You might enjoy that. But behind the scenes, while you were lazily chuckling at the sideshow, the applet would really be scouring your hard drive for private information. Without the sandbox, this scenario is all too possible. The sandbox represents the limits a program has put upon it. The sandbox is another term for a security policy.

As Java grows, the need for varying security policies increases. It is agreed by almost everyone that the original sandbox model of JDK 1.0.x, though safe, was too restrictive. With JDK 1.1 the addition of digital signatures allowed expansion of the original sandbox policy. If the user trusted the digitally signed code, users could allow normally untrusted code to access resources. (Though their discussion is beyond the scope of this article, digital signatures still play an important role in JDK 1.2.)

The sandbox, though, is just the security policy -- the equivalent of a law. And a policy or law must be enforced to be effective. The government can pass a law in your town tomorrow outlawing red shoes, but if nobody enforces it, it's not much of a law. The sandbox won't effectively confine code and its behavior without an enforcement mechanism. This is where the security manager comes into the picture. Security managers make sure all restricted code stays in the sandbox.

1 | 2 | 3 |  Next >
Resources
  • Read "Secure Computing With JavaNow and the Future" http://java.sun.com/marketing/collateral/security.html
  • Read "Low Level Security in Java," by Frank Yellin http://java.sun.com/sfaq/verifier.html
  • See the JDK 1.2 security documentation http://java.sun.com/products/jdk/1.2/docs/guide/security/index.html
  • Visit the Java Security home page http://java.sun.com/security