Configure filter.policy files

 

Overview

Java 2 security uses several policy files to determine the granted permission for each Java program. Java 2 security policy filtering is only in effect when Java 2 security is enabled. Refer to Configuring Java 2 security. The filtering policy defined in the filter.policy file is cell wide. Refer to the article, Dynamic policy, for the list of available policy files supported by WebSphere Application Server. The filter.policy file is the only policy file used when restricting the permission instead of granting permission. The permissions listed in the filter policy file are filtered out from the app.policy file and the was.policy file. Permissions defined in the other policy files are not affected by the filter.policy file.

When a permission is filtered out, an audit message is logged. However, if the permissions defined in the app.policy file and the was.policy file are compound permissions like java.security.AllPermission, for example, the permission is not removed. A warning message is logged. If the Issue Permission Warning flag is enabled (default) and if the app.policy file and the was.policy file contain custom permissions (non-Java API permission, the permission package name begins with characters other than java or javax), then a warning message is logged and the permission is not removed. We can change the value of the Issue permission warning option on the Global Security panel. It is not recommended that you use AllPermission for the enterprise application.

There are some default permissions defined in the filter.policy file. These permissions are the minimal ones recommended by the product. If more permissions are added to the filter.policy file, certain operations can fail for enterprise applications. Add permissions to the filter.policy file carefully.

 

Step for this task

 

Result

An updated filter.policy file is applied to all of the WAS enterprise application after the servers are restarted.

 

Examplefilter.policy

The filter.policy file supplied by WAS resides at: install_root/profiles/profile/config/cells/cell/filter.policy.

It contains these permissions as defaults:

filterMask {
permission java.lang.RuntimePermission "exitVM";
permission java.lang.RuntimePermission "setSecurityManager";
permission java.security.SecurityPermission "setPolicy";
permission javax.security.auth.AuthPermission "setLoginConfiguration"; };
runtimeFilterMask {
permission java.lang.RuntimePermission "exitVM";
permission java.lang.RuntimePermission "setSecurityManager";
permission java.security.SecurityPermission "setPolicy";
permission javax.security.auth.AuthPermission "setLoginConfiguration"; };

The permissions defined in filterMask are for static policy filtering. The security run time tries to remove the permissions from applications during application startup. Compound permissions are not removed but are issued with a warning, and application deployment is stopped if applications contain permissions defined in filterMask, and if scripting was used (wsadmin tool). The runtimeFilterMask defines permissions used by the security run time to deny access to those permissions to application thread. Do not add more permissions to the runtimeFilterMask. Application start failure or incorrect functioning might result. Be careful when adding more permissions to the runtimeFilterMask. Usually, you only need to add permissions to the filterMask stanza.

WebSphere Application Server relies on the filter policy file to restrict or disallow certain permissions that could compromise the integrity of the system. For instance, WAS considers the exitVM and setSecurityManager permissions as those permissions that most applications should never have. If these permissions are granted, then the following scenarios are possible:

exitVM

A servlet, JSP file, enterprise bean, or other library used by the aforementioned might call the System.exit() API and cause the entire WebSphere Application Server process to terminate.

setSecurityManager

An application might install its own security manager and either grant more permissions or bypass the default policy that the WebSphere Application Server security manager enforces.

Important: 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 set a security manager in an application for RMI purposes, you also must enable the Enforce Java 2 Security option on the Global security settings 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).

 

What to do next

For the updated filter.policy file to take effect, restart related Java processes.

---

 

See Also

Java 2 security policy files

 

Related Tasks

Migrating security configurations from previous releases
Configuring app.policy files
Configuring the was.policy file
Using PolicyTool to edit policy files

 

See Also

Global security settings

 

---