CONTENTS | PREV | NEXT

Security Management

Managing Applets and Applications

Java 2 SDK system code invokes SecurityManager methods for access control.

Most appletviewers and browsers will automatically install a security manager, however, a security manager is not automatically installed for applications. To apply the same security policy to applications the user must invoke the JVM with...

-Djava.security.manager AppName

...which sets the value of the java.security.manager property, or the application itself can install a security manager by calling the setSecurityManager method in the java.lang.System class.

To specify a particular security manager...

java -Djava.security.manager=com.domain.MySecMgr AppName

The built-in default security manager is used if no security manager is specified.

java.class.path

Used for classes that are stored on the local file system, but should not be treated as base classes. Classes on this path are loaded with a secure class loader and are thus subjected to the security policy being enforced.

-Djava.security.policy

Command-line argument that determines what policy files are utilized.

You can use a -Djava.security.policy command-line argument to specify an additional or a different policy file when invoking execution of an application.

For example, if you type the following, where pURL is a URL specifying the location of a policy file, then the specified policy file will be loaded in addition to all the policy files specified in the security properties file:

java -Djava.security.manager -Djava.security.policy=pURL AppName

If you instead type the following command, using a double equals, then just the specified policy file will be used; all others will be ignored:

java -Djava.security.manager -Djava.security.policy==pURL AppName

If not included, the policy files specified in the security properties file will be used.

SecurityManager versus AccessController

The new access control mechanism is fully backward compatible. For example, all check methods in SecurityManager are still supported, although most of their implementations are changed to call the new SecurityManager checkPermission method, whose default implementation calls the AccessController checkPermission method. Note that certain internal security checks may stay in the SecurityManager class, unless it can be parameterized.

We have not at this time revised any system code to call AccessController instead of calling SecurityManager (and checking for the existence of a classloader), because of the potential of existing third-party applications that subclass the SecurityManager and customize the check methods. In fact, we added a new method SecurityManager.checkPermission that by default simply invokes AccessController.checkPermission.

To understand the relationship between SecurityManager and AccessController, it is sufficient to note that SecurityManager represents the concept of a central point of access control, while AccessController implements a particular access control algorithm, with special features such as the doPrivileged method. By keeping SecurityManager up to date, we maintain backward compatibility (e.g., for those applications that have written their own security manager classes based on earlier versions of the JDK) and flexibility (e.g., for someone wanting to customize the security model to implement mandatory access control or multilevel security). By providing AccessController, we build in the algorithm that we believe is the most restrictive and that relieves the typical programmer from the burden of having to write extensive security code in most scenarios.

We encourage the use of AccessController in application code, while customization of a security manager (via subclassing) should be the last resort and should be done with extreme care. Moreover, a customized security manager, such as one that always checks the time of the day before invoking standard security checks, could and should utilize the algorithm provided by AccessController whenever appropriate.

Auxiliary Tools

The Key and Certificate Management Tool

The keytool utility enables users to administer their own public/private key pairs and associated certificates for self-authentication using digital signatures. The authentication information includes both...

• A sequence (chain) of X.509 certificates
• An associated private key, which can be referenced by a so-called "alias".
• Certificates that are "trusted" by users, which are stored in the same database as the authentication information, and can be referenced by an "alias".

keytool stores the keys and certificates in a keystore. The default keystore implementation implements the keystore as a file. It protects private keys with a password.

The chains of X.509 certificates are provided by organizations called Certification Authorities, or CAs. Identities (including CAs) use their private keys to authenticate their association with objects (such as with channels which are secured using SSL), with archives of code they signed, or (for CAs) with X.509 certificates they have issued. As a bootstrapping tool, certificates generated using the -genkey command may be used until a Certification Authority returns a certificate chain.

The private keys in this database are always stored in encrypted form, to make it difficult to disclose these private keys inappropriately. A password is required to access or modify the database. These private keys are encrypted using the "password", which should be several words long. If the password is lost, those authentication keys cannot be recovered.

In fact, each private key in the keystore can be protected using its own individual password, which may or may not be the same as the password that protects the keystore's overall integrity: keypass vs storepass.

This tool is (currently) intended to be used from the command line, where one simply types "keytool" as a shell prompt. keytool is a script that executes the appropriate Java classes and is built together with the SDK.

The command line options for each command may be provided in any order. Typing an incorrect option or typing "keytool -help" will cause the tool's usage to be summarized on the output device (such as a shell window), as given below.

% keytool -help
KeyTool usage:
 
-certreq     [-v] 
             [-alias <alias>] 
             [-sigalg <sigalg>]
             [-file <certreq_file>] 
             [-keypass <keypass>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-delete      [-v] -alias <alias>
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-export      [-v] 
             [rfc] 
             [-alias <alias>] 
             [-file <cert_file>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-genkey      [-v] 
             [-alias <alias>] 
             [-keyalg <keyalg>]
             [-keysize <keysize>] 
             [-sigalg <sigalg>]
             [-dname <distinguished_name>] 
             [-validity <valDays>]
             [-keypass <keypass>] 
             [-keystore <keystore>]
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-help
  
-identitydb  [-v] 
             [-file <idb_file>] 
             [-keystore <keystore>]
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-import      [-v] 
             [-noprompt] 
             [-alias <alias>]
             [-file <cert_file>] 
             [-keypass <keypass>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-keyclone    [-v] 
             [-alias <alias>] -dest <dest_alias>
             [-keypass <keypass>] 
             [-new <new_keypass>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-keypasswd   [-v] 
             [-alias <alias>]
             [-keypass <old_keypass>] 
             [-new <new_keypass>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-list        [-v | -rfc] 
             [-alias <alias>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-printcert   [-v] 
             [-file <cert_file>]
 
-selfcert    [-v] 
             [-alias <alias>] 
             [-sigalg <sigalg>]
             [-dname <distinguished_name>] 
             [-validity <valDays>]
             [-keypass <keypass>] 
             [-keystore <keystore>]
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]
 
-storepasswd [-v] 
             [-new <new_storepass>]
             [-keystore <keystore>] 
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]

PolicyTool

The PolicyTool is a GUI that allows one to specify, generated, edit, export, or import a security policy. The tool is invoked from the command line as "policytool">.

JAR Signing and Verification Tool - jarsigner

The jarsigner tool can be used to digitally sign JAR files, and to verify such signatures. This tool, like the PolicyTool, depends on the keystore that is managed by the keytool.

This tool is a script built with the SDK. Note that it is expected that this tool and the existing jar tool script may be merged in the near future to form a single command-line primitive to create JARs, either signed or unsigned.

 

 

CONTENTS | PREV | NEXT