Comparison with Previous Releases

The security manager has existed in every release of Java. In Java 1.0 and 1.1, the security manager is the only thing that affects the security policy of the program. Because there is no way to install a default security manager via the command line prior to Java 2, most Java 1.0 and 1.1 applications do not have a security manager. In addition, the implementation of the security manager between 1.1-based browsers varies in important aspects between different browser vendors. Even though some browser vendors claim to support the Java 2 platform, they still implement their own security manager rather than using the permission and policy-based default security manager.

We’ll discuss many of the major differences here. In addition, in Appendix D, we’ll show how a security manager could be implemented in order to specify a policy for applications run in 1.1.

Trusted and Untrusted Classes

The default notion of what constitutes a trusted class has changed significantly between releases of Java:

  • In Java 1.0, a class that is loaded from the classpath is considered trusted and a class that is loaded from a class loader is considered untrusted.

  • In Java 1.1, the same rule applies but a class that is loaded from a jar file may carry with it a digital signature that allows it to be given extra privileges. These privileges are typically all-or-nothing: if you trust the entity that signed the jar file, then that code can do anything it wants. Some browser vendors have extended that behavior using proprietary APIs.

  • In Java 2, only classes in the core API are considered trusted. Other classes must be given explicit permission to perform the operations we’ve discussed.

Differences in the Security Manager Class

In 1.1, the setSecurityManager( ) method can only be called once, and once installed, the security manager cannot be removed. Attempting to call this method after a security manger has already been installed will result in a SecurityException.

File access

While 1.1-based browsers like Netscape Navigator 4 and earlier, Internet Explorer, and HotJava all have a default policy that prevents untrusted classes from all file access, some of them allow the user to configure a different policy. HotJava and the appletviewer , for example, allow the user to create a set of directories in which applets can read and write files, and some versions of Internet Explorer allow the user to grant file access to all untrusted classes.

Network access

There was a change in the default security policy supplied in 1.0 and in 1.1 with respect to untrusted classes and server sockets (either instances of class ServerSocket or datagram sockets that received data from any source). In 1.0, untrusted classes were typically not allowed to create a server socket at all, which meant that the checkListen( ) and checkAccept( ) methods always threw a security exception when an applet attempted such an operation. In 1.1 and later, untrusted classes are allowed to create a server socket so long as the port number of that socket is greater than the privileged port number on the machine (typically 1024). Note too that the receive( ) method of the DatagramSocket class in Java 2 now calls the checkAccept( ) rather than the checkConnect( ) method.

Sun’s 1.1-based browsers (HotJava and appletviewer) and some versions of Internet Explorer allow you to configure them so that untrusted classes can connect to any host on the network.

System access

In 1.1, attempts to redirect the standard input, output, and error streams call the checkExec() method rather than the checkPermission( ) method. In fact, the checkPermission( ) method does not exist at all in 1.1 and earlier releases.

Thread access

Thread access policy by appletviewer and popular browsers in 1.0 and 1.1 is, simply put, very confusing.

In 1.1, by default each applet is given an individual thread group, and the threads within that group can manipulate other threads within that group without respect to any additional hierarchy.

The getThreadGroup( ) method is only present in Java 1.1 and subsequent releases. In Java 1.0 (and browsers built on that release), thread security was generally nonexistent: any thread could manipulate the state of any other thread, and applets weren’t able to create their own thread groups.

Security access

1.1 implements all of the security checks that were listed earlier; in addition, the following methods also call the checkSecurityAccess( ) method: Identity.toString( ) , Security.getProviders( ), Security.getProvider( ), and Security.getProperty( ). However, since most browsers (including Netscape Communicator 4.x and Internet Explorer 4.x) do not implement the standard security package at all, none of these checks are performed in those browsers.

Get Java Security, 2nd Edition now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.