Using the Java security manager with Contelligent

Spotlight January 2006, by Marcus Rating

Contelligent 9 allows you to fully utilize the Java security manager mechanism to restrict access of deployed code to your system. This article explains the available configuration mechanisms.

Table of Contents

1) Introduction and Requirements
2) Activating the security manager
3) Package policies
4) Custom privileges
5) Feedback

Print version


1) Introduction and Requirements

Contelligent allows you deploy functionality packages from several sources into a single environment. This soon leads to the question of whether you trust the vendor of a certain package enough to have their code run on your production system.

Fortunately, Java already contains advanced mechanisms to both isolate code from sensitive parts of your system (the classical 'sandbox') and to assign different privileges to certain groups of code. Among the many things that can be restricted are file access, network access, executing system commands and certain powerful Java features like custom classloaders that could be used to override access checks.

An introduction by Sun into the available basic permissions built into the JDK is available at http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html

To allow for a more secure environment, Contelligent allows you to easily assign a distinct set of privileges to each deployed package. This document will show you how to use this to make your Contelligent installation more secure.

In order to configure your Contelligent installation to use the security manager, you will need to meet the following requirements: (Note that the specified minimum versions are important!)

  • Contelligent 9.0.25 or newer
  • Java 1.4.2 or newer 1.4 release (Java 1.5 is not yet supported)

The target audience of this document are developers and administrators with a basic knowledge of Java, since an understanding of concepts like a call stack is necessary. Also, knowledge of Contelligent administration basics like packages and editing configuration files is required.

All examples and paths are for a setup consisting of Contelligent installed on JBoss 3.2.6 application server.


2) Activating the security manager

The Java security manager can only be activated for the whole Java virtual machine (JVM). To do so, you will have to add two parameters to your Contelligent server startup script. (Note that the Jboss installation bundled with the Contelligent installer for Windows already has the security manager enabled, starting with release 9.0.25)

The necessary parameters are: "-Djava.security.manager=default" to enable the security manager and "-Djava.security.policy=./server.policy" to select a policy file. Note that using a policy file is necessary, since otherwise your application server will be unable to do even basic setup like reading its configuration files and opening a network socket.

A simple policy file for a normal JBoss installation might be as follows, if it is placed in the "jboss/bin" directory:

grant codebase "file:${java.home}/-" {
   permission java.security.AllPermission;
};

grant codebase "file:../-" {
   permission java.security.AllPermission;
};

This allows code inside Java itself and in the JBoss directory (specified by the relative path in the second block) to run with full privileges, just as if the security manager were not enabled at all. Note that the "contelligent.ear" file containing the core Contelligent code will also be given full privileges this way, since it is deployed under the JBoss directory. This is as it should and will not affect the packages.


3) Package policies

Once the security manager has been activated, Contelligent will assign a set of privileges to each class loaded from a package. Which privileges are assigned is determined by the project configuration files in the contelligent config directory.

If you take a look at the default "project.xml" that comes with Contelligent, you will find a series of blocks like the following:

<policy packagePrefix="contelligent.query">
   <permission
      type="java.net.SocketPermission"
      name="*"
      actions="connect,accept,resolve"/>
</policy>

This grants network access to code in the query package, which is necessary for the remote query functionality in there. If this block were not defined, the system would throw an exception as soon as the query package tried to access the network. A policy block may contain as many different permission elements as needed.

Note also that the topmost policy element in the file has an empty package prefix set. This means that the permissions defined in there are applied to all packages, since policy blocks apply to all packages whose names start with the specified package prefix.


4) Custom permissions

In addition to the standard permissions defined by Java, Contelligent also has checks for two new RuntimePermissions with the names of "getSystemUser" and "doAsSystem", both related to the Contelligent system user.

While "getSystemUser" allows to retrieve the user object, the "doAsSystem" permission allows to run a section of code as the system user through the doAsSystem method on the CallData object, overriding all user specific access checks. Needless to say, this permission should not be granted to any code that is not fully trusted with administrative access to all data within Contelligent.


5) Feedback

Feel free to contact support@contelligent.de if you have any questions or want to provide some feedback.