The RMI Dynamic ClassLoading Service

There is a simple http service that supports requests for classes for RMI dynamic class loading, org.jboss.web.WebService. The configurable attributes for the WebService MBean service are as follows:

• Port: the WebService listening port number. A port of 0 will use any available port.

• Host: Set the name of the public interface to use for the host portion of the RMI codebase URL.

• BindAddress: the specific address the WebService listens on. This can be used on a multi-homed host for a java.net.ServerSocket that will only accept connect requests to one of its addresses.

• Backlog: The maximum queue length for incoming connection indications (a request to connect) is set to the backlog parameter. If a connection indication arrives when the queue is full, the connection is refused.

• DownloadServerClasses: A flag indicating if the server should attempt to download classes from the thread context class loader when a request arrives that does not have a class loader key prefix.

• DownloadResources (4.0.3+) : A flag indicating if the server should attempt to download non .class file resources using the from thread context class loader. Note that this is generally a security risk as it allows access to server configuration files which may contain security settings.

• ThreadPool (4.0.2+): The org.jboss.util.threadpool.BasicThreadPoolMBean instance thread pool used for the WebServer class loading. Typically this is used with the mbean service dependency injection syntax as shown in the example configuration.

An example mbean service descriptor fragment is:

   <mbean code="org.jboss.web.WebService"
      name="jboss:service=WebService">
      <attribute name="Port">8083</attribute>
      <!-- Should non-EJB .class files be downloadable -->
      <attribute name="DownloadServerClasses">true</attribute>
      <!-- Should resources other than .class files be downloadable. Both
         DownloadServerClasses and DownloadResources must be true for resources
         to be downloadable. This is false by default because its generally a
         bad idea as server configuration files that container security
         information can be accessed.
       -->
      <attribute name="DownloadResources">false</attribute>
      <attribute name="Host">${jboss.bind.address}</attribute>
      <attribute name="BindAddress">${jboss.bind.address}</attribute>
      <!-- Use the default thread pool for dynamic class loading -->
      <depends optional-attribute-name="ThreadPool"
         proxy-type="attribute">jboss.system:service=ThreadPool</depends>
  </mbean>

If the MBean is created, it calculates an URL based on the Host and Port attribute. (If no Host atribute was given it tries to use the java.rmi.server.name system property or the local hostname otherwise. This calculated URL will be stored into the java.rmi.server.codebase attribute. (One user of this attribute is for example the exported JNDI server stub).

Securing the RMI Dynamic ClassLoading Service

The DownloadResources setting should certainy be false if you have any concern about leaking information through this server. Beyond that, one step in increasing the security is to set DownloadServerClasses to false so that only ejb deployment classes are available for download. Another is to use an anonymous port so that access is not via a well know port as a security by obscurity measure.

Removing the RMI Dynamic ClassLoading Service

Removal of the WebService altogether is certainly the best security step if you want to limit access points. You need to remove the mbean definition from jboss-server.xml and also remove the dependency of the EJB Deployer:

   <!-- EJB deployer, remove to disable EJB behavior-->
   <mbean code="org.jboss.ejb.EJBDeployer" name="jboss.ejb:service=EJBDeployer">
      ...
      <!-- depends optional-attribute-name="WebServiceName">jboss:service=WebService</depends -->
   </mbean>

Secure Using a Tomcat (or another webserver) for dynamic classloading

You can take complete control of what resources/classes are available for dynamic class loading by deploying only the classes you want to expose for dynamic classloading in a war file, e.g. remoteclasses.war to a standalone tomcat or webserver. You then tell RMI to use this address as the codebase for dynamic classloading when starting JBoss, e.g.

./run.sh -Djava.rmi.server.codebase=http://hostname:8080/remoteclasses

You should of cause also remove the WebService MBean as described above.

Referenced by: