JBoss.org Community Documentation
By default the JBoss server does not start with a Java 2 security manager. If you want to restrict privileges of code using Java 2 permissions you need to configure the JBoss server to run under a security manager. This is done by configuring the Java VM options in the run.bat
or run.sh
scripts in the JBoss server distribution bin directory. The two required VM options are as follows:
java.security.manager
: This is used 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 class name 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
: This is used 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 a file path specification.
Both the run.bat
and run.sh
start scripts reference an JAVA_OPTS variable which 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 as 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.
The current set of JBoss specific java.lang.RuntimePermissions
that are required include:
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. There are various debugging flag that you can set 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 to use -Djava.security.debug=access,failure
. This is still relatively verbose, but not nearly as bad as the all mode as the security domain information is only displayed on access failures.