Running JBoss with a Java 2 Security Manager

• java.security.manager You use this option without any value to specify that the default security manager should be used. This is the preferred security manager. You can also pass a value to the java.security.manager option to specify a custom security manager implementation. The value must be the fully qualified classname of a subclass of java.lang.SecurityManager. This form specifies that the policy file should augment the default security policy, as configured by the VM installation.

• java.security.policy You use this option to specify the policy file that will augment the default security policy information for the VM. This option takes two forms: java.security.policy=policyFileURL and java.security.policy==policyFileURL. The first form specifies that the policy file should augment the default security policy, as configured by the VM installation. The second form specifies that only the indicated policy file should be used. The policyFileURL value can be any URL for which a protocol handler exists, or it can be a file path specification.

Both the run.bat and run.sh start scripts reference a JAVA_OPTS variable that you can use to set the security manager properties.

Enabling Java 2 security is the easy part. The difficult part of Java 2 security is establishing the allowed permissions. If you look at the server.policy file that is contained in the default configuration file set, you'll see that it contains the following permission grant statement:

grant {
    // Allow everything for now
    permission java.security.AllPermission;
};

This effectively disables security permission checking for all code because it says any code can do anything, which is not a reasonable default. What is a reasonable set of permissions is entirely up to you.

Table 8.1 lists the current set of JBoss-specific java.lang.RuntimePermissions that are required.

Table 8.1. Required JBoss-Specific java.lang.RuntimePermissions

TargetName	What the Permission Allows	Risks
org.jboss.security. SecurityAssociation. getPrincipalInfo	Access to the org.jboss.security. SecurityAssociation getPrincipal() and getCredentials() methods.	The ability to see the current thread caller and credentials.
org.jboss.security. SecurityAssociation. setPrincipalInfo	Access to the org.jboss.security. SecurityAssociation. setPrincipal() and setCredentials() methods.	The ability to set the current thread caller and credentials.
org.jboss.security. SecurityAssociation. setServer	Access to the org.jboss.security. SecurityAssociation setServer method.	The ability to enable or disable multithread storage of the caller principal and credential.
org.jboss.security. SecurityAssociation. setRunAsRole	Access to the org.jboss.security. SecurityAssociation pushRunAsRole and popRunAsRole methods.	The ability to change the current caller run-as role principal.

To conclude this discussion, here is a little-known tidbit on debugging security policy settings: You can set various debugging flags to determine how the security manager is using your security policy file as well as what policy files are contributing permissions. Running the VM as follows shows the possible debugging flag settings:

[bin]$ java -Djava.security.debug=help

all           turn on all debugging
access        print all checkPermission results
combiner      SubjectDomainCombiner debugging
jar           jar verification
logincontext  login context results
policy        loading and granting
provider      security provider debugging
scl           permissions SecureClassLoader assigns

The following can be used with access:

stack     include stack trace
domain    dumps all domains in context
failure   before throwing exception, dump stack
          and domain that didn't have permission

Note: Separate multiple options with a comma

Running with -Djava.security.debug=all provides the most output, but the output volume is torrential. This might be a good place to start if you don't understand a given security failure at all. A less verbose setting that helps debug permission failures is -Djava.security.debug=access,failure. This is still relatively verbose, but it's not nearly as bad as the all mode because the security domain information is displayed only on access failures.