WAS v8.5 > Secure applications > Set up security > Enable security

Java 2 security

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

Because Java 2 security is relatively new, many existing or even new applications might not be prepared for the very fine-grain access control programming model that Java 2 security is capable of enforcing. Administrators need to understand the possible consequences of enabling Java 2 security if applications are not prepared for Java 2 security. Java 2 security places some new requirements on application developers and administrators.

The application server does not support a custom Java security manager implementation.


Java 2 security for deployers and administrators

Although Java 2 security is supported, it 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. You 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 policy embodied by these policy files cannot be made more restrictive because the product might not have the necessary Java 2 security doPrivileged APIs in place. The restrictive policy is the default policy. We can grant additional permissions, but we cannot make the default more restrictive because AccessControlExceptions exceptions are generated from within WebSphere Application Server. WAS v8.5 does not support a more restrictive policy than the default defined in the policy files previously mentioned.

Several 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. Refer to the Java 2 security policy files for more information.

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

If an application is not prepared for Java 2 security, if the application provider does not provide a was.policy file as part of the application, or if the application provider does not communicate the expected permissions the application is likely to cause Java 2 security access control exceptions at runtime. It might not be obvious that an application is not prepared for Java 2 security. Several run-time debugging aids help troubleshoot applications that might have access control exceptions. See the Java 2 security debugging aids for more details. See Handling applications that are not Java 2 security ready for information and strategies for dealing with such applications.

It is important to note 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.


Java 2 security for application developers

Application developers must understand the permissions that are granted in the default WebSphere policy and the permission requirements of the SDK APIs their application calls to know whether additional permissions are required. The Permissions in the Java 2 SDK reference in the resources section describes which APIs require which permission.

Application providers can assume that applications have the permissions granted in the default policy previously mentioned. 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 java.policy static policy files, the was.policy file, 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 needs to 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 that are protected by the permission, it might be necessary to mark the code as privileged. Refer to the, AccessControlException, topic for more details. However, improperly inserting a doPrivileged call might open up security holes. Understand the implication of doPrivileged call to make a correct judgement.

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.

Developing an application to use with Java 2 security might be a new skill and impose a security awareness not previously required of application developers. Describing the Java 2 security model and the implications on application development is beyond the scope of this section. The following URL can help you get started: http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.


Debugging Aids

The WAS SYSOUT file and the com.ibm.websphere.java2secman.norethrow property are the two primary aids for debugging.


The WebSphere System Log or Trace Files

The AccessControl exception that is 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.


The com.ibm.websphere.java2secman.norethrow property

When Java 2 security is enabled in WAS, the security manager component creates a java.security.AccessControl exception when a permission violation occurs. This exception, if not handled, often causes a run-time failure. This exception is also logged in the SYSOUT file.

However, when the Java virtual machine com.ibm.websphere.java2secman.norethrow property is set and has a value of true, the security manager does not create the AccessControl exception. This information is logged.

This property is intended for a sandbox or debug environment because it instructs the security manager not to create the AccessControl exception. Java 2 security is not enforced. 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.

This property is valuable in a sandbox or test environment where the application can be thoroughly tested and where the system log or trace files can be inspected for AccessControl exceptions. Because this property does not create the AccessControl exception, it does not propagate the call stack and does not cause a failure. Without this property, we have to find and fix AccessControl exceptions one at a time.


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 WAS 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, no easy way exists 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 that is 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 the app_server_root/properties/ directory.

This policy defines the policy for the WAS classes. At present, all the server processes on the same installation share the same server.policy file. However, we can configure this file so that each server process can have a separate server.policy file. Define the policy file 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 file represents the default permissions that are 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.


Troubleshooting

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 dmgr 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


Related


Work with trace


Reference:

Java 2 Connector authentication data entry settings
Configuration entry settings for Java Authentication and Authorization Service
Login module settings for Java Authentication and Authorization Service


+

Search Tips   |   Advanced Search