Java's security model is, from a programming perspective, a lot more flexible than many people realize. Why is that important, and what does it mean for Java developers? O'Reilly Web site editor Allen Noren asked Java Security author Scott Oaks to explain.

Scott is a lead tactical engineer at Sun Microsystems, where he has worked since 1987. While at Sun, he has specialized in many disparate technologies, from the SunOS kernel to network programming and RPCs to the X Window System to threading. Since early 1995, he has been primarily focused on Java and bringing Java technology to end users; he writes a monthly column on Java solutions for The Java Report. Around the Internet, Scott is best known as the author of olvwm, the OPEN LOOK window manager.

Noren:

When did you become interested in Java? What was the spark that made you recognize it as something different?

Oaks:

I started becoming interested in Java early in 1995. I'm not sure if there was a single spark that piqued my interest or not--it was more along the lines of the more I learned about it and used it, the more I realized that its potential was so enormous. I think that's because Java is more than just the sum of its parts. I had written programs with cross-platform tools before, but none solved that problem as well as Java. I had written threaded applications before, but not as cleanly as I can with Java. I had seen languages that claim to be better than C++, but none as elegant as Java. And so the more I actually used it, the more excited I became about it.

Then, on September 21, 1995, we held the first Java Developer's Conference. That was the first time I was actually able to see the same Java applets running on different platforms, not just on my Sun workstations. It was the first time that I saw the write-once-run-anywhere promise of Java in action. And this was at a venue where we often have Sun events that register a few hundred people and at which we typically have 30% no-shows. For this event, we drew 800 people, and instead of no-shows, we had walk-ins that we had to turn away at the door. The enthusiasm of the crowd was incredible--and the combination of their enthusiasm and seeing all the cool programs that different vendors had brought made me realize that all the excitement about Java was justified.

Noren:

You just completed writing Java Security for O'Reilly. Who should buy this book?

Oaks:

I believe that every individual on the planet should buy this book.

Seriously, since I am a developer at heart, the primary audience for the book will be developers who want to write Java programs that take full advantage of Java's security model. Java's security model is, from a programming perspective, a lot more flexible than many people realize, especially for developers working within a corporate or campus environment. And there are a host of new features in 1.1, and especially in 1.2, that provide programmers the tools to write secure programs. The notion of a secure program goes beyond what we typically think of as a program that contains no viruses. For example, a program that retrieves your payroll data from a centralized server really ought to use the security features of the Java platform to authenticate the request for data in a strong way, and it ought to encrypt the payroll data itself. Java Security shows how to do things like that.

I think that many non-developers will be interested in the book as well. Whenever you talk about security, you end up talking about risks: there are no 100% completely secure systems, and the task that falls upon people is to assess the potential risk of a system with its potential benefits. So I spend a lot of time in the book explaining in-depth the components of Java's security model. There's a chapter on class loaders, for example, since class loaders are a key component in the security model. You may not be interested in writing a class loader, but if you're examining the potential risks of Java, you'll be very interested in the first part of that chapter that explains why the class loader is important and what it does to provide a piece of Java's security model. I tried to segregate this sort of material to the beginning of each chapter so that people who are assessing risk--end-users, or system or network administrators--could read the first half of many of the chapters and understand how Java's security model actually works.

The role of the administrator becomes more important in Java 1.2, when a lot of the flexibility that has always been possible at a programmatic level becomes possible at an administration level as well. I cover that in the book as well.

Noren:

Java has made some dramatic and controversial claims about security. One of those is that nothing hostile can be done using Java, like writing a virus. What are Java's security claims and why are they important?

Oaks:

The key thing to remember about Java's security claims is that they really apply only to applets run in the default state of a Java browser. I mention that first because it's often left out of the discussion, which can lead to a lot of confusion. The first claim is that a Java applet running inside of a standard Java-enabled browser (where there have been no changes to the environment of that browser) meets a certain set of security goals, but that Java programs run from the a command line or file manager, and Java applets that are run from a Java-enabled browser that has a certain configuration, will meet a different set of security goals (which, usually, means no security goals at all). This changes somewhat in 1.2, but it's the state of the world today.

There are many goals for the applet running inside of the secure Java-enabled browsers, but they essentially boil down to this: applets cannot introduce a virus onto your machine, and they cannot retrieve sensitive data from your machine. This means that the applet really has access only to its own local memory (and no other memory on the machine), the machine's CPU, the screen and keyboard, and the host from which the applet was loaded. Hence, the default state for these applets is that they cannot write files or memory locations other than those belonging to the applet, since that would allow a potential virus into the system. Nor can they read files or arbitrary memory locations, nor can they contact other machines on the network, since that is all potentially sensitive information.

Noren:

How successful has Java been at living up to those claims?

Oaks:

I think it has been very successful. Sun publishes a list of Java security bugs that violate Java's security goals at https://java.sun.com. It's instructive to look over that list and make your own judgement as to that claim. It's important to notice that the bugs listed there have all been minor and/or obscure, quickly fixed, and none have actually been widely exploited.

Noren:

A lot of programmers complain that the security model is overly restrictive--for example, applets can't read or write files. How do you accomplish useful work within these limitations? How can you relax these restrictions without asking for trouble?

Oaks:

I think that different security models may be appropriate for different environments, of for different people. You have to figure out what's appropriate and then work around the restrictions of that environment.

Let's take the idea of writing a file: if you want to create a virus on someone's machine, you do that by opening a file and writing the virus code there. As soon as you allow an applet to write a file, you allow for the possibility of the applet introducing a virus onto the machine. Maybe that's a risk that you're willing to take, especially if you're on a secured corporate network where all the Java programs you'll be running come from within your corporation.

Now, let's say that the applet in question carries a digital signature, and that you trust the person or company who signed the applet. If you let it write files on your system, you've increased your potential risk somewhat: the signature accompanying the applet could have been forged if the provider of the applet has been careless with their private key. And even though you trust the provider of the applet, it might still have a bug that introduces a virus onto your system. Still, the balance of this risk versus the reward of being able to save the information locally is worthwhile for many people. In fact, it's really the same risk as buying shrink-wrapped software. We buy shrink-wrapped software all the time, and on occasion that software has been found to contain viruses. You would not want to have a default policy that allowed this type of access even for applets that carry a digital signature, but there are certain times when you might feel its appropriate to relax the policy somewhat. And digital signatures allow an end-user or administrator to relax that policy, especially in 1.2.

On the other hand, I'm waiting for the day when this issue becomes moot--and for corporate networks, we're a long way there already. I think that the idea of keeping state on a client device is a bad thing: it belongs on a central server somewhere where I can access it no matter where I am. Yes, I know that there are logistical networking problems with this at present, but those are being worked out. All this furor over being able to save a file won't matter when there is no local storage on the machine running the applet.

In fact, there are a number of vendors who provide Java network services to allow Java programs to read and write files over the network like this. And I'm personally very excited by the prospect of using these services to work with Java's security model. I'd rather see us all use these services, which allows us to, as you say, do useful work but still operate within the strictest constraints of the security model.

So, you can relax the restrictions if you know what sort of risk you're taking, or you can utilize the power of network computing to work around them.

Noren:

One thing that your book does is show how to relax the security policy. Give us some examples of what that will accomplish.

Oaks:

One thing I alluded to earlier is the notion that the default security policy is not necessarily the best policy for a secured corporate network. You might want to relax the security policy in that case so that you don't have to deal with digital signatures and all its infrastructure because you know everything that goes onto your network. A corporation could let their internal applications work in this relaxed policy and let applets from the outside world operate in the default, strict policy.

But it will also allow for more flexibility in an unsecured environment as well. If you knew that the cool game applet from the local computer club could access the local files it needed but still couldn't access your Quicken data file, then you'd have the confidence to play the game. This type of relaxing of the security policy without throwing it out altogether is very important, I think.

Noren:

The way Java security works changed between Java 1.1 and Java 1.2. Why did it change and what's better about it?

Oaks:

The main result of the change is who is in control of the security policy. In 1.1, the security policy is under control of the author of the Java-enabled browser or of the standalone Java application. In 1.2, the security policy is under control of the end-user or system administrator.

One big benefit of this change is the notion of fine-grained control over the security policy. If you want the code that is loaded from https://www.spellchecker.com to be able to access only the file on your system that contains your personal dictionary, that's simple to do in the 1.2-based model: the system administrator merely has to run a tool and add that appropriate permission. In 1.1, giving that sort of fine-grained control was possible, but it required a lot of programming by the author of the Java application or browser, and so it typically did not exist.

If you like the sandbox analogy that's often used to describe Java's security model, this notion of fine-grained permissions works really well: you can add only those toys (e.g. files, or network permissions, or whatever) to the sandbox that are appropriate for the resident of the sandbox while still leaving the toys that you think are too dangerous outside of the sandbox. That's really an important step in the development of the security features of Java.

This is really an attempt to get the best of both worlds: programs can do what they need to do in a standard desktop architecture, but there's still a degree of security associated with them. And by moving the configuration outside of the program itself, it really makes this notion of fine-grained policies possible.

Noren:

Contrast the Java security model with the one Microsoft offers using ActiveX, now called DNS.

Oaks:

And previously called DCOM, and before that it was ....

The issue boils down, I think, to what authentication means. An ActiveX control may be authenticated--that is, digitally signed--to belong to your local computer club, as may a Java applet. And in either case, all you know is that the computer club provided the code in question. You don't know anything about the code, or the intent of the computer club, or anything else.

So the question is, what do you do with an authenticated piece of code? In the ActiveX world, you give that code free-reign over your system: if it wants to read and write entries to your Quicken data file, so be it. In the Java 1.2 world, you give that code whatever particular permissions you want: if it wants to read some preferences file to find out if its buttons should be displayed in red instead of green, you might allow it to read and write that preference file, but you don't have to give it access to any other files on your system. In Java 1.1, different browser vendors handled this issue differently--but HotJava, for example, allowed you to specify a set of permissions for the signed Java code.

This is not just a question of intent, of course, because ActiveX controls can be signed by a "software publisher" who claims that there are no malicious attacks in their code. I think that the claim there is that you can then sue the publisher of the code if it does something nasty to your system, but I'm not sure exactly who you sue if the code plants something nasty on your system and disguises it to look as if the nasty virus came from someone else. But anyway, it's not just intent. There have been many times when viruses were propagated unknowningly by commercial software vendors, or when bugs in a software package have led to a security breach, and so on. So the all-or-nothing model isn't really the best solution: you still want a fine-grained method of security control.

Noren:

You work for Sun. Where do you see Java developing in the next year?

Oaks:

I can't really answer that in terms of a Sun perspective. Even if I worked for a Java engineering group, I couldn't really give a Sun perspective on that. But from the point of view of an ordinary developer or end-user, I think that we're ready for the next explosion of Java development and applications. In the past, it has been easy to get caught up on the hype and excitement of Java and forget that its a new technology and to get frustrated with some of its immaturity. At the Java Developer's Conference I mentioned earlier, we were still writing to an alpha applet interface, and there was no support for GUI elements. But a lot of people still recognized Java's potential then and spread their excitement.

What's happened since, of course, is that the hype has continued unabated, and the known issues with Java have not been solved as quickly as everyone might have liked--even though we've come a really long way. This didn't prevent a lot of people from doing a lot of really great work in Java, but it was harder than everyone would have liked.

But I think we're on the cusp, with Java 1.2, of another big leap for Java: with the new GUI classes, the enhanced security model, and a new generation of really fast virtual machines. I think that some of the reality of Java will begin to catch up with its promise. Plug-in virtual machines like the Java Activator will allow everyone to take advantage of the new features quickly, and the new GUI classes will make development so much easier that I think the next year will be spent by developers really reaping the benefits of the new pieces to the Java foundation that have just, or are just about to, hit the web.

Noren:

What are the most important problems that still need to be solved?

Oaks:

I think that some network issues still need to be solved. How we are going to get fast connections everywhere? How, where, and when should caching be done? There are a lot of good things happening in all these areas, but it remains to be seen which of them might win widespread adoption. At Sun we use Java programs to do a lot of internal stuff, like filling out expense reports. While doing that on our corporate wide-area network is easy, doing that from my machine at home is somewhat harder, and doing that on my laptop while I'm flying to California is impossible. I think that's the next big issue that people are going to tackle.

Of course, we still need better tools for Java--better builders, better debuggers. But I think that's more a reflection of a timing problem than a technology problem, and I see that being solved incrementally as vendors have the time to write really great tools.

Scott Oaks