Java 2 security

 

 

Overview

Configuring Java 2 security essentially involves tweaking...

You can grant additional permissions to the default settings in these files, but WAS does not support making the default settings more restrictive.

If any of the above files are misconfigured, you will get AccessControlExceptions. To avoid syntax errors you might want to edit these policy files using...

$WAS_HOME/java/jre/bin/policytool

Java 2 security and global security can be configured independently of one another. Disabling global security does not disable Java 2 security automatically.

For enterprise application resources and utility libraries, WAS provides dynamic policy support in which the code base is dynamically calculated based on deployment information and permissions are granted based on template policy files during run time.

If an application provider does not provide a was.policy file as part of the application, or if the policy file is misconfigured, you will get Java 2 security access control exceptions.

When Java 2 Security is enabled in the Global Security settings, the installed SecurityManager does not currently check modifyThread and modifyThreadGroup permissions for non-system threads. Allowing Web and EJB application code to create or modify a thread can have a negative impact on other components of the container and can affect the capability of the container to manage enterprise bean life cycles and transactions.

 

Java 2 security for application developers

Applications that access resources not covered by the default WebSphere policy are required to grant the additional Java 2 security permissions to the application.

While it is possible to grant the application additional permissions in one of the other dynamic WebSphere policy files or in one of the more traditional static policy files, such as java.policy, was.policy (which is embedded in the EAR file) ensures the additional permissions are scoped to the exact application that requires them. Scoping the permission beyond the application code that requires it can permit code that normally does not have permission to access particular resources.

If an application component is being developed, like a library that might actually be included in more than one .ear file, then the library developer should document the required Java 2 permissions needed by the application assembler. There is no was.policy file for library type components. The developer must communicate the required permissions through Javadoc or some other external documentation.

If the component library is shared by multiple enterprise applications, the permissions can be granted to all enterprise applications on the node in the app.policy file.

If the permission is only used internally by the component library and the application should never be granted access to resources protected by the permission, then it might be necessary to mark the code as privileged (inserting doPrivileged). However, improperly inserting a doPrivileged might open up security holes.

The section on Dynamic Policy describes how the permissions in the was.policy files are granted at run time.

 

Debugging

For debugging, use the WebSphere SystemOut.log file and the com.ibm.websphere.java2secman.norethrow property.

 

SystemOut.log

The AccessControl exception logged in the SystemOut.log file contains the permission violation that causes the exception, the exception call stack, and the permissions granted to each stack frame. This information is usually enough to determine the missing permission and the code requiring the permission.

 

com.ibm.websphere.java2secman.norethrow

If the JVM com.ibm.websphere.java2secman.norethrow property is set and has a value of true, the security manager does not throw AccessControl exception. Rather, the information is simply logged.

To set com.ibm.websphere.java2secman.norethrow property for a server, go to...

Console | Servers | Application Servers | Additional Properties | Process Definition | Java Virtual Machine | Custom Properties | New.

...and in the Name field, type com.ibm.websphere.java2secman.norethrow. In the Value field, type true.

To set the com.ibm.websphere.java2secman.norethrow property for the node agent, go to...

Console | System Administration | Node Agents | Additional Properties | Process Definition | Java Virtual Machine | Custom Properties | New

...and in the Name field, type com.ibm.websphere.java2secman.norethrow. In the Value field, type true.

 

Handling applications that are not Java 2 security ready

If the increased system integrity that Java 2 security provides is important, then contact the application provider to have the application support Java 2 security or at least communicate the required additional permissions beyond the default WebSphere policy that must be granted.

The easiest way to deal with such applications is to disable Java 2 security in WAS. The downside is that this solution applies to the entire system and the integrity of the system is not as strong as it might be. Disabling Java 2 security might not be acceptable depending on the organization security policies or risk tolerances.

Another approach is to leave Java 2 security enabled, but to grant either just enough additional permissions or grant all permissions to just the problematic application. Granting permissions however, might not be a trivial thing to do. If the application provider has not communicated the required permissions in some way, there is no easy way to determine what the required permissions are and granting all permissions might be the only choice. You minimize this risk by locating this application on a different node, which might help isolate it from certain resources. Grant the java.security.AllPermission permission in the was.policy file embedded in the application's .ear file... 

grant codeBase "file:${application}" {
    permission java.security.AllPermission;
};

 

$WAS_HOME/properties/server.policy

Defines the policy for WebSphere classes. By default, all server processes on the same installation share the same server.policy file. You can configure this file so that each server process can have a separate server.policy file as the value of the Java system properties java.security.policy.

The server.policy managed by the repository and the file replication service. Changes to this file are local and do not get replicated to other machines. Use the server.policy policy for server resources. Use the app.policy file (per node) or was.policy file (per enterprise application) to define Java 2 security policy for enterprise application resources.

 

WAS_HOME/java/jre/lib/security/java.policy

The file represents the default permissions granted to all classes. The policy of this file applies to all the processes launched by the WAS JVM.

 

Troubleshoot

Symptom...

Error message SECJ0314E: Current Java 2 security policy reported a potential violation of Java 2 security permission. Refer to Problem Determination Guide for further information.{0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5} Current Java 2 security policy reported a potential violation of Java 2 Security Permission.

 

Problem:

The Java security manager checkPermission() reported a SecurityException on the subject permission with debugging information. The reported information can be different with respect to the system configuration. This report is enabled by either configuring RAS trace into debug mode or specifying a Java property. Specify the following property in the JVM Settings panel from the administrative console: java.security.debug. Valid values include:

access Print all debug information including: required permission, code, stack, and code base location.
stack Print debug information including: required permission, code, and stack.
failure Print debug information including: required permission and code.

 

Recommended response...

Turn on security trace to determine the potential code that might have violated the security policy. Once the violating code is determined, verify if the attempted operation is permitted with respect to Java 2 security, by examining all applicable Java 2 security policy files and the application code.

If the application is running with Java Mail, this message might be benign. User can update the was.policy file to grant the following permissions to the application. 

permission java.io.FilePermission "${user.home}${/}.mailcap", "read"; 
permission java.io.FilePermission "${user.home}${/}.mime.types", "read"; 
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read"; 
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

 

Messages

Message... SECJ0313E: Java 2 security manager debug message flags are initialized\: TrDebug: {0}, Access: {1}, Stack: {2}, Failure: {3}
Problem... Configured values of the valid debug message flags for security manager.
Recommended response... None.

 

Message... SECJ0307E: Unexpected exception is caught when trying to determine the code base location. Exception: {0}
Problem... An unexpected exception is caught when the code base location is determined.
Recommended response... Contact an IBM representative.