Administering a JAAS Policy

Appendix B. Security Resources Books are very useful for learning some things, and hopefully youve gotten some benefit from the one youre holding in your hand. However, for some types of information, the Internet remains the better choice. In this appendix, well list and discuss various network resources that relate to Java and security. One reason why this information is better found on the Internet is because it is subject to rapid change. The APIs weve discussed may remain fairly stable despite the big changes in many of them between 1.1 and Java 2, but the information to be found in these resources is more dynamic. B.1 Security Bugs Early in my computer science career, I handed in an exam that ended up receiving a lower grade than I had expected. [A] As part of the exam, I was asked to write an algorithm, prove that it was correct, and then provide an implementation of the algorithm. [A] Okay, that was not an unusual event for me... While my algorithm and its accompanying proof were completely correct, my implementation received a failing grade. This was a rather dispiriting result: I had come up with a solution and proved that the solution was correct. But the real answer −− the implementation −− was still flawed. Such is the potential problem with implementing a security model. A lot of design and analysis has gone into Javas default security model, and hopefully youll put your own effort into making your own applications secure. But no matter how sound the design of a security model, in the end it is the implementation that matters. In this section, well discuss some past bugs in Javas security implementation and list some common resources for finding out about and fixing present bugs. Few issues in the Java world receive more attention than security bugs; report of a new bug is guaranteed to produce a flurry of activity. As a result, readers of the trade press often have the idea that Java is riddled with security bugs or that it isnt secure to begin with. This is not the case. While some important bugs in Javas security implementation have been reported, the impact of these bugs has at least until now been minimal. Bugs that are reported against Javas security model fall into one of five categories: Reports that are not bugs but that arise from a lack of understanding of Javas security model. There are two types of very common bugs in this category: applets that perform annoying tasks and applets that seem to break out of the sandbox. The former category includes applets that take lots of CPU time or otherwise consume many resources. As we mentioned at the outset of this book, such attacks are annoying but are not security attacks. The latter category often involves bugs that hinge upon someone having installed a local class file or worse, a local native library; as we know by now, these local class files are treated as trusted classes. When one of these local classes is able to read or remove files on your disk, contact a machine on your local network, or engage in some other potentially malicious behavior, word goes out that Java is not secure or at best has bugs in its security model. The lesson to learn from these reports is this: no computer security model is a substitute for vigilant 1. practices by the end user. If your policy is never to run shareware programs downloaded from the Internet, then your policy should be never to install local classes on your system. And while newer versions of browsers, along with the ability in Java 2 to run applications in a secure environment, help to mitigate the potential danger of installing a local class file, such features will never obviate the need for users and system administrators to understand and work with the security model. There may be real bugs in the Java implementation −− but dont assume that all reports you hear about the sandbox being broken fall into that category. Bugs that are misclassified; that is, actual bugs that are reported as being security bugs when they are not. As weve seen, security is pervasive in the Java platform −− the bytecode verifier, the class loader, the security manager, and the compiler all have aspects of security to them. Hence, bugs in these areas are often considered security bugs even when they are not. For example, a bug in the bytecode verifier is usually assumed to be a security bug, even if it is not; if the verifier doesnt accept a particular construct that it should accept, for example, no security concerns arise. 2. Web−related bugs that are not Java−specific. Often, security problems on the Internet are associated with Java without any direct cause. In particular, bugs related to JavaScript TM and to ActiveX often fall into this category. When the first reports of ActiveX security bugs were circulated, there was a lot of discussion about active content; the assertion in many quarters was that the security problems that plagued ActiveX were inherent in any active content system. This assertion attempted to place Java in the same light as ActiveX since both were active content systems. The reality is that Java and ActiveX have very different security models. Similarly, bugs in JavaScript are often confused with bugs in Java, in part because of the name. It is probably well known by this point, but it doesnt hurt to reiterate: JavaScript and Java are completely different technologies produced by separate companies AOL and Sun, respectively. The two technologies are complementary in many ways, but they are fundamentally different from a security perspective. Finally, Java is not immune to security problems that plague the Web in general. Data that is sent between sites among Java applets and servers can be snooped just like data that is sent via HTTP can be snooped unless the Java traffic is using SSL or another encryption technique. A hacker that sets up a site to impersonate XYZ.com will be able to serve Java applets just as she is able to serve HTML. 3. Bugs in third−party trusted classes. When you install third−party classes, it is possible that one of them may breach the security model that you think is in place: it may provide a mechanism for an untrusted class to open a file, for example, based upon the permissions normally given to the third−party class. Complicating this factor is the manner in which these classes are often installed: they are often put into a directory and the users classpath is globally set to include those classes. Now untrusted classes will be able to access the third−party classes. 4. Bugs in the Java implementation. There have been several well−publicized bugs that do involve Javas security implementation; and as with any large computer system, there are bound to be others. 5. This last point should not minimized −− there have been and will be bugs in the Java security implementation. But the potential for bugs and their potential impact must be weighed against the potential benefits of using