The Java™ 2 Platform, Enterprise Edition (J2EE) Version 1.3 and later specifications have a well-defined programming model of responsibilities between the container providers and the application code. Using Java 2 security manager to help enforce this programming model is recommended. Certain operations are not supported in the application code because such operations interfere with the behavior and operation of the containers. The Java 2 security manager is used in the product to enforce responsibilities of the container and the application code.
This product provides support for policy file management. A number of policy files in the product are either static or dynamic. Dynamic policy is a template of permissions for a particular type of resource. No relative code base is defined in the dynamic policy template. The code base is dynamically calculated from the deployment and run-time data.
Policy file | Location |
---|---|
java.policy |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy. The java.policy file is used throughout the system. Do not edit this file. |
server.policy | profile_root/properties/server.policy. Default permissions are granted to all the product servers. |
client.policy | profile_root/properties/client.policy. Default permissions are granted for all of the product client containers and applets on a node. |
Policy file | Location |
---|---|
spi.policy | profile_root/config/cells/cell_name This template is for the Service Provider Interface (SPI) or the third-party resources that are embedded in the product. Examples of SPI are the Java Message Service (JMS) in MQ Series and Java database connectivity (JDBC) drivers. The code base for the embedded resources are dynamically determined from the configuration (resources.xml file) and run-time data, and permissions that are defined in the spi.policy files are automatically applied to these resources and JAR files that are specified in the class path of a resource adapter. The default permission of the spi.policy file is java.security.AllPermissions. |
library.policy | profile_root/config/cells/cell_name/nodes This template is for the library (Java library classes). You can define a shared library to use in multiple product applications. The default permission of the library.policy file is empty. |
app.policy | profile_root/config/cells/cell_name The app.policy file
defines the default permissions that are granted to all of the enterprise
applications running on node_name in cell_name.
Note: Updates
to the app.policy file only apply to the enterprise applications
on the node to which the app.policy file belongs.
|
was.policy | profile_root/config/cells/cell_name This template is for application-specific permissions. The was.policy file is embedded in the enterprise archive (EAR) file. |
ra.xml | rar_file_name/META-INF/was.policy.RAR. This file can have a permission specification that is defined in the ra.xml file. The ra.xml file is embedded in the RAR file. |
grant [codebase <Codebase>] { permission <Permission>; permission <Permission>; permission <Permission>; }; <CodeBase>: A URL. For example, "file:${java.home}/lib/tools.jar" When [codebase <Codebase>] is not specified, listed permissions are applied to everything. If URL ends with a JAR file name, only the classes in the JAR file belong to the codebase. If URL ends with "/", only the class files in the specified directory belong to the codebase. If URL ends with "*", all JAR and class files in the specified directory belong to the codebase. If URL ends with "-", all JAR and class files in the specified directory and its subdirectories belong to the codebase. <Permissions>: Consists from Permission Type : class name of the permission Target Name : name specifying the target Actions : actions allowed on target For example, java.io.FilePermission "/tmp/xxx", "read,write"Refer to developer kit specifications for the details of each permission.
Symbol | Meaning |
---|---|
file:${application} | Permissions apply to all the resources within the application |
file:${jars} | Permissions apply to all the utility Java archive (JAR) files within the application |
file:${ejbComponent} | Permissions apply to the Enterprise JavaBeans™ (EJB) resources within the application |
file:${webComponent} | Permissions apply to the Web resources within the application |
file:${connectorComponent} | Permissions apply to the connector resources within the application |
grant codeBase "file:DefaultWebApplication.war" { permission java.security.SecurityPermission "printIdentity"; }; grant codeBase "file:IncCMP11.jar" { permission java.io.FilePermission "${user.install.root}${/}bin${/}DefaultDB${/}-", "read,write,delete"; };
Symbol | Meaning |
---|---|
file:${application} | Permissions apply to all the resources within the application |
file:${jars} | Permissions apply to all the utility JAR files within the application |
file:${ejbComponent} | Permissions apply to the enterprise beans resources within the application |
file:${webComponent} | Permissions apply to the Web resources within the application |
file:${connectorComponent} | Permissions apply to the connector resources both within the application and in the standalone connector resources. |
Symbol | Meaning |
---|---|
${app.installed.path} | Path where the application is installed |
${was.module.path} | Path where the module is installed |
${current.cell.name} | Current cell name |
${current.node.name} | Current node name |
${current.server.name} | Current server name |
Carefully determine where to add a new permission. An incorrectly specified permission causes an AccessControlException exception. Because dynamic policy resolves the code base at runtime, determining which policy file has a problem is difficult. Add a permission only to the necessary resources. For example, use ${ejbcomponent}, and etc instead of ${application}, and update the was.policy file instead of the app.policy file, if possible.
Limited static policy filtering support exists. If the app.policy file and the was.policy file have permissions that are defined in the filter.policy file with thefilterMask keyword, the runtime removes the permissions from the applications and an audit message is logged. However, if the permissions that are defined in the app.policy and the was.policy files are compound permissions, for example, java.security.AllPermission, the permission is not removed, but a warning message is written to the log file. The policy filtering only supports Developer Kit permissions; the permissions package name begins with java or javax.
Run-time policy filtering support is provided to force stricter filtering. If the app.policy file and the was.policy file have permissions that are defined in the filter.policy file with the runtimeFilterMask keyword, the runtime removes the permissions from the applications no matter what permissions are granted to the application. For example, even if a was.policy file has the java.security.AllPermission permission granted to one of its modules, specified permissions such as the runtimeFilterMask permission are removed from the granted permission during runtime.
If the Warn if applications are granted custom permissions option on the Secure administration, applications, and infrastructure panel is enabled and if the app.policy file and the was.policy file contain custom permissions (non-Developer Kit permissions, where the permissions package name begins with java or javax), a warning message logs. The permission is not removed. If the AllPermission permission is listed in the app.policy file and the was.policy file, a warning message logs.
Using the policy tool that is provided by the Developer Kit (app_server_root/java/jre/bin/policytool), to edit the previous policy files is recommended. For WebSphere Application Server, Network Deployment, extract the policy files from the repository before editing. After the policy file is extracted, use the policy tool to edit the file. Check the modified policy files into the repository and synchronize them with other nodes.
grant { permission javax.security.auth.PrivateCredentialPermission "javax.resource.spi.security.PasswordCredential * \"*\" ","read"; };If the permission is in a policy file that is loaded by the IBM Developer Kit, Java Technology Edition policy tool Version 5, the following message might display:
Errors have occurred while opening the policy configuration. View the warning log for more information.or the following message might display in a warning log:
Warning: Invalid argument(s) for constructor: javax.security.auth.PrivateCredentialPermission.To fix this problem, edit the permission and remove the trailing space. When the trailing space is removed, the permission loads properly. The following code sample shows the corrected permission:
grant { permission javax.security.auth.PrivateCredentialPermission "javax.resource.spi.security.PasswordCredential * \"*\","read"; }
com.ibm.ws.security.policy.*=all=enabled: com.ibm.ws.security.core.SecurityManager=all=enabled