By default, the JBoss server does not start with a Java 2 security manager. If you want to use Java 2 permissions to restrict code privileges, you need to configure the JBoss server to run under a security manager. You do this by configuring the Java VM options in the run.bat or run.sh scripts in the JBoss server distribution bin directory. There are two required VM options:
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.
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. |