The Java "sandbox" is great for providing security, but it's lousy if you want to do something useful with downloaded applets. That's because the sandbox imposes tight restrictions on downloaded code. Sandboxed applets can't touch your computer's file system, they can only initiate network connections to the computer from which they were downloaded. And they can't directly access your computer's screen or other hardware. Unfortunately, if you want to write a cool application in Java, that severely limits your options.
Microsoft thinks it has the answer with ActiveX. Instead of using a sandbox, ActiveX simply requires that downloaded programs be digitally signed. But they can still run rampant on the client side. Microsoft says if anybody's applet wipes out your hard drive or steals confidential documents, you should just sue the author (if you can find the guilty party).
Until now, deciding between the safety of the Java sandbox and the power of ActiveX has been a Hobson's choice. But last summer, Dan Wallach, Edward Felten, and Jim Roskind found a better way: a system for granting conditional privileges to programs written in Java. With the new system, a game written in Java can access a high-score file on your hard drive and write directly to the screen, but can't spy on your bank statement or plant a virus in your disk drive's boot blocks. The new approach leverages the capabilities inherent in the Java language while drawing on more than 20 years' research in computer security architectures. And best of all, it's going to be built into Netscape Navigator 4.0.
Wallach, for those of you who have lost your playbills, is a bright young graduate student at Princeton University who spent much of last spring finding security holes in the original Java implementation shipped by Sun and Netscape. Felten is his professor. Together with Drew Dean, they formed the Princeton Security Internet Programming group. One of the group's primary accomplishments was getting Wallach a summer job at Netscape, where he worked with Roskind on this new approach.
The basic problem with Java's security model, Wallach says, is that all applets that run on your browser get the same privileges, no matter where they come from. Although that model worked fine for getting the first product out the door, it doesn't make sense in the real world. If some Web site is giving you an applet that just does a fancy animation, it makes sense to prevent that applet from taking over your screen. But if you're running that new copy of Hellacious Mayhem, you want it to be able to write directly to the screen and manage a high-scores file on your hard disk - but you don't want it to be able to edit your system configuration files. What to do?
Instead of granting all-or-nothing access, Wallach's solution requires each Java application to ask for the specific privileges it needs when it starts up. A rewritten Java Security Manager then examines each of these requests and decides whether to grant or deny them based on the user's security policy and the policy of the organization where he or she works. The security manager can also ask the user whether specific privileges should be granted to the applet.
So when you first click on that Hellacious Mayhem applet, you might get a window that says the Hellacious Mayhem applet wants direct I/O access to the screen and sound system, and the ability to read and write to the file C:WINDOWSHELLACIOUS.SCORE. Clearly, those would be reasonable requests. Similarly, that new Corel word processor that's written in Java might want to be able to read and write document files to your hard disk. Clearly, that's also acceptable. But if the word processor asks for physical I/O access or the ability to initiate network connections, then you know something fishy's going on.
Wallach and Felten believe that users are generally good at making security-related decisions when given enough context phrased in plain language, but bad at making decisions when things get too technical. How would the average user respond to a request for "physical I/O access to port 350h" from Hellacious Mayhem? To help users who might not know enough to make such decisions, Wallach's team has come up with a bunch of macros that group these privileges together in a series of meaningful sets. Users will be asked if Hellacious Mayhem should be granted "typical game privileges." Corel's word processor might ask for "standard word-processor privileges."
If you decide to grant an application program these privileges, they are stored on the program's stack as a series of invisible capabilities. The Java system library will trace up the stack looking for these capabilities before performing any security-critical actions. A combination of the Java class loader, the byte-code verifier, and the language design itself assures that an applet can't just directly poke into memory and disable the security checks.
Wallach's team has also come up with a neat way to use digital signatures that allows these fine-grained security decisions to be made automatically.
The real meat of the Wallach proposal is the use of digital signatures to automatically convey privileges for particular libraries written in Java. The idea is really quite simple. It's unlikely that the makers of Hellacious Mayhem are actually going to be writing their own functions to directly poke into the user's screen. Instead, they're likely to call a series of routines in a library written by Netscape or Microsoft. Hellacious Mayhem will automatically download a copy of this library when it loads. This is a direct analogy to the way developers of Windows-based games include DLLs from Microsoft.
With Wallach's system, any software publisher will be able to digitally sign these downloaded libraries. If you or your company configure your browser to automatically trust, for example, the Netscape signature, then the library will be able to give a downloaded application selective access to part of your computer - for example, Netscape might have a 3-D game library that writes directly to the screen. Any program that uses this library to accomplish its special access won't need to have special privileges, because the library will have those privileges by virtue of being signed. But those privileges will only extend to the signed library itself - if Hellacious Mayhem wants to write directly to your screen, rather than going through the library, it's still going to need special permission.
Navigator 4.0 will have an easy-to-use GUI that shows a list of software publishers and which particular privileges you chose to grant them. This is similar to Internet Explorer's concept of approved ActiveX publishers. The big difference is that Explorer approves these publishers to do anything they want to your computer, whereas Navigator will only approve each publisher for the particular privileges each user sets forth.
Navigator 4.0 will also integrate smoothly with Netscape's caching proxy server, so that an organization can put its Java policy on the proxy and have it automatically downloaded to the clients each time they run. What's sure to be really cool is Netscape's new administrator's toolkit, which will let site admins write their own policies in JavaScript and have them automatically run on their users' machines.
Microsoft's ActiveX and Authenticode technologies can't ever provide the sort of control that's going to be in Netscape Navigator 4.0, because once an ActiveX control is running, it has free run of your Windows 95-based computer.
That means organizations on the Internet that care about their internal security will soon have a compelling reason to forsake Microsoft's "free" Internet Explorer for Netscape Navigator. And hopefully, it will be another reason to avoid the deadly dangers of ActiveX.
