HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Introduction
Scheduled for a beta release at about the time this issue hits the news stands, the next version of Java will finally offer the fine-grained system resource access capabilities that Java programmers have been begging for since JDK 1.0. Not just a new capability, this represents a new step in the evolution of Java's security architecture.

Existing Security Model
A review of the existing Java security model will be useful. Whatever its antecedents, the first codebase to be named 'Java', and released as a general purgramming language and a mobile code architecture, anticipated security concerns. The Java Virtual Machine is designed to allow applets very limited access to system resources. while code located on a local drive runs virtually unrestricted. Code running remotely (i.e., applets), is only allowed access to the GUI (screen, monitor and keyboard), the originating host and CPU processing resources.

Java's security architecture is comprised of three different mechanisms. The first mechanism is the Byte Code Verifier, which checks incoming code to ensure that it is correctly formatted and does not contain any illegal usages. The second mechanism is the Class Loader. Responsible for loading all Java classes, it makes a distinction between local code and networked code and loads the Security Manager to enforce the restrictions on non-local code. It is essentially a reference monitor, a mechanism that actively enforces a security policy. In this case, the Security Manager prevents any attempts at accessing local resources, such as files or the network stack. Think of these components as three legs holding up a stool. If any code is caught attempting to circumvent any single one of these mechanisms, the stool falls over.

Certainly there have been much-publicized security holes in the common implementations of the Java Virtual Machine, Microsoft's Internet Explorer and Netscape's Communicator, but these have been just that - implementation bugs. The basic architecture has held up quite well. Millions of systems connected to the Internet are running these products - bugs and all - but there are absolutely no recorded cases of any actual Java security failure outside of the laboratory.

The interesting Java security story is that it actually works too well. Many potential Java projects have been unfeasible, because Java applets cannot access local resources. JDK 1.1 introduced the concept of digitally signed code. Digital signature provides a means to identify the source of an object (to any arbitrary level of assurance) and to verify the integrity of that object. It is a mechanism that allows the trusting of code even when it is accessed through non-trusted means. The JDK 1.1 JVM allows signed applets complete access to local system resources. While this is a step towards the support of a more powerful capability, it wasn't compelling enough for the browser vendors to actually implement it. The real need is to allow trusted mobile code the ability to access specific resources but without giving it carte blanche to access all local resources. Enter JDK 1.next. (Note that the working designation is 1.2, but Sun has not announced its official numbering yet.)

Protected Domains Security Model
The new security model - which represents an evolution of the existing model - is intended to provide a number of benefits:

  • expansion of the Java Sandbox model in a way that is easy to administer
  • accommodation of the typical hierarchical network, taking into account the existence of local resources, organizational resources and external resources
  • a new default setting that allows applets secure access to a specific file system area
  • a unified security architecture that encompasses both local code and remote code
Unsigned applets will still work within the same Java sandbox as before (although it will be implemented differently). By default, signed applets will have read and write access to a specific file area (/sandbox). Applets will not be allowed to execute from this file area - only reading and writing are allowed. If desired, an administrator may turn off this capability, but it is intended to provide a certain level of convenience to Java applets without requiring a lot of administrative decisions. If desired, signed applets can be allowed selective access to specific resources outside of the extended sandbox.

Figure 1
Figure 1: By default, JDK 1.2-compliant JVMs wiil
support the original sandbox.

Sunsoft's concept of a Protection Domain is really an object-oriented way of grouping resources to simplify the administration of their access. Well regarded by security researchers, Sun hired Li Gong in 1996 to architect the security of the upcoming Java release. His "Java Security Architecture" whitepaper describes domains:

"A domain can be scoped by the set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which authorizations (and as a result, accountability) are granted. The Java sandbox is one example of a protection domain with a fixed boundary...[they] serve as a convenient point for grouping and isolation between units of protection."

Protection domains can be hierarchical in terms of the level of access they are permitted and generally will be either a system domain or an application domain. Protected external resources, objects such as the monitor and input devices, network stack and file system, are not accessible through application domains. The JVM maintains the mapping between domains and permissions. When a thread of execution involves more than one domain, the Java runtime ensures that its permission consists of the intersection of all domains it traverses. Naturally, there are times when this conservative policy will be too restrictive, so the beingPrivileged and endPrivileged calls are provided to allow for exceptions. Code can be written using these calls to explicitly allow access to an object when the code is being invoked by a principle that normally wouldn't have that access. Conceptually, this is comparable to a UNIX application with SUID root permissions so that users invoking it can run it with the privileges they would have if they had logged in as root. The advantage of having a pair of calls is that the privilege can be turned on and then off - within the code - as soon as possible. The temporary granting of increased access can be more tightly controlled than is possible with a clumsy mechanism such as SUID.

A New SecurityManager Class
The implementation of the Security Manager is being changed to accommodate the new capabilities. While the original functionality will remain, providing full backwards compatibility, the Security Manager is being rewritten as a more modular and flexible service. One of the most important goals is to allow changes to the security policy without the necessity of programming. Administrators, system integrators and individual users will be able to change JVM security policy without having to write code. This will be a major convenience and productivity enhancement both on the client side and for Java server applications.

In "Implementing a Security Policy," (Java Developer's Journal Vol.2, Iss. 8), Qusay Mahmoud highlights the need for specifying a security policy and describes building it into a server application by subclassing the SecurityManager class. JDK 1.2 will simplify this process by allowing configuration of security policy through a text file. This ease of configuration will encourage greater attention to security and place final specification and implementation of policy where it belongs - with the system administrator responsible for the management of an appropriately secure real-world service.

Anticipating the Future
The beta version of JDK 1.next is anticipated to ship in late 1997. Netscape has already committed to making a browser that is 100% pure java-based. While it is easy to discount this claim as marketing hype, and of minimal benefit to the end-user or programmer, hopefully this will provide a benefit in terms of security capabilities. By completely building its browser using the classes from the next version of the JDK, they will be able to take advantage of the Protection Domains model as implemented by Sun. The user client itself will use the Java security architecture, and their operating system access will be mediated by it. Note, however, that Netscape has already started down their own path by publishing their own Java Capabilities API to provide fine-grained access'.

Microsoft also has promised to allow Java applets greater access granularity and, like Netscape, has not committed to specific capabilities or time frame. Like all licensees of Java, their contract calls for them to implement new Java codebases within six months of their release by Sun, so it is likely that Microsoft will provide support for these features by mid-1998.

While their administrative interfaces will probably differ, properly implemented Java runtimes should be able to run the same code and support the same flexible access to system resources. It would truly be unfortunate if users had to run both Internet Explorer and Navigator in order to support proprietary' applets, especially if both require their own security administration. The current JVM implementations are already showing evidence of diverging behavior, as evidenced by their security bugs, which are no longer shared. Netscape and Microsoft are also promulgating different certificate infrastructures. Dr. Gary McGraw, co-author of the book "Java Security" and a recognized authority on Java implementation security, is concerned about this issue. "Security never was easy; this [divergence] just makes it more arcane and confusing for people who don't understand it but really want to manage security."

Administration of the security profiles - a responsibility of the system administrators - will be critical in ensuring the expected new functionality while not introducing unanticipated vulnerabilities. It's reasonable to expect that the vendors will develop something more sophisticated than a text file for security policy configuration of their JVM implementations. To effectively enforce security policies, they must not be modifiable by the users, which implies a locked or encrypted file or an ACL-controlled registry entry. The new security functionality will be a boon to developers, but it might become a nightmare for IS staff.

Just the fact that this will be a new implementation has significant security implications. According to Dr. McGraw, "Any time you have new code, you hope it's implemented right. The bigger and more complex it is, the harder it is to get it exactly right. Unfortunately for security, it's almost impossible to get it exactly right." Historically, every implementation of a Java Virtual Machine has introduced new security holes, and this version will be the most complex. What will the the vendors do to ensure that their code functions correctly? Anticipate a period of time while the bugs manifest themselves and are fixed.

Figure 2
Figure 2: System resources are only available through
system domains

Conclusion
The next version of the JDK offers a crucial new capability necessary for the wide-spread productive use of Java. The presence of Li Gong on the development team is evidence that Sun has increased their commitment to developing a secure technology, but that doesn't guarantee that the products marketed by Netscape and Microsoft will be well implemented or compatible. In the relatively short history of Java, the good guys are undefeated - security holes have been discovered and fixed before attackers have been able to develop and use exploits. Be cautious about using and administering JDK 1.2 - especially during the break-in period' - but if it is well implemented, includes a practical management interface and is well administered, the new Java Security Model will be highly successful.

For Further Information
Sun's web site is the best source for detailed information about the next version of JDK, including Li Gong's architecture document: java.sun.com/products/jdk/preview/docs/guide/security/index.html

About the Author
Jay Heiser is a computer security consultant located near Washington, DC. He has a Master of International Management degree from the American Graduate School of International Management and eight years of experience helping people use the Internet. Jay can be reached at [email protected]

Summary
 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.