WebSphere Application Server Network Deployment, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Configuring filter.policy files

Before you begin

Before starting this task, the wsadmin tool must be running. See the Starting the wsadmin scripting client article for more information.

Why and when to perform this task

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 Protecting system resources and APIs (Java 2 security). The filtering policy defined in the filter.policy file is cell wide. Refer to the Java 2 security policy files topic for the list of available policy files that is supported by WebSphere Application Server. The filter.policy file is the only policy file that is used when restricting the permission instead of granting permission. The permissions that are listed in the filter policy file are filtered out from the app.policy file and the was.policy file. 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 file and the was.policy file are compound permissions like the java.security.AllPermission permission, 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), a warning message is logged and the permission is not removed. You can change the value of the Issue permission warning option on the Global Security panel. It is not recommended that you use the AllPermission permission for the enterprise application.

Some default permissions that are defined in the filter.policy file. These permissions are the minimal ones that are 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.

You cannot use the Policy Tool to edit the filter.policy file. Editing must be completed in a text editor. Be careful and verify that no syntax errors exist in the filter.policy file. If any syntax errors exist in the filter.policy file, the file is not loaded by the product security run time, which implies that filtering is disabled.

Steps for this task

  1. Extract the filter.policy file. For example:
    set obj [$AdminConfig extract cells/cell_name/filter.policy c:/temp/test/filter.policy]
  2. Check in the policy file. For example:
    $AdminConfig checkin cells/cell_name/filter.policy c:/temp/test/filter.policy $obj

Result

An updated filter.policy file is applied to all of the WebSphere Application Server enterprise applications after the servers are restarted.

Example

filter.policy

The filter.policy file that is supplied by WebSphere Application Server resides at: app_server_root/profiles/profile_name/config/cells/cell_name/filter.policy.

This fill 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 that are defined in filterMask filter 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 that are defined in the filterMask filter, and if scripting is used. The runtimeFilterMask filter defines permissions that are used by the security run time to deny access to those permissions to application thread. Do not add more permissions to the runtimeFilterMask filter. Application start failure or incorrect functioning might result. Be careful when adding more permissions to the runtimeFilterMask filter. 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 can compromise the integrity of the system. For instance, WebSphere Application Server considers the exitVM and setSecurityManager permissions as those permissions that most applications never have. If these permissions are granted, the following scenarios are possible:
exitVM
A servlet, JavaServer Pages (JSP) file, enterprise bean, or other library that is 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, a conflict exists with the internal security manager within WebSphere Application Server. If you must set a security manager in an application for Remote Method Invocation (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, which the application code can verify is registered by using the System.getSecurityManager application programming interface (API).
Important: In application code, do not use the setSecurityManager permission to set a security manager. When an application uses the setSecurityManager permission, a conflict exists with the internal security manager within WebSphere Application Server. If you must set a security manager in an application for Remote Method Invocation (RMI) purposes, you also must enable the Restrict access to local resources option on the Secure administration, applications, and infrastructure panel within the WebSphere Application Server administrative console. WebSphere Application Server then registers a security manager, which the application code can verify is registered by using the System.getSecurityManager application programming interface (API).

What to do next

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



Related concepts
Java 2 security policy files

Related tasks
Migrating, coexisting, and interoperating – Security considerations
Configuring app.policy files
Configuring the was.policy file
Using Policy Tool to edit policy files
Configuring Java 2 security policy files

Related reference
Global security settings

Task topic    

Terms of Use | Feedback

Last updated: Dec 11, 2005 4:07:15 PM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tsec_filterpolicy.html

© Copyright IBM Corporation 2002, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)