Java Reference
In-Depth Information
Running Untrusted Code
Recall the
Server
example of Chapter 5,
Networking
. That generic server class
dynamically loaded and ran
Service
implementations. Suppose that you are a sys-
tem administrator in charge of the
Server
program, and that you don't trust the
programmers who are developing the
Service
implementations; you're afraid that
they'll accidentally (or maliciously) include damaging code in their
Service
classes. Java makes it easy to run these untrusted classes with access-control
mechanisms in place, to prevent them from doing anything they shouldn't.
Access control in Java is performed by the
SecurityManager
and
AccessCon-
troller
classes. When a security manager has been registered, Java checks with it
every time it is asked to perform any operation, such as reading or writing a file or
establishing a network connection, that might be restricted. In Java 1.2 and later,
the
SecurityManager
class uses the
AccessController
class to perform these
access-control checks, and the
AccessController
in turn refers to a
Policy
file
that describes exactly what
Permission
objects are granted to what code.
As of Java 1.2, it is quite simple to run code under the watchful eye of a security
manager. Simply run the Java interpreter using the
-D
option to set the
java.secu-
rity.manager
property. For example, to run the
Server
class under a security
manager, start it like this:
% java -Djava.security.manager com.davidflanagan.examples.net.Server \
-control password 4000
When you do this, both the
Server
class and the control service class it loads are
subject to the access-control checks of a security manager that uses the system's
default security policy.
If you try running
Server
using the default security policy shipped by Sun, the
server will fail when the first client attempts to connect to it, and you'll see the fol-
lowing message:
java.security.AccessControlException:
access denied (java.net.SocketPermission 127.0.0.1:1170 accept,resolve)
This message tells you that the security manager has not allowed your
Server
class to accept a network connection from the client. The reason is that the default
security policy is too restrictive for our server. Fortunately, there is an easy way to
allow the server to accept connections. Create a file with the following contents
(except replace the directory name with the name of the directory where you have
your classes installed) and name it
Server.policy
:
// These lines grant permissions to any code loaded from the directory shown.
// Edit the directory to match the installation on your system.
// On Windows systems, change the forward slashes to double backslashes: "\\".
grant codeBase "file:/home/david/Books/JavaExamples2/Examples" {
// Allow the server to listen for and accept network connections
// from any host on any port > 1024
permission java.net.SocketPermission "*:1024-", "listen,accept";
};
Once you've created the
Server.policy
file, run the server class again but add
another
-D
option to specify that the interpreter should use this policy file: