JBoss.orgCommunity Documentation
To restrict code privileges using Java permissions, you must configure the JBoss server to run under a security manager. This is done by configuring the Java VM options in the run.conf
in the JBoss server distribution bin directory. The two required VM options are as follows:
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.
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 a JAVA_OPTS
variable specified in run.conf
(Linux) or run.conf.bat
(Windows) that sets the required security manager properties.
The next element of Java security is establishing the allowed permissions. If you look at the $JBOSS_HOME/bin/server.policy.cert
file that is contained in the default configuration file set you will notice it contains the following grant statement:
grant signedBy "jboss" {
permission java.security.AllPermission;
};
This statement declares that all code signed by JBoss is trusted. To import the public key to your keystore, follow Activate Java Security Manager
Carefully consider what permissions you grant. Be particularly cautious about granting java.security.AllPermission
: you can potentially allow changes to the system binary, including the JVM runtime environment.
The current set of JBoss specific java.lang.RuntimePermissions
are described below.
org.jboss.security.SecurityAssociation.getPrincipalInfo
Provides access to the org.jboss.security.SecurityAssociation getPrincipal()
and getCredential()
methods. The risk involved with using this runtime permission is the ability to see the current thread caller and credentials.
org.jboss.security.SecurityAssociation.getSubject
Provides access to the org.jboss.security.SecurityAssociation getSubject()
method.
org.jboss.security.SecurityAssociation.setPrincipalInfo
Provides access to the org.jboss.security.SecurityAssociation setPrincipal()
, setCredential()
, setSubject()
, pushSubjectContext()
, and popSubjectContext()
methods. The risk involved with using this runtime permission is the ability to set the current thread caller and credentials.
org.jboss.security.SecurityAssociation.setServer
Provides access to the org.jboss.security.SecurityAssociation setServer
method. The risk involved with using this runtime permission is the ability to enable or disable multithread storage of the caller principal and credential.
org.jboss.security.SecurityAssociation.setRunAsRole
Provides access to the org.jboss.security.SecurityAssociation pushRunAsRole
and popRunAsRole
, pushRunAsIdentity
and popRunAsIdentity
methods. The risk involved with using this runtime permission is the ability to change the current caller run-as role principal.
org.jboss.security.SecurityAssociation.accessContextInfo
Provides access to the org.jboss.security.SecurityAssociation accessContextInfo, "Get"
and accessContextInfo, "Set"
methods, allowing you to both set and get the current security context info.
org.jboss.naming.JndiPermission
Provides special permissions to files and directories in a specified JNDI tree path, or recursively to all files and subdirectories. A JndiPermission consists of a pathname and a set of valid permissions related to the file or directory.
The available permissions include: bind
, rebind
, unbind
, lookup
, list
, listBindings
, createSubcontext
, and all
.
Pathnames ending in /*
indicate the specified permissions apply to all files and directories of the pathname. Pathnames ending in /-
indicate recursive permissions to all files and subdirectories of the pathname. Pathnames consisting of the special token <<ALL BINDINGS>>
matches any file in any directory.
org.jboss.security.srp.SRPPermission
A custom permission class for protecting access to sensitive SRP information like the private session key and private key. This permission doesn't have any actions defined. The getSessionKey target provides access to the private session key resulting from the SRP negotiation. Access to this key will allow you to encrypt and decrypt messages that have been encrypted with the session key.
org.hibernate.secure.HibernatePermission
This permission class provides basic permissions to secure Hibernate sessions. The target for this property is the entity name. The available actions include: insert, delete, update, read, * (all).
org.jboss.metadata.spi.stack.MetaDataStackPermission
Provides a custom permission class for controlling how callers interact with the metadata stack. The available permissions are: modify
(push/pop onto the stack), peek
(peek onto the stack), and *
(all).
org.jboss.config.spi.ConfigurationPermission
Secures setting of configuration properties. Defines only permission target names, and no actions. The targets for this property include: <property name> - property which code has permission to set; * - all properties.
org.jboss.kernel.KernelPermission
Secures access to the kernel configuration. Defines only permission target names and no actions. The targets for this property include: access - access the kernel configuration; configure - configure the kernel (access is implied); * - all of the above.
org.jboss.kernel.plugins.util.KernelLocatorPermission
Secures access to the kernel. Defines only permission target names and no actions. The targets for this property include: kernel - access the kernel; * - access all areas.
Procedure 11.1. Activate Java Security Manager
Follow this procedure to correctly configure the JSM for secure, production-ready operation. This procedure is only required while configuring your server for the first time. In this procedure, $JAVA_HOME
refers to the installation directory of the JRE.
Import public key to keystore
Execute the following command:
[home]$ sudo $JAVA_HOME/bin/keytool -import -alias jboss -file JBossPublicKey.RSA -keystore $JAVA_HOME/jre/lib/security/cacerts
C:\> %JAVA_HOME%\bin\keytool -import -alias jboss -file JBossPublicKey.RSA -keystore %JAVA_HOME%\jre\lib\security\cacerts
Verify key signature
Execute the following command in the terminal.
The default JVM Keystore password is changeit
.
$ keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries jboss, Aug 12, 2009, trustedCertEntry, Certificate fingerprint (MD5): 93:F2:F1:8B:EF:8A:E0:E3:D0:E7:69:BC:69:96:29:C1 jbosscodesign2009, Aug 12, 2009, trustedCertEntry, Certificate fingerprint (MD5): 93:F2:F1:8B:EF:8A:E0:E3:D0:E7:69:BC:69:96:29:C1
Specify additional JAVA_OPTS
Ensure the following block is present in the $JBOSS_HOME/server/$PROFILE/run.conf
file.
## Specify the Security Manager options JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==$DIRNAME/server.policy.cert -Djava.protocol.handler.pkgs=org.jboss.handlers.stub -Djava.security.debug=access:failure -Djboss.home.dir=$DIRNAME/../ -Djboss.server.home.dir=$DIRNAME/../server/default/"
Placing run.conf
into the target profile directory will mean the file overrides any other run.conf
files outside server profiles.
Ensure the following block is present in the $JBOSS_HOME\bin\run.conf.bat
file.
rem # Specify the Security Manager options set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.manager -Djava.security.policy==%DIRNAME%\server.policy.cert -Djava.protocol.handler.pkgs=org.jboss.handlers.stub -Djava.security.debug=access:failure -Djboss.home.dir=%DIRNAME%/../ -Djboss.server.home.dir=%DIRNAME%/../server/default/"
Start the server
Start JBoss using the run.sh
or run.bat
(Windows) script.
A number of Java debugging flags are available to assist you in determining how the security manager is using your security policy file, and 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 configfile JAAS ConfigFile loading configparser JAAS ConfigFile parsing gssloginconfig GSS LoginConfigImpl 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 dump all domains in context failure before throwing exception, dump stack and domain that didn't have permission The following can be used with stack and domain: permission=<classname> only dump output if specified permission is being checked codebase=<URL> only dump output if specified codebase is being checked
Running with -Djava.security.debug=all
provides the most output, but the output volume is acutely verbose. This might be a good place to start if you don't understand a given security failure at all. For less verbose output that will still assist with debugging permission failures, use -Djava.security.debug=access,failure
.