Java 2 security

Java 2 security provides a policy-based, fine-grain access control mechanism that checks for permissions before allowing access to protected system resources such as file I/O, sockets, and properties. J2EE security guards access to web resources such as servlets, JavaServer Pages (JSP) files and EJB methods.

Java 2 security is disabled by default. We can configure Java 2 security and administrative security independently of one another. Disabling administrative security does not disable Java 2 security automatically. We need to explicitly disable it.

If the applications, or third-party libraries are not ready, having Java 2 security enabled causes problems. We can identify these problems as Java 2 security AccessControlExceptions in the system log or trace files. If we are unsure about the Java 2 security readiness of the applications, disable Java 2 security initially to get the application installed and verify that it is working properly.

The restrictive policy is the default policy for Java 2 security. We can grant additional permissions, but we cannot make the default more restrictive. AccessControlExceptions exceptions are generated from within WAS v9 which does not support a more restrictive policy than the default defined in the policy files.

Java 2 policy files are used to define the security policy for the Java process. These policy files are static (code base is defined in the policy file) and in the default policy format provided by the IBM Developer Kit, Java Technology Edition. For enterprise application resources and utility libraries, WAS provides dynamic policy support. The code base is dynamically calculated based on deployment information and permissions are granted based on template policy files during runtime.

Syntax errors in the policy files cause the application server process to fail, so edit these policy files carefully using the Policy Tool.

When Java Security is enabled in the administrative security settings, the installed security manager 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.

Application developers additional permissions

To know whether additional permissions are required application developers must understand...

• The permissions granted in the default WebSphere policy file, was.policy, which is embedded in the application EAR file
• The permission requirements of the SDK APIs called by their application

If an application component, like a library, needs to be included in more than one .ear file, the library developer should document the required Java 2 permissions required by the application assembler. There is no was.policy file for library-type components. The developer must communicate the required permissions through API documentation 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. Updates to the app.policy file only apply to the enterprise applications on the node to which the app.policy file belongs.

If the permission is only used internally by the component library and the application is never granted access to resources protected by the permission, we can mark the code as privileged. Note however that improperly inserting a doPrivileged call might open up security holes.

The section on Dynamic policy files in Java 2 security policy files describes how the permissions in the was.policy files are granted at runtime.

Debugging

The AccessControl exception logged in the system log or trace files 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.

When the JVM property is...

com.ibm.websphere.java2secman.norethrow = true

...the security manager does not create the AccessControl exception and does not cause a failure. Java 2 security is not enforced. This property is intended for a sandbox or debug environment Do not use this property in a production environment where a relaxed Java 2 security environment weakens the integrity that Java 2 security is intended to produce.

We can also also disable Java 2 security in WAS.

One other approach is to leave Java 2 security enabled and grant just enough additional permissions. if the application provider has not communicated the required permissions this may not be a trivial task.

Finally we can grant all permissions to just the problematic application. We can minimize risk by locating this application on an isolated node, away from certain resources. Grant the java.security.AllPermission permission in the was.policy file embedded in the application .ear file, for example:

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

The server.policy file

The server.policy file is located in...

app_server_root/properties/

(iSeries) The server.policy file is located in...

profile_root/properties

The server.policy file defines the policy for the WAS classes. By default all the server processes share the same server.policy file. However, we can configure this file so that each server process can have a separate file. Define server.policy as the value of the java.security.policy Java system properties . For details of how to define Java system properties, refer to the Process definition section of the Manage application servers file.

The server.policy file is not a configuration file 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 file to define Java 2 security policy for server resources. Use the app.policy file (per node) or the was.policy file (per enterprise application) to define Java 2 security policy for enterprise application resources.

Updates to the app.policy file only apply to the enterprise applications on the node to which the app.policy file belongs.

The java.policy file

The java.policy file represents the default permissions granted to all classes. The policy of this file applies to all the processes launched by the Java Virtual Machine in the WAS.

The java.policy file is located in the app_server_root/java/lib/security directory.

(iSeries) The java.policy file is located in...

${java.home}/lib/security/

The policy file is used throughout the operating system. Do not edit the java.policy file.

Troubleshoot

Error message CWSCJ0314E

Symptom:

Error message CWSCJ0314E: 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. Refer to Problem Determination Guide for further information.{0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5}

Problem:

The Java security manager checkPermission method reported a security exception 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 a Reliability Availability Service Ability (RAS) trace into debug mode or specifying a Java property.

See Enable trace for information on how to configure RAS trace in debug mode.

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:

The reported exception might be critical to the secure system. Turn on security trace to determine the potential code that might have violated the security policy. After 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. We 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";

SecurityException - Access denied

Symptom:

If Java security is enabled, and permissions to read the jaxm.properties file is not granted, when a SOAPFactory instance is created through a call to javax.xml.soap.SOAPFactory.newInstance(), or a MessageFactory instance is created through a call to MessageFactory.newInstance(), a SecurityException exception occurs, and the following exception is written to the system log:

Permission:

      /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied 
(java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties
read)

Code:

     com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder  
in  {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/
ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib
/addressbinder1.jar}

Stack Trace:

java.security.AccessControlException: access denied (java.io.FilePermission
/opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read)
.

Problem:

The Java 2 Security policy reports a potential violation of Java 2 Security permission.

Recommended response:

The SOAPFactory ignores the exception, and continues on to the next means of determining which implementation to load. Therefore, we can ignore the log entry for this security exception.

Because this product uses the SOAPFactory to support other web services technologies, such as WS-Addressing (WS-A) , WS-Atomic Transaction (WS-AT), and WS-Notification, we can ignore this SecurityException in any web services application where Java security is enabled.

Messages

Message: CWSCJ0313E: 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.

Message: CWSCJ0307E: 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.

Subtopics

• Java 2 security policy files
  
• Java 2 access control
  
• server.policy file

Work with trace

Java 2 Connector authentication data entry settings

Configuration entry settings for JAAS

Login module settings for JAAS