Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Understanding the keys to Java security -- the sandbox and authentication

A detailed look at the latest security features in Java -- and the recently discovered code-signing hole

By Gary Mcgraw and Edward Felten, JavaWorld.com, 05/01/97

You may have heard about the latest flaw in the security of JDK 1.1 and HotJava 1.0 that was recently discovered by the Secure Internet Programming team at Princeton University (led by one of the authors). If you want the whole story, read on. But there's more to Java security than the specifics about this latest security hole. Let's get some perspective.

Java security and public perception

Everybody knows that security is a big deal for Java. Whenever a security hole is discovered, the story blasts into the computer news (and sometimes the business news) very quickly. You may not be surprised to learn that the popular press monitors comp.risks and other security-related newsgroups. They pick security stories to highlight seemingly at random, though since Java is so hot these days they almost always print Java security stories.

The problem is that most news stories don't explain the holes well at all. This could lead to a classic "cry wolf" problem where people become habituated to seeing "this week's security story" and don't educate themselves about the very real risks of executable content. Moreover, vendors tend to downplay their security problems, thus further confusing the key issues.

The good news is that the JavaSoft security team is serious about making Java secure. The bad news is that a majority of Java developers and users may believe the hype emanating from events like JavaOne where security problems are not given much airplay. As we said in our book, Java Security: Hostile Applets, Holes, & Antidotes, Sun Microsystems has a lot to gain if it makes you believe Java is completely secure. It is true that the vendors have gone to great lengths to make their Java implementations as secure as possible, but developers don't want effort; they want results.

Since a Java-enabled Web browser allows Java code to be embedded in a Web page, downloaded across the net, and run on a local machine, security is a critical concern. Users can download Java applets with exceptional ease -- sometimes without even knowing it. This exposes Java users to a significant amount of risk.

Java's designers are well aware of the many risks associated with executable content. To combat these risks, they designed Java specifically with security concerns in mind. The main goal was to address the security issue head-on so that naive users (say, a majority of the millions of Web surfers) would not have to become security experts just to safely peruse the Web. This is an admirable goal.

The three parts of the Java sandbox

Java is a very powerful development language. Untrusted applets should not be allowed to access all of this power. The Java sandbox restricts applets from performing many activities. The best technical paper on applet restrictions is "Low Level Security in Java" by Frank Yellin.

Java security relies on three prongs of defense: the Byte Code Verifier, the Class Loader, and the Security Manager. Together, these three prongs perform load- and run-time checks to restrict file-system and network access, as well as access to browser internals. Each of these prongs depends in some way on the others. For the security model to function properly, each part must do its job properly.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.