Initial Foreword and Addendum

Initial Foreword (as published in October)

DYADE is a common emanation of BULL and INRIA devoted to Internet and Intranet problems. In DYADE, the VIP (Verification of Internet Protocols) team, headed by D. Bolignano, is more especially in charge of security problems and formal verification of security policies. During the last months, within DYADE, I have been in charge of a survey of Java security problems.

The point of view I have adopted to guide my investigations was the one of a honest third-party Java programmer who would aim at providing additional Java libraries, or stand-alone Java applications, that could be exploited in a Java-enabled browser environment. From this perspective, I have found, on points that are often poorly documented in JavaSoft official documentation, some very serious and unexpected weaknesses in the Java security model as it is presently implemented. These weaknesses are different from those pointed out by the Princeton Safe Internet Programming team: they are not related to flaws in the design of the Java language, and are no more related to bugs in the Java runtime system implementation.  They are only due, in my opinion, to an incompleteness of the (low-level) security model itself and to some subsequent arbitrary implementation choices that did not respect the spirit (if not the letter) of Java semantics. As far as I know, the correction of these weaknesses is not under consideration in JavaSoft future release anouncements.

In the first section of this page, I informally discuss some of the weaknesses I have found. In the second section, after a recapitulation of these weaknesses, I propose some possible solutions to get a really secure Java runtime system that could be free of these weaknesses without requiring any modification of the Java language itself.

So, this page must not be understood as an attack against Java. I believe Java is a great language that can bring substantial benefits from the security viewpoint. But I also believe that specific, low-level, modifications of the present (JDK 1.02, probably true also for JDK 1.1) Java runtime system are needed to bring more robustness to (higher level) Java-based security architectures.

This page is a draft still under construction. It is a still evolving synthesis of a previous report I wrote in French. A lot of apologies for my bad english. Any suggestion, comment or critic welcome at Jean-Paul.Billon@dyade.fr



Addendum (new remarks from December 96)

Contrarily to what I had initially written (see just above) in October, I shall not any longer upgrade this paper. I think it will be better to write an entirely new paper with a more organized plan. Things have rapidly evolved during the two last months. On a first hand, there is now a quickly growing set of third-party additional Java libraries currently available. Some of them are just about security, but seem to have been conceived without any understanding of the weaknesses I discuss in this paper. On the other hand, JavaSoft will certainly migrate during next months to a new security architecture (extended sandbox model with privilegiate signed applets and/or gateway model examplified by JECF) , certainly much more elaborated than the sandbox model and with a much wider scope of security objectives. However, it is still uncertain that the basic weaknesses of the Java runtime system I discuss in this paper will be seriously reconsidered.

Some remarks on these points can be found in the addendum page.

I. The Sandbox Model as an "Electronic Maginot Line" : Examples

Introduction

The official "philosophy" of Javasoft is that Java is a powerful programming language that can be used for two completely separate ends :

All the security efforts are for now exclusively oriented toward this second case of use : how an applet viewer can securely execute foreign applets that are a priori "untrusted" pieces of code. This leads to the so-called "sandbox" model. A foreign applet is treated as an irresponsible "baby" who is not allowed to move beyond very precise limits : it must strictly respect the semantics of the Java language (bytecode verification and access restriction checks), it must not redefine "system" classes with new classes of its own (verified by the class loader used by the applet viewer) and it must not try to perform "dangerous" actions such as reading or writing anywhere in the local file system (controlled by the security manager installed by the applet viewer).

According to the official "philosophy" of JavaSoft, the sandbox model provides a complete protection against hostile foreign applets, and any additional piece of "trustworthy" Java code can be safely installed in the local file system in addition to an applet viewer. Let me cite JavaSoft: "[since they] are only installed by trusted individuals, Java applications add no new security concerns"(in Java Security by J.S. Fritzinger and M. Mueller, p.4, col.2). According to this view, the only question about security model would be to make the sandbox model both more robust and flexible.

I believe this "official" position is rather misleading and makes the protection provided by the sandbox model implemented by applet viewers as illusory as the French Maginot line was against attack by Hitler's troupes (to reuse the image introduced by Bill Wulf in JavaSoft security forum).

Let me just briefly recall what the Maginot line was : an unbreakable barrier of defense that had been built by the French army, just before world war II, on the whole length of the frontier between France and Germany. The fundamental point is that it was really impossible, with the means of that time, to open any breach in this continuous line of defense. The great mistake that French people made was to divide their neighboring world in two parts : dangerous enemies (mainly Germany) and trusted friends (among which Belgium). In consequence, they did not extend the Maginot line protection to the frontiers between France and their trusted neighbor that was Belgium. In fact, the real mistake was not to consider Belgium as a trustworthy friend, but to make a semantic confusion between "trustworthy" and "secure". Belgium was a real friend of France and had no secrete pact with Germany. But it was not "secure" because it was not well protected against an attack of German army through its frontier with its own friendly neighbor, Netherlands, itself unable of any serious military defense. And it had been very easy for Hitler's troupes to defeat Netherlands, then attack Belgium through its unprotected frontier with Netherlands and then France through its unprotected frontier with Belgium, without any need of a frontal attack against the Maginot line.

The lesson of the Maginot line uselessness is that it is illusory to protect oneself only against the frontal attacks of potential enemies : you have also to protect yourself against your trusted neighbors, or to protect them, if they are not able to protect themselves against potential attackers that could take control of them. And so, adding new trustworthy pieces of Java code in the neighborhood of an applet viewer may lead to deep security problems, especially in reason of specific features of the Java system, security problems that the official "position" of JavaSoft about its sandbox model seems to ignore.

Let me now justify this opinion.

I.1 Security Concerns of Additional Java Modules

Java, not to be confused with JavaScript, is a powerful complete programming language intended to build stand-alone and rather open applications. That the Java compiler allows to compile separately small units like individual classes that the run time system can load and link dynamically is a prominent feature that provides a great flexibility and extensibility. This means that independent stand-alone applications can be downloaded from remote servers and dynamically linked and executed by "master" Java applications (e.g. an applet viewer), but also that any kind of additional modules or public libraries can be added to the CLASSPATH of a Java applet viewer or any other Java application (I recall that any class that is stored in the directories of the local file system mentioned in the CLASSPATH environment variable is considered as trusted "system" code by the Java runtime system).

The fundamental point here is that a Java applet viewer, like the one of Netscape Navigator for instance, is not at all a piece of native code hidden somewhere into a browser main body code file : a Java applet viewer is itself just a stand-alone Java program whose individual classes are stored in one or several separate data files. What may come merged within the browser main body code file is just a rather standard Java runtime system that can execute any kind of Java program. Programmers are free to implement Java programs that can download and execute foreign Java code with their own class loading and security management policies : there is no constraint to use a ready-made applet viewer coming with a Java-enabled browser. It can be also noticed that the security policies of those ready-made applet viewers are not universal and may be quite different according to the way their security manager is programmed : for instance, the security manager used by Netscape Navigator 3.0 is much less liberal than the one of the applet viewer provided with the JDK 1.02 or HotJava 1.0beta. Even the standard Java APIs do not correspond to real built-ins of the runtime system and are just a set of separately stored individual classes (regrouped in one zip archive) that are loaded and linked dynamically by the runtime system and that can be easily modified or masked.

I am not sure that all the consequences of this openness of the Java system are presently well understood. For instance, there are already many applets proposed in repositories like GAMELAN, many stand-alone programs for the server side, but until now, no additional modules or libraries to be placed in client CLASSPATH to extend applet viewers (but remember that, as soon as an applet is stored in the CLASSPATH of an applet viewer, it becomes trusted "system" code and can act as an additional module escaping the sandbox model).

As Java is especially designed for extensibility, it would however be completely unrealistic, and contrary to the very philosophy of Java, to assume that no additional Java modules will never be added to the CLASSPATH of the ready-made applet viewer coming with a java-enabled browser. Indeed, this is not assumed by JavaSoft: the "official" position is just that this does not lead to any security problem as far as the additional piece of Java code is trustworthy. And new Java extensions using the future Java Management or JECF APIs will just be such additional Java modules extending ready-made applet viewers. In fact, browser extensions (plug-ins) will more and more be provided as such Java modules that will be placed in the CLASSPATH : Netscape Navigator 3.0 itself comes already with several such plug-ins that are just Java classes exploited with the same Java runtime system component that also runs its applet viewer program. And the same kind of free extensibility problems will also arise on the server side when Java server programs like Jeeves will download and execute foreign "servlet" modules.

In the sandbox model, all the protection effort of a foreign code (applet, servlet, etc.) viewer is devoted exclusively to make impossible direct attacks from untrusted foreign code. And no protection at all is provided against indirect attacks that could be performed by the means of additional modules that could be placed in the CLASSPATH, because it is assumed that only trustworthy code has been stored in the local file system and that, thanks to the sandbox model, a foreign untrusted applet cannot write by its own in that local file system to store hostile files. This is where the present interpretation of the sandbox model is rather like the French Maginot line : it does not take care of possible indirect attacks by enemies that could take control other trustworthy but insecure neighbors that are not able to protect themselves against such attacks.

The sandbox model makes a priori no distinction between trustworthy additional modules and secure ones. A Java library or program intended to be installed in the CLASSPATH of a foreign code viewer can well be trustworthy to be without any hostile intentions : this does not means that it is secure. To know whether or not it can be secure, this notion would have to be precisely defined, which is not presently the case because the sandbox model does not define any kind of internal security policy between local modules. And, as we shall see, the potential securities that Java allows programmer to specify in additional modules can be useless if the foreign code viewer is not aware of the existence of these modules.

I.2 Example 1

Let me give a first example.

Suppose you are a third-party (and honest) programmer who has carefully read publicly available JavaSoft documentation. You want to provide an additional Java module that can perform electronic payment with usual Java-enabled browsers. You want, for the sake of ergonomy and automaticity, this module can be activated by foreign applets coming with HTML pages of vendor servers. This is a reasonable wish, because otherwise this module would have to be explicitly loaded by user, and many parameters, such as vendor URL and various order information, might have to be typed in by user while they could be automatically transmitted by vendor applets. So your module has one, and only one, public entry point (a unique public method in a unique public class) programmed in such a way that the subsequent execution of the payment transaction cannot be done without user authorization.

As this module is intended to be called by foreign code, you may have a problem with the security manager of the ready-made applet viewer of some Java-enabled browser : it might systematically forbid your classes to perform some necessary actions such as reading local files where user confidential data are stored. To avoid this, instead of calling the standard API public read/write methods that systematically ask for security manager checks before calling themselves the private native methods that really perform these actions, you just have to call directly these private native methods of the standard core API. This is perfectly possible because the Java runtime system never verifies access restriction on imported resources when the importing class has been loaded from the CLASSPATH. So, using a modified Java compiler (or a standard Java compiler with modified core API classes), you can compile classes calling private native methods of the standard core API as if they were public ones, and, in consequence, bypassing any security manager control when they are loaded from the CLASSPATH, even if they are activated by foreign applets.

You could believe this trick is safe from the security viewpoint because your module has no public entry point except the one that systematically leads to ask user for authorization. But, suppose your electronic payment module is a whole Java package whose name is, say, "EPayment". As it is a new additional package, this is where your approach is very insecure : the present Java runtime system accepts foreign classes can be declared as members of any package, even those already located in the CLASSPATH! It is only the security manager that can forbid foreign classes to be declared as members of certain packages (the packages that foreign code is not allowed to extend by new classes are defined in a list that can be itself hidden in a compiled class of the applet viewer, and so that is not modifiable). As long as the security manager is not aware that it must take care of the integrity of your package "EPayment", it will never forbid applets to declare new classes in that package, classes which will then access, as if they were public, any of your methods or attributes you have not explicitly declared as being "private" (because, according to Java semantics, everything is public among classes of a same package except what has been declared "private"). So, your honestly, but trickily, programmed module can become the back door through which hostile applets can escape the sandbox model without having to break by deep hacking the security barrier of the applet viewer.

By keeping secret the Java sources of your electronic payment package, you might hope it could however remain safe, because without those sources it would be impossible to know what non private methods and attributes are defined in your package. This is also an illusion, because Java bytecode is so much informative that it is very easy to reconstitute the original sources from which it has been compiled (see for instance the Java decompiler Mocha).

The last point denotes a funny contradiction: you cannot keep your sources secrete because Java bytecode has to be very informative about those sources to allow bytecode verification and access restriction checking. But on the other hand, all the security problems come from the fact that your bytecode, as it is stored in the local CLASSPATH, will never be verified by the runtime system and that the access restrictions it declares will be in most cases useless as foreign code can freely declare new classes as being members of your package with privileged accesses to your methods and attributes.

However, the first very serious problem illustrated by this example is that the lack of any verification on "trusted" code is a permanent invitation to bypass the securities installed by other modules as soon as this may be thought of some practical interest. So, all the securities that a programmer may implement through access restriction declarations to protect its packages can be ruined, with no hostile intentions, by other programmers for the practical needs of their own additional packages. It was the case in our example where our imaginary programmer thought he needs to bypass the security checks of the applet viewer.

The second, even more dangerous, and, indeed, very surprising problem, is the lack of any serious support from the runtime system for the fundamental notion of package. You cannot declare all attributes and methods of your classes "private", because such classes could not be used (except if you rely on a tricky systematic violation of access restrictions by "CLASSPATH" code). So, at least one method of each of your classes must not be declared "private". Then, the distinction between members of your packages and classes external to those packages is the only line of defense that you have to prevent these non private methods to be used by any foreign code as if they were public. So, the systematic protection of the integrity of the packages installed in the CLASSPATH is the minimal guarantee that is absolutely needed by programmers to conceive any security policy for their modules. The present Java runtime system implements a very liberal and unexpected interpretation of the notion of package that is in total contradiction with this fundamental need: not only a package is not considered as a unit of code, it is the individual class which is the only unit, but, moreover, to be member of a package is mainly treated like an optional attribute of a class, attribute that can take any value more or less independently of the location from which the class is loaded. So, the protection of local packages against foreign applet intrusion in their privacy is not guaranteed by the runtime system, but only by some optional checks that might be performed by the security manager installed by an applet viewer.

Note that the present Java runtime system does not provide any support to the security manager to know what are the packages currently in the CLASSPATH. For this reason, the security manager must rely on a preprogrammed list of packages to be protected, list that is not always made accessible for required modifications (e.g. Netscape Navigator 3.0).

I.3. Example 2

Now let me introduce a second example.

Suppose that being now aware of the risks I have mentioned, you decide to program a more clean and secure electronic payment module. You accept to make it invisible to foreign code not declared as belonging to your package (no public entry at all) and you modify the applet viewer in order to make it aware of the existence of your package to protect it against redefinition and also (redundantly) any access by foreign code. Is now your module secure ? Not at all ! Suppose another programmer provides an additional program to be used as a local applet and that this program implements its own particular class loader to download foreign code. As this other programmer may be unaware of the existence of your "EPayement" package, he will not program the required checks to protect your module against redefinition by foreign code. Even if now your module does not try any longer to bypass the security manager checks, according to the various security policies implemented by the security manager of currently available browsers, you cannot be sure that any risk can then be avoided...

So, the present Java runtime system, which is inspired by a very narrow vision of the sandbox model, imposes a double security interdependency between local Java packages: the security of any of them can be voluntarily broken by any other one for practical purpose, while the security features of all, relying basically on the respect of their integrity by foreign code, depends on optional checks that are expected to be performed by modules downloading foreign code. In consequence, storing in the CLASSPATH of a foreign code viewer new additional modules provided by trustworthy independent third-parties must be heavily discouraged for security reasons, while this is contrary to the native openness of the Java system and is not at all forbidden by current implementations.

I.4 Final Remark

Let me finally remark that assuming no hostile piece of Java code is stored in the user local file system is in general a rather unrealistic and quite risky assumption, because Java compiled classes, and in particular those of applets, are just small data files recording, apparently opaque, bytecode, easy to discretely hide, and moreover that will more and more often accompany HTML documentation users are commonly downloading and storing in their local file system for off-line reading (e.g. the HTML Java Tutorial of Sun that comes with many applets). As long as those locally stored applets are not belonging to the applet viewer CLASSPATH, they will be treated as foreign untrusted code. But, as soon as they are stored in the applet viewer CLASSPATH, they will be systematically treated as trusted system code on which no verification nor limitation is never applied by the runtime system nor the security manager installed by the applet viewer. This last feature makes very easy for attackers to put hostile code in the CLASSPATH of "naive" users who may not be Java expert and who may even have no idea of what the notion of CLASSPATH could mean (anyway, try to guess what is the default CLASSPATH of you favorite browser : this point is generally not documented, but, for the today most widely used browser, Netscape Navigator 3.0, I found its default CLASSPATH surprisingly wide and exposed. And the applet viewer of JDK 1.02 extends dynamically its CLASSPATH to embed all subdirectories of the directory where lies the HTML file that you drag and drop on it ! ).


II. Toward a Secure Architecture : Some Possible Solutions Preserving Flexibility

II.1 Recapitulation of the Main Weaknesses of the Present Java Runtime System

The present Java runtime system does not provide any guarantee of its own. Let us recall the main weaknesses related to this lack of guaranties:

II.2 Imperative Requirements

In order to provide any additional Java module that could be installed securely in the environment of a Java program downloading and executing foreign Java code, programmers need imperatively the conjunction of the following basic guaranties:

All these basic guaranties would have to be provided by the runtime system itself. As I recalled it at the beginning of this section, the present runtime system provides no guaranty at all, which leads to the weaknesses I have mentioned.

But, thanks to the good features of the Java language, it is rather easy to design simple and effective modifications of the present Java runtime system that could solve all these problems while requiring no modification of the language itself and while preserving most of Java flexibility and extensibility. I propose such possible modifications leading to what I call "the secure runtime system". These modifications would provide rather complete answers to the real and specific security problems that can arise from the fact that any additional Java module added to the CLASSPATH of a foreign code viewer might become involuntarily an easy-to-open backdoor to escape the sandbox model. extensibility.

II.3 Proposed Enhancements for a Secure Runtime System

In the sequel, I just briefly sketch such possible modifications leading to what I call "the secure runtime system".

The first modification is related to the use of two pairs of asymmetric keys.

The first pair is used to encrypt/decrypt Java classes. The encryption key is public, while the decryption key is secrete and specific to only one installed instance of the secure runtime system. Only a part of the secrete decryption key is hidden in the runtime system code. The complete key is computed at launch time from this part and another part that must be typed in by user. The encryption key is public and must be certified by some trusted authority. Thus, thanks to encryption with this public key, new additional Java modules will be provided for this specific instance of the secure runtime system in such a way that no other runtime system and no human spy will be able to decrypt the encrypted modules. Thanks to this solution, it will not be necessary to protect class files against any read operations.

The secure runtime system will also have a special procedure to install, under its own control, classes in the CLASSPATH. When it installs (encrypted) classes in its CLASSPATH, the secure runtime system digitally signs them with the secrete key of the second pair of keys (this secrete key is also dynamically computed at launch time like the secrete decryption key). Thanks to this signature made by the runtime system itself (which does not exclude modules to be also signed by certificate authorities), every time the runtime system loads a class from the CLASSPATH, it can then verify that it is an authorized class that it has itself installed. Thus, even if not physically protected against write operations, any attempt to modify the class files it has itself installed will be detected by the secure runtime system.

To detect any alteration of the secure runtime system, complementary security can be brought by the use of a smartcard device comparing the present state of the runtime before launching it with a (hash) snapshot of the legal one captured at installation time. Moreover, parts of the secrete keys could be more securely kept in the smartcard memory rather than on disk files.

The second modification is related to the management of the CLASSPATH.

With the present runtime system the CLASSPATH is an easily modifiable environment variable: it can be modified by user or by other programs before launching the runtime system. This is very dangerous, as any, and maybe untrusted, Java class you could think stored outside the scope of the CLASSPATH may dynamically become in its scope. To correct this weakness, the secure runtime system will have a fixed, well defined, maximal CLASSPATH whose content will be entirely under its own control. Every class stored outside the scope of this maximal CLASSPATH will always be treated as untrusted foreign code. The secure runtime system will never allow that two classes of the same package can be stored in different directories of the maximal CLASSPATH. And it will never allow that two subpackages of a same main package can be stored independently of each other (for instance, all the subpackages of a main package will be stored in the direct subdirectories of the unique directory assigned to this main package). In consequence, and contrarily to what is presently possible with current Java runtime systems, with the secure runtime system it will become impossible to mask or extend the classes of a previously installed package without modifying the content of the (unique) directory where its classes are directly stored.

The maximal CLASSPATH will be itself subdivided in several categories (corresponding to different main directories): SystemLibs, Trusted&SecureLibs, OtherLibs.

The secure runtime system will have a native class loader and security manager that will impose specific restrictions and protections to the classes of OtherLibs, and less drastic restrictions and protections to the classes of Trusted&SecureLibs. But, the native security manager will not forbid that Java applications can define their own security manager (of which security checks will be used in complement, and not instead, of those performed by the native security manager).

Local classes stored outside the maximal CLASSPATH, as well as foreign classes downloaded from a remote server, will never be allowed by the secure runtime system to be members of a package already present in the maximal CLASSPATH. This interdiction will be directly supported by the runtime system that will systematically add the name of their class loader to the name of the package of foreign classes, and will not rely, as it is presently the case, on an optional check performed by class loaders and security managers.

With these simple modifications that have just been briefly sketched above (and that will be more detailed in my complete forthcoming paper), the main weaknesses of the present Java runtime system will be avoided, and all the basic guaranties needed to install securely additional Java modules in the neighborhood of a Java program downloading foreign code will be provided by the secure runtime system itself.

Thanks to these basic guaranties that allow to avoid the circular interdependency of the Java module security, it will become possible to precisely define the notion of "intrinsically secure Java module" (i.e. self-protected against misuse) and it will also certainly become possible to verify the intrinsic security of Java modules on a rather automated basis with formal verification methods.




There are some additional remarks to my October 96 paper (Java Security: Weakenesses and Solutions) about Java and security. Once again, a lot of apologies for my bad english. Any suggestion, comment or critic welcome at Jean-Paul.Billon@dyade.fr


Since October 96, things have evolved. On a first hand, there is now a quickly growing set of third-party additional Java libraries currently available. Some of them are just about security, but seem to have been conceived without any understanding of the weaknesses I discuss in this paper. On the other hand, JavaSoft will certainly migrate during next months to a new security architecture (extended sandbox model with privilegiate signed applets and/or gateway model examplified by JECF), certainly much more elaborated than the sandbox model and with a much wider scope of security objectives. However, although it seems that now people at JavaSoft are becoming conscious of some of the security concerns I have presented (by emphasizing the fundamental role of the notion of package), it is still uncertain that the basic weaknesses of the Java runtime system I have discussed in this paper will be seriously reconsidered.

Let me emphasize a fundamental point: adding new Java APIs, or modifying existing ones, cannot be alone the right solution to those weaknesses. In the same way, switching to a new general architecture for security, and certainly, like the gateway model, a more elaborated one than the sanbox model, would be illusory if this was done only through the use of new Java libraries without any modification of the runtime system. As long as a certain number of basic guaranties are not directly provided by the kernel of the runtime system, any new security architecture would just be another "electronic Maginot line", or, in other words: a sandcastle!

The solutions I have briefly sketched in my paper are not related to a high level new security architecture: they are related to the reinforcement of the basic low level security architecture, reinforcement which is mandatory to securize any higher level security architecture that could be provided on the basis of dedicated Java APIs.

In my October paper, I pointed out the fundamental role of the notion of package in matter of security. On this point, people of JavaSoft are now rather on the same line. Let me cite Theodore Goldstein "[...] it is necessary to define few terms: rights and principals. [...] a right is an abstract privilege. A principal uses a right. A principal can be a person, a corporation, or a body of code. [...]. The Java sandbox is all-or-nothing because the security principal is the applet. [...]. Electronic commerce needs to identify a principal more precisely than the applet thread.[...]. Packages are a natural choice for creating a security principal. [...]. Packages are a natural source of protection." (Th. Goldstein, The Gateway Security Model in the Java Electronic Commerce Framework, p.10). In the same spirit, I can also cite designers of the JDK1.1 about inner-classes: "If an inner class C requires access to a private member m of an enclosing class T, the inserted access method for m opens up T to illegal access by any class K in the same package. There at present are no known security problems with such access methods, since it is difficult to misuse a method with package scope."

Those citations are interesting because they just sound like if the respect of package integrity was granted by the Java runtime system. But the most surprising weakness I have discussed in my October paper is precisely that it is not the case. For now (JDK 1.02 and apparently also JDK 1.1), a package is just a loose association of classes, and the classes of a same package can be loaded from different locations. And every package can be dynamically extended by new classes declaring themselves to be members of this package: even untrusted applets can declare themselves to be members of local packages if these ones are not explicitely protected (by the classloader and/or the security manager) from such redefinitions (the famous "separation of name spaces" provided by the class loaders does not forbid foreign applet classes to be members of local packages!).

So, it appears that people of JavaSoft have a contradictory discourse about packages: on one hand, the notion of package still denotes a loose association of classes, association without physical existence that could be rooted in the unicity of location, which means that package privacy is not systematically protected, while, on the other hand, the notion of package is presented illusorily as a natural source of protection that allows people designing the "inner-class" extension of the JDK 1.1 to design somewhat "dirty" things in what they believe to be a secure way as well as people designing the new security model of the JECF to design a clean and more accurate high level security model exclusively based on package rights and package membership, which is illusory as long as package integrity is not systematically granted.

This sounds like if there were two classes of people in JavaSoft: high-level security architects believing that packages actually provide a real protection (what packages should have to do!!!) and runtime system designers who have not considered this seriously and in consequence have not designed to implement any systematic protection of package integrity.

This kind of confusion, that leads to believe that packages are what they should have to be and not what they presently are, is not proper to JavaSoft. Other companies are now selling additional Java packages. Some of them are dedicated to security. For instance, Phaos technology sells SSLava, a set of Java packages dedicated to the implementation of the SSL protocol. On the client side, you can use these packages in a standard java-enabled browser class path, in order to run applets establishing securized connection with the remote server from which they come. The problem is that the prefix of the SSLava packages is not "java" or "sun" (those packages are systematically protected against package extension by foreign applets) but "crysec". As this package name is a priory unknown from browsers, any hostile applet could declare new classes in these packages and so access to secret ressources like private encryption keys that are stored in non-private (only "protected") attributes. In order to protect the privacy of those packages, it is necessary to add explicitely to the property file of the applet viewer that applets are not allowed to define classes in those packages. This is possible (for people aware of the problem...) when this file is accessible, which is the case with the applet viewer of the JDK 1.02 or HotJava. But it is not the case presently with Netscape Navigator 3 or Microsoft Internet Explorer 3.

Those examples reinforce the evidence that the kind of modifications to the Java runtime system I have sketched in my October paper is mandatory to provide a robust basis to any higher level security package or architecture based on Java libraries.