Configure the filter.policy file

Java 2 Security uses several policy files to determine the granted permission for each Java programs. Java 2 Security policy filtering is only in effect when Java 2 Security is enabled. For more information about enabling Java 2 Security, see Configure Java 2 security.

The filtering policy that is defined in the filter.policy file is cell wide. The filter.policy file is the only policy file that is used to restrict permissions instead of granting permissions. The permissions that are listed in the filter policy file are filtered out of the app.policy and was.policy files. Permissions that are 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 that are defined in the app.policy and was.policy files are compound permissions (java.security.AllPermission, for example), the permission is not removed, and a warning message is logged. If Issue Permission Warning is enabled (it is enabled by default), and if the app.policy and was.policy files contain custom permissions (permissions for packages that do not start with java or javax), then a warning message is logged, and the permission is not removed. You can disable the Issue Permission Warning setting in the Global Security page of the administrative console. If java.security.AllPermission is specified in the app.policy file or in the was.policy file, a warning message is logged. However, the permission is not removed. It is recommended that you not use AllPermission for your enterprise applications.

Some default permissions are defined in the filter.policy file. These are the minimal permissions that are recommended. If more permissions are added to the filter.policy file, certain operations may fail for enterprise applications.

The filter.policy file is managed by the WebSphere configuration and file replication services, so changes that are made in the file are replicated to other nodes in the Network Deployment cell.

The WebSphere Application Server filter.policy file is located in the /QIBM/UserData/WebAS5/product/instance/config/cells/cell directory, where product is either Base or ND, instance is the name of your instance, and cell is the name of your cell.

By default, the filter.policy file contains these permissions:

  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 that are defined in the filterMask block are for static policy filtering. The security run time tries to remove the permissions from applications during application startup. Compound permissions are not removed and a warning is issued. Application deployment is stopped if applications contain permissions that are defined in filterMask and if scripting was used (wsadmin tool).

The runtimeFilterMask block defines the permissions to access resources that the security run time denies to the application thread. Do not add more permissions to the runtimeFilterMask because the application may fail to start or may function incorrectly. Usually, you only need to add permissions to the filterMask block.

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

• exitVM
  A servlet, JSP file, enterprise bean, or other library could call the System.exit() API and cause the entire WebSphere Application Server process to terminate.

• setSecurityManager
  An application could install its own SecurityManager that could either grant more permissions or bypass the default policy that the WebSphere Application Server SecurityManager enforces.

If there are syntax errors in the filter.policy file, it is not loaded by the WebSphere security run time. This implies that there is no filter in place. If there is no filter, enterprise applications can access resources that are normally not allowed. Use extreme care editing the filter.policy file.

In Version 5, there is no tool support for editing the filter.policy file. You must use a text editor to edit the file.

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