Migrating Java 2 security policy
Use this topic for guidance pertaining to migrating Java™ 2 security policy.
About this task
Previous WebSphere® Application Server releases
WebSphere Application Server uses the Java 2 security manager in the server runtime to prevent enterprise applications from calling the System.exit and the System.setSecurityManager methods. These two Java application programming interfaces (API) have undesirable consequences if called by enterprise applications. The System.exit API, for example, causes the Java virtual machine (application server process) to exit prematurely, which is not a beneficial operation for an application server.
To support Java 2 security properly, all the server runtime must be marked as privileged (with doPrivileged API calls inserted in the correct places), and identify the default permission sets or policy. Application code is not privileged and subject to the permissions that are defined in the policy files. The doPrivileged instrumentation is important and necessary to support Java 2 security. Without it, the application code must be granted the permissions that are required by the server runtime. This situation is due to the design and algorithm that is used by Java 2 security to enforce permission checks. Refer to the Java 2 security check permission algorithm.
- java.lang.RuntimePermission(exitVM)
- java.lang.RuntimePermission(setSecurityManager)
Application code is denied access to these permissions regardless of what is in the Java 2 security policy. However, the server runtime is granted these permissions. All the other permission checks are not enforced.
- java.net.SocketPermission
- java.net.NetPermission
However, not all the product server runtime is properly marked as privileged. You must grant the application code all the other permissions besides the two listed previously or the enterprise application can potentially fail to run. This Java 2 security policy for enterprise applications is liberal.
What changed
Java 2 Security is fully supported in WebSphere Application Server, which means that all permissions are enforced. The default Java 2 security policy for an enterprise application is the recommended permission set defined by the Java Platform, Enterprise Edition (Java EE) Version 1.4 specification. Refer to the profile_root/config/cells/cell_name/nodes/node_name/app.policy file for the default Java 2 security policy that is granted to enterprise applications. This policy is a much more stringent compared to previous releases.
All policy is declarative. The product security manager honors all policy that is declared in the policy files. There is an exception to this rule: enterprise applications are denied access to permissions that are declared in the profile_root/config/cells/cell_name/filter.policy file.
In application code, do not use the setSecurityManager permission to set a security manager. When an application uses the setSecurityManager permission, there is a conflict with the internal security manager within WebSphere Application Server. If you must set a security manager in an application for RMI purposes, you also must enable the Use Java 2 security to restrict application access to local resources option on the Global security page within the WebSphere Application Server administrative console. WebSphere Application Server then registers a security manager. The application code can verify that this security manager is registered by using System.getSecurityManager() application programming interface (API).
Migrating system properties
- java.security.policy. The absolute path of the policy file (action required). This system property contains both system permissions (permissions granted to the Java virtual machine (JVM) and the product server runtime) and enterprise application permissions. Migrate the Java 2 security policy of the enterprise application to Version 8.5. For Java 2 security policy migration, see the steps for migrating Java 2 security policy.
- enableJava2Security. Used to enable Java 2 security enforcement (no action required). This system property is deprecated; a flag in the WebSphere configuration application programming interface (API) is used to control whether to enable Java 2 security. Enable this option through the administrative console.
- was.home. Expanded to the installation directory of WebSphere Application Server (action might be required). This system property is deprecated; superseded by the ${user.install.root} and ${was.install.root} properties. If the directory contains instance-specific data then ${user.install.root} is used; otherwise ${was.install.root} is used. Use these properties interchangeably for the WebSphere Application Server or the WebSphere Application Server Network Deployment environments. See the steps for migrating Java 2 security policy.
Migrating the Java 2 Security Policy
No easy way exists to migrate the Java policy file to Version 8.5 automatically because of a mixture of system permissions and application permissions in the same policy file. Manually copy the Java 2 security policy for enterprise applications to a was.policy or app.policy file. However, migrating the Java 2 security policy to a was.policy file is preferable because symbols or relative code base is used instead of an absolute code base. This process has many advantages. Grant the permissions that are defined in the was.policy to the specific enterprise application only, while permissions in the app.policy file apply to all the enterprise applications that run on the node where the app.policy file belongs.
Refer to the Java 2 security policy files topic for more details on policy management.
The following example illustrates the migration of a Java 2 security policy from a previous release. The contents include the Java 2 security policy file for the app1.ear enterprise application and the system permissions, which are permissions that are granted to the Java virtual machine (JVM) and the product server runtime.
The default location for the Java 2 security policy file is profile_root/properties/java.policy. Default permissions are omitted for clarity:
The default location for the Java 2 security policy file is profile_root/properties/java.policy. Default permissions are omitted for clarity:
// For product Samples
grant codeBase "file:${app_server_root}/installedApps/app1.ear/-" {
permission java.security.SecurityPermission "printIdentity";
permission java.io.FilePermission "${app_server_root}${/}temp${/}somefile.txt",
"read";
};
For clarity of illustration, all the permissions are migrated as the application level permissions in this example. However, you can grant permissions at a more granular level at the component level (Web, enterprise beans, connector or utility Java archive (JAR) component level) or you can grant permissions to a particular component.