The Java Security Manager

At the JVM level, WebLogic can use the standard Java Security Manager to prevent untrusted code from performing unwanted actions. Using a security policy file, you can configure the JVM so that all threads running on the JVM have restricted access to sensitive runtime operations. The security policy file encapsulates a set of permissions that are granted to (or revoked from) all classes loaded within the current instance of the JVM. You can define a whole range of security permissions to control access to particular resourcese.g., "write" access to certain folders on the filesystem, "connect" access to a particular host and range of ports, "read" access to environment variables, "get" access to the current class loader, and more. Refer to your JDK documentation for more information on the Security Manager and security policy files.

Java's Security Manager ensures that any code running within WebLogic accesses these critical resources only in the permitted ways. This low level of access control may be useful for third-party untrusted code. The Java Security Manager also can interact with J2EE deployment settings. For instance, you can use the standard ra.xml deployment descriptor to define security permissions that apply to the resource adapter. WebLogic also provides similar access control for web applications and EJBs.

Note that WebLogic itself requires a policy file to be in place before it can run. The startWebLogic scripts load the policy file located at WL_HOME/server/lib/weblogic.policy by default.

17.1.1 Configuring the Security Manager

In order to use the Java Security Manager, you need to supply two options from the command line when starting WebLogic Server:

• You must use the -Djava.security.manager option to ensure that the default security manager is installed, and that the JVM is subjected to policy checks.
• You must use the -Djava.security.policy option to specify the location of a security policy file.

By default, the JVM uses security policies defined in the java.security and java.policy files located under the JAVA_HOME/jre/lib/security folder. Here is the syntax for starting WebLogic Server using a custom security policy file:

java -Djava.security.manager -Djava.security.policy==c:oreilly.policy 
 ... weblogic.Server

The default startup scripts created by WebLogic refer to the sample security policy file located at WL_HOME/server/lib/weblogic.policy. Notice how we've used the == (double equal sign) when specifying the java.security.policy argument. This persuades the Security Manager to use c:oreilly.policy as its only source of policies. If we had used a single equal sign instead, the policy file would be used in conjunction with default security policy files provided by your JDK installation.

Usually the JVM will use the security policy file to enforce access control over any code running within WebLogic. The only deviation from this rule is when WebLogic Server starts up. When a server boots up, WebLogic partially disables the Java Security Manager and replaces it with a variation that disables the checkRead( ) method. While this approach improves the performance of the startup sequence, it also reduces the security of the JVM during startup. In addition, it means that the startup classes for WebLogic will run using this modified security manager. You will need to ensure that these classes cause no security breaches.

Because the policy file determines access privileges for all classes running within WebLogic's JVM, we recommend that only the Administrator has read and write access to the security policy file. No other users should be allowed to access the policy file.

 

17.1.2 Global Security Policies

WebLogic allows you to define security policies for EJBs, resource adapters, and web applications in the weblogic.policy file. Table 17-1 lists the codebases under which the default permissions for these component types may be defined.

Table 17-1. Default codebases for access permissions that apply to J2EE components

Application type	Codebase
EJBs	file:/weblogic/application/defaults/EJB
Resource adapters	file:/weblogic/application/defaults/Connector
Servlets	file:/weblogic/application/defaults/Web

You can use these codebases to grant special privileges to particular J2EE component types. Note that any security policies defined under these codebases apply to all EJBs, resource adapters, and web applications deployed to that particular server instance.

17.1.3 Application-Specific Security Policies

You also can define security policies that are specific to an EJB component or resource adapter, and thereby ensure that only particular components are targeted. To achieve this, you must modify their deployment descriptors, and not the policy file itself. Resource adapters support this mechanism as part of the J2EE standard, and you need only modify the standard ra.xml descriptor file. For EJBs, you need to modify the weblogic-ejb-jar.xml descriptor file. In both cases, it is the security-permission element that allows you to define additional security policies.

Let's look at specifying permissions for EJBs. The security-permission element in the weblogic-ejb-jar.xml descriptor specifies security privileges that apply to all EJBs packaged in the EJB JAR. The following example grants read and write access to a temporary directory on the server's filesystem for the EJBs:

 


 


 
 grant permission to special folder
 
 
 grant {
 permission java.io.FilePermission 
 "f:${/}tmp${/}-", "read,write";
 }
 

Notice how the security-permission-spec element defines a grant permission using the same syntax for security policy files. The only restriction to this syntax is that you cannot use the codebase or signedBy clauses.

17.1.4 Tracing the Security Manager

BEA provides a Recording Security Manager that can be used to trace any permission problems caused by the Java Security Manager. When installed, the tool detects and records all access control exceptions that occur at runtime. In this way, you can easily pinpoint problems in your access control policy and later reconfigure the security policy to remove these errors. The tool is not distributed with WebLogic Server. However, it can be downloaded from BEA's dev2dev web site (http://www.dev2dev.bea.com).