Secure Class Loading

Because class loading exposes an agent to external classes, the Java Dynamic Management Kit offers security within the m-let service. Security mechanisms differs between the JDK 1.1 and Java 2 Java runtime environments.

Security Manager (JDK 1.1)

The default behavior of the Java virtual machine forbids you from downloading native libraries across the network, since the code they contain cannot be controlled by the usual Java security mechanism. If the classes you wish to download are bundled with native libraries, you will need to instantiate a custom security manager.

The Java Dynamic Management Kit provides a simple implementation of a security manager, called com.sun.jdmk.AgentSecurityManager, which accepts all incoming libraries. This security manager extends the java.lang.SecurityManager interface, and you must install it as the default security manager for your agent application.

Before your agent instantiates the MLetSrv class it must set the security manager in the Java virtual machine. This is done with the following call:

import com.sun.jdmk.AgentSecurityManager;

System.setSecurityManager(new AgentSecurityManager());

Code Signing (JDK 1.1)

Code signing is a security measure which you can use to identify the originator of a downloaded class. The m-let service will enforce code signatures if it is instantiated in secure mode. One of the constructors of the MLetSrv class takes a boolean parameter which specifies the security mode. For obvious security reasons, the security mode cannot be modified once the m-let service is instantiated.

When the m-let service is running in secure mode, it will only load classes and native libraries which are signed by a trusted party. A trusted party is identified by a key: this key was used to sign the code and a copy of the key is given to all parties that wish to download the signed class. Therefore, you must identify trusted keys in your agent before attempting to download their signed classes.

Downloading native libraries always requires a custom security manager, regardless of whether they are trusted or not. See the description of the "Security Manager (JDK 1.1)".

In the JDK 1.1 environment, .jar files are signed using the javakey utility. You also use the javakey utility on your agent's host to identify trusted keys. The command line parameters of this tool allow you to define your security policy based on trusted identities and keys. Please refer to the JDK documentation of the javakey utility for details.

When the secure mode of the m-let service is enabled, unsigned classes and libraries will never be loaded.

When the secure mode is not enabled, all classes and native libraries may be downloaded, regardless of whether they are signed and not trusted, or not signed.

Code Signing (Java 2)

The code signing mechanism and trust policies were modified for the Java 2 platform.

In the MLet class for the Java 2 platform, security is no longer determined when you instantiate the m-let service. Rather, security is enabled or disabled for your entire agent application, including any class loaders used by the m-let service. Class loaders on the Java 2 platform also rely on code signing, but the mechanism is different.

To enable security on the Java 2 platform, launch your agent applications with the java.lang.SecurityManager property on the command line. Then, when the m-let service loads a class through one of its class loaders, the class loader will check the origin and signature of the class against the list of trusted origins and signatures.

The tools involved in signing a class file are the jar, keytool, and jarsigner utilities. On the host where the agent application would like to download a class, you define a set of permissions for signatures and URL origins. Then, you need to use the policytool utility to generate a java.policy file containing the trusted signatures. Please refer to the JDK documentation for the description of these utilities.

When the agent application is launched with a security manager, it will check this policy file to insure that the origin and signature of a downloaded class match a trusted origin and a trusted signature. If they do not match, the code is not trusted and cannot be loaded.

When the agent application is launched without the security manager, all classes and native libraries may be downloaded and instantiated, regardless of their origin and signature, or lack thereof.