If you are implementing an application that makes use of untrusted, dynamically downloaded Java classes, you need to spend some time thinking about security issues. Your application will need a security policy and code that enforces that policy. Just as important, but often overlooked, is the need for a security interface-a way for users to understand and configure the security policy for the application.
It is difficult to know in advance just how much security will be required in a given situation. Although it's not always true, there is often a trade-off between convenience and security. Nearly any interesting application has to enable end users to configure some of the security parameters to suit their particular needs. Unfortunately, many users are not aware of the many ways that security on their systems can be compromised. This chapter gives some tips on understanding the way your customers or users think about security and suggests some strategies for helping them to understand the security issues involved in your application.
Often, the easiest way for a developer to deal with a complicated problem is to hide it from the application's end users. Sometimes, that's exactly the right approach-if the problem isn't central to the task a program is designed for, the users might not need (or want) to know about it. Other times, it is exactly the wrong approach. When it comes to security, users need to know about the problem and understand it. They might not need to know all the complications and intricacies (and there are a lot of those), but they need to know enough to be able to make informed decisions about security.
The difficult part is keeping the security options simple and comprehensible. It's not that application users aren't intelligent; rather, security issues are just hard, and where they are concerned, it is easy to make mistakes. Security experts can deal with all the complexity when they are concentrating fully on security issues, but even experts make serious mistakes if they're forced to deal with all the little details while they are focused on some unrelated task.
Users expect security configuration to be fairly simple, and that's not an unreasonable expectation. The simpler it is, the fewer mistakes will be made, and the fewer unfortunate security incidents in which your application will be involved. When your application is involved in a security incident, even if it is the result of poor user judgment, it affects the way your application is perceived.
Before trying to simplify the security issues for your users,
it's a good idea to try to understand them yourself. This section
provides a brief overview of several common attacks to which users
might be susceptible. (Chapter 21, "Creating
a Security Policy," contains a similar overview, but it is
organized along the lines of the Java SecurityManager
class features.) The following are common attacks:
| Theft of information | Nearly every computer contains some information that the owner or primary user of the machine would like to keep private. |
| Destruction of information | In addition to data that is private, most of the data on typical computers has some value, and losing it would be costly. |
| Theft of resources | Computers contain more than just data. They have valuable, finite resources that cost money; disk space and a CPU are the best examples. A Java applet on a World Wide Web page could quietly begin doing some extensive computation in the background, periodically sending intermediate results back to a central server, thus stealing some of the CPU cycles to perform part of someone else's large project. This would slow down the machine, wasting another valuable resource: the user's time. |
| Denial of service | Similar to theft of resources, denial-of-service attacks involve using as much as possible of a finite resource, not because the attacker really needs the resource, but simply to prevent someone else from being able to use it. |
| Masquerade | By pretending to be from another source, a malicious program could persuade a user to reveal valuable information voluntarily. |
| Deception | If a malicious program were successful in interposing itself between the application and some important data source, the attacker could alter data, or substitute completely different data, before giving it to the application or the user. The user would take the data and act on it, assuming it to be valid. |
To gain an appreciation for the importance of a good, simple security configuration interface, try a thought experiment. Glance at the list of attacks in the previous section and try to answer the following question: "Which resources on my system and in my application will be useful in mounting each of those attacks?" You will probably be able to think of a few things, but how do you know you've identified them all?
If you're reading this book, you probably know your way around Java pretty well. You're probably a programmer, writing applications, thinking about security issues. Furthermore, you understand quite a lot about how computers, operating systems, networks, and applications work. Unless you're a security expert, however, you probably won't be able to identify all the resources that might open the door to a security attack.
If that's true, then how can you decide what to restrict? How can your users have confidence in the security of your application? How can users know whether it's safe to adjust their security configurations at all?
The good news is that you really don't have to identify all those dangerous things. Security experts have already done it for you. The designers of the Java Virtual Machine and library have put a lot of work into identifying the potential dangers. Other security experts have taken a close look at their conclusions and made their own suggestions. Rely on these experts.
Don't start with a blank slate and decide on which things to restrict. You're bound to forget something, and you'll hear about it from the people using your application. Instead, start with the full complement of security restrictions that Java provides, and loosen them little by little, as necessary. Try to loosen the restrictions just as much as necessary, and no more.
With that approach, you can consider the implications of each change carefully, and your users are likely to have far fewer things to worry about.
In addition to the security experts, there's another group of experts you should rely on: the users themselves.
Although most users won't be able to pick out the security implications of socket connections to particular ports, or accessing thread groups, or creating factory objects, they do know a lot more about their own security than anyone else. Users know all about their data, and they know which parts are valuable and just how valuable. They know what secrets they want to keep and what information needs to be distributed right away. They know what information sources they trust and how much damage it would cause if that trust failed. They know what their time is worth.
They just might not know the correspondence between all those things and a bunch of low-level system resources with names they've never heard of, such as SocketImplFactory.
Chapter 21 recommends formulating a security model in terms of application-level resources and abstractions, rather than the low-level resources that the Java SecurityManager class knows about. Doing that will help you understand your security policy, and it will help your users to understand it as well.
Take the example of a group calendar management system. If you were using such a system, you probably wouldn't know the format of the data files it used. You certainly wouldn't know which record in a file corresponded to a particular appointment. You might not even know where-in which file-the calendar is stored. Those aren't the kinds of things you care about when you're using a program (unless you are the program's developer).
You would know the important things, though. You would know, without really even having to think about it, that people outside your group shouldn't be able to look at your work calendar, and that your personal calendar should be inaccessible to everyone except your family and a particularly close group of friends.
Those are the kinds of issues that users will be thinking about when they make security decisions. If you let them make decisions on that level, you won't have many confused users.
The calendar example is also used in Chapter 21, which mentions the possibility that it might be nice if, on occasion, your calendar program were not entirely honest-for instance, if you were trying to avoid a particularly tiresome series of meetings. With a program like that, fine-tuning the security configuration might actually be fun! Just remember that the security configuration file might be just as incriminating as the calendar itself.
One group of users deserves special consideration: site administrators. They are often charged with enforcing organizational security policies, so they will have a special interest in your application's security configuration.
Most site administrators want to be able to control the security configuration for all the users they support. Individual users may be allowed to make some security decisions on their own, but certain choices will be prohibited by administrators. The reasoning is similar to that for network firewalls: to guard against the possibility that naïve or distracted users may inadvertently open a security hole that could damage the organization (and the administrator's career).
Frequently, site administrators make decisions about which software will be purchased and installed at their site. They will be reluctant to choose applications that make it difficult to uphold their organization's security policy.
You should seriously consider providing a way for site administrators to limit the range of security decisions available to users. At a minimum, your application should support a site-wide default configuration. Ideally, it should also provide the capability of setting bounds on the allowable security levels and of locking in particular configuration options so that they cannot be changed by individual users.
Basing the security model on application-level ideas helps, but it won't solve all the problems. That technique doesn't really help much against denial-of-service attacks or masquerades. Users still, on occasion, obediently type their usernames and passwords into dialog windows that pop up on their screen, even when the windows are labeled "Untrusted Applet Window."
Other factors will improve the situation, though. The security infrastructure on the Internet will improve, and people will become more aware of some of the risks. Over time, more people will come to understand that their computers are tools, and that the computers should obey people and not the other way around. As network access becomes more and more prevalent, and as the Internet and the Web become more useful and less a playground, people will be more conscious of the Net and more aware that it may hold some dangers.
At the same time that users learn to tighten up, corporate information officers will learn to lighten up. There will certainly be some resistance to Java-enabled applications in some corporate environments, due to fear of security holes. That resistance may never go away entirely, but it will diminish as people become convinced of the effectiveness of Java's security mechanisms and as Java applications become more powerful and useful.
Not too long ago, most companies considered it sheer folly to connect their computers to an external network. As understanding of network security grew, more companies took the plunge, and now many companies see Internet access as crucial. (In January of 1995, I was playing with a Java-like system that permitted sending secure applets, of a sort, through electronic mail. A colleague scoffed at the idea, saying that he would never install a program that would allow code straight off the network, from unknown sources, to run on his machine. Less than a year later, he was downloading the latest beta release of Netscape Navigator, playing with applets.)
User understanding of security issues and official acceptance of Java applications will feed off one another. If users understand the security options in your application, they will make fewer errors. The more your application is used without permitting security breaches, the more acceptance it will get from "the powers that be."
The security interface is a vital part of an application's overall security structure, and it should be designed carefully. An annoying or confusing security configuration interface can lead users to make poor security choices, undermining even the best security features. Many computer users are unsophisticated about security, and the corporate world can be excessively paranoid at times. The tension between the two makes the security interface especially important. A good security interface might give your application a valuable competitive edge.
Security issues can be complex, but the solution isn't to hide them from users; instead, you should present them in simple, understandable terms that are relevant to the concepts with which application users are familiar. It's also important to give site administrators a special measure of control over security configuration so that they can make certain decisions on a site-wide basis.