current protection domain must carry a runtime permission with the name setFactory
. The instances where these methods are used and the rationale for such uses are shown in Table 4−2.
Table 4−2. Security Manager Methods to Protect Network Access
Method Called By
Rationale
checkConnect DatagramSocket.send
DatagramSocket.receive Deprecated
MulticastSocket.send Socket
Test if the untrusted class can create a client−side connection.
checkConnect DatagramSocket.getLocalAddress
InetAddress.getHostName InetAddress.getLocalHost
InetAddress.getAllByName
Test if the untrusted class can see any hosts on the local network.
checkListen DatagramSocket
MulticastSocket ServerSocket
Test if the untrusted class can create a server−side socket.
checkMulticast DatagramSocket.send
DatagramSocket.receive MulticastSocket.send
MulticastSocket.receive MulticastSocket.joinGroup
MulticastSocket.leaveGroup
Test if the untrusted class can operate on a multicast socket.
checkAccept ServerSocket.accept
DatagramSocket.receive
Test if the untrusted class can accept a server connection.
checkSetFactory ServerSocket.setSocketFactory
Socket.setSocketFactory URL.setURLStreamHandlerFactory
URLConnection.setContentHandlerFactory RMI.setSocketFactory
Test if the untrusted class can alter the manner in which all sockets are created. checkSetFactory
HttpURLConnection.setFollowRedirects
Test if the untrusted class can change redirection behavior. Some notes are in order. As in the case with file access, these methods sometimes check operations that are
logically different from a programming view but are essentially the same thing from a system view. Hence, the
checkConnect method not only checks the opening of a socket but also the retrieval of hostname
or address information on the theory that to know the name of a host, you need to be able to open a socket to that host. This last test may seem somewhat odd −− under what circumstances, you might wonder, should an
untrusted class not be able to know the name or address of the machine on which it is running? Recall that we want to prevent the outside world from knowing our network topology; this includes the name and address of
the users machine as well.
[3]
[3]
On the other hand, theres a good chance the outside web server already has that information, since our browser sent along a hostname and other information when it retrieved
the file to begin with. If our request passed through a firewall or proxy server, theres a chance that some of this information was prevented from passing to the outside web server, but thats
not necessarily the case either.
The checkSetFactory
method of the security manager class is responsible for arbitrating the use of several low−level aspects of Javas network classes. Most of the tests made by this method have to do with
whether or not the untrusted class is allowed to create some variety of socket factory. Socket factories are classes that are responsible for creating sockets that implement a particular interface while having a
nonstandard feature. For instance, you could use a socket factory to provide sockets that always perform encryption. Predictably, untrusted classes cannot change the socket factory in use.
This method is also used to determine whether the Java program will automatically follow redirect messages when opening a URL. When a Java program opens a URL, the server to which it is connected may send back
a redirect response an HTTP response code of 3xx. Often, browsers follow these redirects transparently to the user; in Java, the programmer has the ability to determine if the redirection should automatically be
followed or not. An untrusted class is not able to change whether redirection is on or off. The
HttpURLConnection class that uses this method is abstract, so the actual behavior of this class may be
overridden in a particular implementation.
4.3.3 Methods Protecting the Java Virtual Machine
There are a number of methods in the SecurityManager
class that protect the integrity of the Java virtual machine and the security manager. These methods fence in untrusted classes so that they cannot circumvent
the protections of the security manager and the Java API itself. These methods are summarized in Table 4−3. Chapter 4. The Security Manager
Table 4−3. Security Manager Methods Protecting the Virtual Machine
Method Called By
Rationale
checkCreateClassLoader ClassLoader
Class loaders are protected since they provide information to the security manager.
checkExec Runtime.exec
Other processes might damage the users machine.
checkLink Runtime.load
Runtime.loadLibrary
Dont let untrusted code import native code.
checkExit Runtime.exit
Dont let untrusted code halt the virtual machine.
checkExit Runtime.runFinalizersOnExit
Dont let untrusted code change whether finalizers are run.
checkPermission
Many See if the current thread has been granted a particular permission.
public void checkCreateClassLoader The distinction we keep mentioning between trusted and untrusted classes is often based on the
location from which the class was loaded. As a result, the class loader takes on an important role since the security manager must ask the class loader where a particular class came from. The class loader is
also responsible for marking certain classes as signed classes. Hence, an untrusted class is typically not allowed to create a class loader. This method is only called by the constructor of the
ClassLoader class: if you can create a class loader or if you obtain a reference to a previously
created class loader, you can use it. To succeed, the current protection domain must have a runtime permission with the name
createClassLoader .
public void checkExecString cmd This method is used to prevent execution of arbitrary system commands by untrusted classes −− an
untrusted class cannot, for example, execute a separate process that removes all the files on your disk.
[4]
To succeed, the current protection domain must have a file permission with a name that matches the given command and an action of execute.
[4]
The separate process would not need to be written in Java, of course, so there would be no security manager around to enforce the prohibition about deleting files.
public void checkLinkString lib System commands arent the only code that is out of reach of the security manager −− any native C
language code that is executed by the virtual machine cannot be protected by the security manager or, in fact, by any aspect of the Java sandbox. Native code is executed by linking a shared library
into the virtual machine; this method prevents an untrusted class from linking in such libraries.
It may seem as if this check is very important. It is, but only to a point: the programmatic binding from Java to C is such that Java code cannot just call an arbitrary C function −− the C function must
have a very specialized name that will not exist in an arbitrary library. So any C function that the untrusted class would like to call must reside in a library that youve downloaded and placed on your
machine −− and if the programs author can convince you to do that, then you dont really have a secure system anyway and the author could find a different line of attack against you.
To succeed, the current protection domain must have a runtime permission with the name loadLibrary.lib
. public void checkExitint status
Next, there is the continuing processing of the virtual machine itself. This method prevents an untrusted class from shutting down the virtual machine. This method also prevents an untrusted class
from changing whether or not all finalizers are run when the virtual machine does exit. This means that an untrusted class −− and in particular, an applet −− cannot guarantee that all the finalize methods
of all the objects will be called before the system exits which cannot be guaranteed in any case, since the browser can be terminated from the operating system without an opportunity to run the finalizers
anyway.
When you install a security manager via the command−line argument, all code trusted or not is able to exit the virtual machine. In the
appletviewer or the Java Plug−in, the current protection
domain must have the runtime permission named exitVM
in order for this call to succeed. public void checkPermissionPermission p
public void checkPermissionPermission p, Object context Check to see if the current thread has the given permission. This method is used when you write your
own permission classes, as well examine in Chapter 5. It is also used directly by the Java API when it Chapter 4. The Security Manager
