rmid exec policies for Jini^TM technology

Introduction and Rationale

The RMI activation daemon, rmid, executes subprocesses which run Java^TM virtual machines (JVMs*). It does this to keep activation groups separate from one another, and to allow the use of special VM engines and options for different activation groups.

The ActivationGroupDesc structure, which affects the subprocess environment, command, and command options and arguments, is flexible enough that with an insecure security policy, any command can be run, even a non-Java-platform command or program. There is clearly a need for a security control to prevent unauthorized specification of a ActivationGroupDesc.

In releases of the Java 2 SDK prior to 1.2.2_006, this need to control security was satisfied by the same stopgap measure used for rmiregistry access control: if the caller was running on the same host as the remote object, then all access was allowed; otherwise, no access to sensitive functions was allowed. Registering or changing an ActivationGroupDesc is an example of a sensitive function; activating an object is an example of a non-sensitive function that anyone can perform. This security mechanism was predicated on the assumption that unprivileged code is not allowed to connect to port 1098 on the executing host.

However, that assumption is no longer as certain, and a stronger security model has been developed. In this new model, an extra security control has been added: before being executed, the command and options requested by an ActivationGroupDesc are checked by the security manager of rmid, which then references the security policy file that was set for rmid from the command line (for authorization).

An "exec policy" is a Java class employed by the RMI activation daemon to check commands and command-line options used to launch a JVM when deciding whether or not an ActivationGroupDesc is authorized. The exec policy is adopted when rmid is started. The value of the sun.rmi.activation.execPolicy property dictates the policy that rmid uses to determine whether or not the information in an ActivationGroupDesc may be used to launch a JVM for an activation group. Some exec policies are built in to rmid, and rmid can be instructed to use one of them by defining a property that specifies a built-in policy instead of the exec policy's class name.

In the exec policy represented by the value none (discussed later, in the section, How to achieve the behavior of rmid released in previous versions of the Java 2 SDK), the new security control is disabled, and execution is compatible with the rmid found in previous releases of the Java 2 SDK.

In the default exec policy (discussed in the section, How to assign and maintain security controls), the authorized commands and options are encoded in the security policy file, which gets set using the "-J-Djava.security.policy=..." option on the rmid command line. Each command and option string in each ActivationGroupDesc is separately authorized or unauthorized. While there is no authentication of a caller (an authorized option is authorized for everyone's use), there is still a check to ensure that the registration of the ActivationGroupDesc originates from the local host.

The exec policy can be set to the name of another class which rmid will instantiate; the exec policy object will then be expected to perform the security check on ActivationGroupDescs at group activation time. This option is the most flexible, but discussion of its use is beyond the scope of this document. See the rmid tool documentation (manpage) for details, at:

     http://java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/rmid.html

     http://java.sun.com/products/jdk/1.3/docs/tooldocs/win32/rmid.html

How to achieve the behavior of rmid released in previous versions of the Java 2 SDK

The new security control can be effectively bypassed by assigning an exec policy which permits all commands and all options. There is a short way to specify this behavior by setting the exec policy value to none:

   rmid -J-Dsun.rmi.activation.execPolicy=none

For the user who can control the rmid host to guarantee the assumptions of Java 2 SDK, v1.2.x, or who is simply impatient with the new security control, the none keyword is a convenient way to get rmid up and running quickly. Remember that this is a way to sacrifice security for temporary convenience, and therefore is not recommended.

How to assign and maintain security controls

The default exec policy is used if the sun.rmi.activation.execPolicy system property is not set for the rmid tool, or if the value of the execPolicy property is set to default. In this case, a security policy file must be specified on rmid's command line.

In the default case, the java.security.policy system property must be set for rmid. For example:

   rmid -J-Djava.security.policy=C:\example\rmid.policy

The file named as the value of this property should contain a Java 2 platform security policy file. An example which has appropriate syntax for the Microsoft Windows platform is:

   grant {
     // permissions granted to everyone
     permission com.sun.rmi.rmid.ExecPermission "C:\\jdk\\bin\\java_g";
     permission com.sun.rmi.rmid.ExecOptionPermission "-Djava.security.policy=C:\\jini1_0_1\\example\\lookup\\policy";
   };

The two permission types shown above, ExecPermission and ExecOptionPermission, are the only two security permissions relevant to the new security control. Notice that they are granted to all codebases (grant {): you should always be cautious when granting permissions to all codebases, because they are the permissions granted to unknown downloaded code. See the rmid reference pages for a complete description of the syntax for these permissions.

The straightforward way to build up an effective rmid.policy is:

1. Start with an empty rmid.policy.
2. Run rmid -J-Djava.security.policy=rmid.policy.
3. Run a client program to activate an object (you might need to register the object if you haven't already).
4. Catch and printStackTrace the AccessControlException that gets thrown by the activation attempt (usually the client program will do this anyway).
   

   Note on restartable Activatable objects: Some activatable objects are activated automatically by rmid (if ActivationDesc.getRestartMode() is true); in this case, rmid will printStackTrace the exception to its System.err, preceded by the English-language message "rmid: unable to restart service".

5. Look in the AccessControlException to see the failed exception. For example, the exception:

   java.security.AccessControlException: access denied (com.sun.rmi.rmid.ExecOptionPermission -cp)

   means that the permission you need to add to the security policy file is:

      grant {
        permission com.sun.rmi.rmid.ExecOptionPermission "-cp";
      };
   

6. Kill the rmid process (rmid -stop) and return to step b.

Specific examples for some Jini technology-enabled service implementations

Here's an example of an rmid.policy which will run Reggie (the contributed Jini lookup service implementation) in the Solaris^TM operating environment:

  grant {
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Djava.security.policy=/files/jini1_0_1/example/lookup/policy";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Djava.rmi.server.codebase=*";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-cp";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "/files/jini1_0_1/lib/reggie.jar";
  };

Here's an example to run Mahalo (the contributed Jini transaction manager service implementation) in the Solaris operating environment:

  grant {
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Djava.security.policy=/files/jini1_0_1/example/txn/policy";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Djava.rmi.server.codebase=*";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-cp";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "/files/jini1_0_1/lib/mahalo.jar";
  };

Here's one for FrontEndSpace (a contributed implementation of JavaSpaces technology) in the Solaris operating environment:

  grant {
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Djava.security.policy=/files/jini1_0_1/example/books/policy";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Djava.rmi.server.codebase=*";
    permission com.sun.rmi.rmid.ExecOptionPermission
	       "-Xbootclasspath/p::/files/jini1_0_1/lib/outrigger.jar:/files/jini1_0_1/lib/transient-outrigger.jar:/files/jini1_0_1/lib/pro.zip";
  };

Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.