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.
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.
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.
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.
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.
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 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.
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 the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
