Writing Secure Libraries

The process of writing and specifying good libraries cannot be overemphasized in the importance of Java security. The paper Security Flaws in the HotJava Web Browser by Drew Dean and Dan Wallach gives a number of good examples of how the security of the HotJava Web browser is compromised by errors in implementation of the libraries. Dean and Wallach point out flaws in the implementation of the 1.0 alpha 3 release libraries. They show that a number of variables and methods are made publicly accessible and do not have security checks, allowing certain breaches of security. While these specific problems have been fixed in the beta version of the Java runtime libraries, they show that correct specification is not a simple task.

The problem of security is made more difficult by the fact that even if the libraries are written properly, the writer of a Java enabled Web browser must correctly implement and specify their part of the SecurityManager. The SecurityManager is an improvement over the previous versions more spread out mechanisms, providing a specific and well-encapsulated way of flexibly setting up a security policy. Nevertheless, the fact that a Web browser has direct hooks into the security of the Java system increases the potential for errors in specification and implementation. While Java itself may undergo fairly rigorous scrutiny, it is quite possible the Java enabled browsers may not be as careful, relying on Java's built in security.

The security of Java thus relies upon the correct implementation of a fairly large code base. This situation is a result of Java's design choice to provide a very flexible security model. By giving application writers hooks into the systems security, they have offered flexibility at the price of opening potential holes.