the security model of JDK 1.2

by Dario Forte
<dario.forte@usa.net>

Dario Forte is an Italian system administrator and freelance journalist. He is CCSE and CCSA CheckPoint Certified and is a USENIX-SAGE individual member and can be contacted at
<www.darioforte.com>.


After the polemics about the JDK.1.1 security policy, the primary JavaSoft objective is to facilitate the work of the applet programmer as well as making Java applications compliant. The aim of the designers of JavaSoft is to provide multilevel security mechanisms as outlined in following the steps.

Fine-Grained Access Control: This widens the concept of granularity, which, to be well implemented, requires considerable effort at the programming stage to optimize the development personnel, with experience not only in programming, but also in information security. During a recent unofficial conference held in Rome, Italy, representatives from the computer security industry, academia, and Sun Microsystems jokingly observed, "How much is the developer really in possession of all these qualities to prevent costing 200 million lira per year?" The likelihood, at least in Italy, is very low! This is the same argument that the designers of Sun Microsystems must have come up with when drawing up the new security analysis model.

Easily Configurable Security Policy: Though this was included in the previous release of the JDK, it was not easy to use. The main improvement to this problem will be to allow the developer to implement personalized and flexible security policies without programming.

Easy, Extensible Access Control Structure: Many of the criticisms brought to the designers of the sandbox have commented on the lack of configurability of the Security Manager for creating new access permissions. To address this criticism, it was necessary to program a new check method and add it to the Security Manager. Few developers were available to solve this problem, which represented a potential leak in the management of the strategic security system.

The Evolution of the Security Model

Related to the general analysis model, there are different complementary approaches to Java security, especially concerning the applet layout and application. One of the recently proposed techniques is "Java Stack Inspection." The principle here refers to undocumented security procedures that can be executed automatically, allowing a more flexible standard policy for the sandbox. Automation of the procedures is possible by rewriting all the Java classes to execute an additional step that will invoke the check procedure. This is called security passing style.

Stack Inspection has been adopted from the browser manufacturers (Netscape and Microsoft) into JDK 1.2. The general principle of Stack Inspection has been implemented in Netscape Navigator version 3.0 onwards. Without going into great detail, Java Stack Inspection is based on the principle of "Privilege assignment," based, in turn, on the following:

• enablePrivilege ()
• disablePrivilege ()
• checkPrivilege ()
• revertPrivilege ()

These elements are set up to guard the "dangerous resource," a term used to describe resources that must be protected. This is reminiscent of a recent technique criticized by some people for being too complex.

Another study has been undertaken in order to solve the problem of multiprocessing. This is especially the case for Java-based solutions in the networking field, where the demand for the Java platform is in the multiprocessing field for multiusers. There have been some attempts to solve this problem in JDK 1.2 beta version in order to provide security in the execution of the mobile Java code and increase access to more users.

As previously mentioned, the execution of "risk" actions from the part of the .class file is substituted in the first place to the security manager of the JVM, which analyzes the calls according to the cases and allows or disallows the execution. JDK 1.2 has an alternative process evolution of applet checking. To create a distinction between local code and remote code, policies are set before deciding the work. This is also the case to determine whether or not the code is from a trusted source based on a digital signature. In the multiprocessing field, this operational principle will be taken as a base to combine the source-based policies with the user-based policies.

Conclusions

On one hand, many developers are disposed to think well of the developments in the new model of Java security. Others see the developments as an acceptance of defeat to those who have preached about the insecurity of Java.

On the other hand, it appears that the new "policy and permission-based" security model is an intelligent simplification of the programmer's work, but for the developers, the "signature-based" method has been poorly considered. For some, who remember the failure of Microsoft's authenticode to secure ActiveX, JavaSoft is an unloading of responsibilities for developers. However, sole responsibility for applet security now lies with the developers.