9.3. Enabling Security

In this section, in addition to your role as a developer, you assume the responsibility of an administrator for learning and practicing purposes. However, in real-life deployment situations, the two duties usually are not shared by a single person, because

• The service providers are independent of the gateway operators from an operational perspective.

• Merging the two roles would constitute conflicts of interest, because each service would like to have as little security restrictions as possible, which is usually not acceptable for overall security. Bear in mind that services from competitors are likely to coexist in the framework, and it won't be fair to allow one to regulate security, possibly at the sacrifice of another.

Undoubtedly developers and the administrator must cooperate with one another. A developer's concerns with security are mostly local to one's particular service, whereas an administrator must plan for the security of the overall system consisting of many services. Each developer usually communicates to the administrator the permissions that are required by one's service, but the administrator is the policy maker.

To enable security for the Java Embedded Server software, the administrator must do the following:

9.3.1. Setting Up a Policy

In JDK, policies are defined using a flat text file, and can be retrieved through a URL. Multiple policy files can be used to specify a composite policy. The policies to be applied are specified by the security configuration file java_home/lib/security/java.security, where java_home points to the Java runtime environment on the system.

By default, JDK uses java_home/lib/security/java.policy, which defines the systemwide policy, and user_home/.java.policy, which defines the per-user policy, where user_home points to a user's home directory.

In this discussion, we use an additional application-specific policy, with a location that is specified with the system property java.security.policy. Let's refer to our policy file as jes_policy.

9.3.2. Running with Security Enabled

To enable security, we must install the default security manager when we launch the framework. Otherwise, the Java runtime environment reverts to the “sandbox” model, in which all local classes are fully trusted. Furthermore, we want to grant the framework implementation code all permissions; therefore, we define the following policy file as a starting point:

grant codeBase "file:jes_path/lib/*" {
   permission java.security.AllPermission;
};

Make sure you include the semicolon at the end after the closing brace, and save this file as jes_policy. The following command line is used to start the Java Embedded Server software:

java -Djava.security.manager -Djava.security.policy=jes_policy
   com.sun.jes.impl.framework.Main

You see the same screen that you did in Chapter 2. Issue the help command to confirm that security is indeed enabled:

Java Embedded Server 2.0

Copyright 1998, 1999 and 2000 Sun Microsystems, Inc.
All rights reserved.
Use is subject to license terms.

Type h[elp] for a list of commands.
> help
...

JES cache directory:    /home/joe/jescache
Bundle base URL:       file:/home/joe/jes2.0/bundles
Java 2 security support: Yes
					

How will things work differently now that security has been enabled? Let's attempt to install and activate the Log bundle to find out:

> start jes_path/bundles/log.jar
Error: Could not start bundle jes_path/bundles/log.jar:
org.osgi.framework.BundleException: BundleActivator (start)
failed for bundle ...
Nested exception: java.security.AccessControlException: access
denied (java.util.PropertyPermission com.sun.jes.service.log.size read)

Alas! We are no longer able to perform an innocuous function of activating a standard bundle. The culprit is the Log bundle's lack of a few permissions. From the previous message it needs PropertyPermission to read property com.sun. jes.service.log.size as part of its activation routine.

To fix this problem, we need to append the following entries to jes_policy:

...
grant codeBase "jes_path/bundles/log.jar" {
   permission java.util.PropertyPermission
      "com.sun.jes.service.log.*", "read,write";
   permission org.osgi.framework.ServicePermission
      "org.osgi.service.log.*", "register";
   permission org.osgi.framework.PackagePermission
      "org.osgi.service.log", "export";
};

This definition grants the Log bundle PropertyPermission to read and to write any properties prefixed with com.sun.jes.service.log. It also permits the Log bundle to register its own services; namely, org.osgi.service.log. LogService and org.osgi.service.log.LogReaderService. Lastly, we permit the Log bundle to export the org.osgi.service.log package, which automatically allows it to import that same package.

How can we be certain that these permissions are granted to the Log bundle and not something else? We put the location string as the code base in the grant clause in the policy file, and use it to identify the code source of the classes from the Log bundle only. This location string is the same as the one we used to install the Log bundle in the console previously.

Similarly, we have to inspect other bundles and grant appropriate permissions individually. It is tempting to avoid the hassle and grant broad permissions at a coarse granularity. For example, grant java.security.AllPermission to all code. In doing so we effectively cancel out the protection afforded by Java 2 Platform security. Convenience and security usually demand competing priorities, and you have to make a trade-off.