8.1 Overview of the Java 2 Access-Control Model

An obvious handicap with the security architecture of some common mobile-code platforms is the lack of fine-grained access control. Code is in general either completely trusted or completely untrusted, with all trusted code enjoying unrestricted access to all the system resources and all untrusted code not allowed to execute. The Java 2 platform implements a fine-grained access-control model , or the ability to grant specific permissions to a particular piece of code about accessing specific resources of the clientsay, read and write permission on file x but only read permissions on file y and no permission on file z depending on the signers of the code and/or the URL location from which the code was loaded. The existence of a fine-grained access control allows a Java system administrator to specify access permissions on a case-by-case basis.

The Java 2 security architecture allows easy fine-tuning of the access-control restrictions. With the Java 2 security model, all code, whether remotely downloaded or local, signed or unsigned, has access to system resources based on what the system administrator defines in a security policy database. The default implementation of this database is a flat file, called the policy file . This mechanism allows the client to explicitly specify the access rights to be granted to various signatories of code and originating URL locations.

Prior to the Java 2 platform, the JVM resource access was enforced by the sandbox security model, which was a function of the security controller, implemented as a java.lang.SecurityManager object (see Section 7.4 on page 237). Extensions were usually limited to features implemented in the specific platforms such as Web browsers and Java-enabled Web servers. The Java 2 implementation gives you full control over what each program and application is permitted to do, unlike earlier versions. The Java 2 security architecture allows Java system administrators to define the exact operations any programapplication, servlet, enterprise bean, and so onsigned by one or more particular entities and coming from a specific URL location can do. Further, in multiuser systems, the system administrator can define a default system policy database, and each system user can have a separate policy database, which is combined with the system default. Additionally, in an intranet, the network administrator can define a corporatewide policy database and install it on a policy server for all the Java systems in the network to download and use. At runtime, the corporatewide policy database is combined with the system policy database and the user -defined policy database to specify the current security policy in effect.

Java 2 access restrictions can be customized without having to write a new SecurityManager or modify the underlying platform. The Java 2 access-control model is depicted in Figure 8.1 and shows how a predetermined security policy of the Java system dictates the Java security domains within which a specific piece of code can reside.

Figure 8.1. Java 2 Fine-Grained Access Control Mechanism

8.1.1 Lexical Scoping of Privilege Modifications

A security feature implemented in the Java 2 platform is the lexical scoping of privilege modification . Using this technique, a piece of code, typically library code, can be defined as privileged . To understand what privileged code is and why it is necessary, consider the scenario depicted in Figure 8.2.

Figure 8.2. Motivation for Privileged Code

A method in a J2EE-container trusted library class has been programmed to perform a security-sensitive operation, such as opening a socket connection, on behalf of its callers and also to log to a file all the times it has been accessed. It certainly makes sense to require that this method's callers have the necessary java.net.SocketPermission but not the java.io.FilePermission to write to the local file system, because technically, they had not requested to perform the log operation.

As we see in more detail in Section 8.7 on page 274, this problem can be overcome by wrapping the portion of code responsible for writing to the log file into a privileged block . The API to define privileged code is java.security.AccessController.doPrivileged() .

8.1.2 Java 2 Security Tools

The Java 2 reference implementation provides four security tools for ensuring confidentiality, integrity, authenticity of data, and adequate control on access to various system and nonsystem resources. These tools are jar , keytool , jarsigner , and the Policy Tool utilities.

8.1.2.1 The jar Utility

The jar command line tool is used to aggregate and compress collections of Java programs and related resources into a single JAR file. The JAR format acquires specific security significance because only JAR files can be signed. Additionally, JAR files can be sealed (see footnote 2 on page 208).

8.1.2.2 The keytool Utility

The keytool command line utility creates key pairs; imports and exports X.509 V1, V2, and V3 certificates; generates self-signed X.509 certificates; and manages keystores (see Appendix B on page 553). A keystore is a protected database that holds private keys, public keys, and certificates. In the default implementation, a keystore is protected using a password, and each private key stored in the keystore is protected with a possibly different password. The private keys are used to digitally sign programs, whereas public keys are used to verify signed data, and certificates are used to verify whether a public key indeed belongs to the person to whom it is supposed to belong. The -export flag of the keytool command line utility can be used to export certificates from a keystore. The -import flag can be used to import certificates as trusted certificates into a keystore.

The keytool utility can also be used to obtain a certificate issued by a Certificate Authority (see Section 10.3.4 on page 372) by following these steps:

1. Use the -genkey option of the keytool utility to generate a public/private key pair, with the public key wrapped in a self-signed certificate.

2. Use the -certreq option of the keytool utility to generate a PKCS#10 Certificate Signing Request (see Section 12.1.6 on page 437) that contains the self-signed certificate.

3. Send the certificate request to the CA. The CA will authenticate the certificate requestor , usually off line, and will return a certificate or certificate chain, used to replace the existing certificate chain, which initially consists of the self-signed certificate only.

4. Use the -import option of the keytool utility to import the response from the CA.

8.1.2.3 The jarsigner Utility

The jarsigner command line tool signs JAR files and verifies the signatures of signed JAR files. It accesses the keystore when it needs to find

• A private key when signing a JAR file

• A public key when verifying a signature

• A certificate when verifying a public key

8.1.2.4 The Policy Tool

The Policy Tool utility, which is launched through the policytool command, creates and modifies the policy configuration files that define the Java system security policy. In the Java 2 reference implementation, policy files are flat files that can be modified with a regular text editor. The Policy Tool offers a graphical user interface to prevent unintentional syntax errors while modifying a policy file.

8.1.3 JAAS

Access control in the basic Java security model allows granting Permission s to code, based on the code signers and the URL location from which the code is coming. Even though this powerful concept significantly protects Java systems against malicious programs downloaded from the network, this model would be insufficient in an enterprise environment, where the concept of the user running the code is a fundamental component in access-control decisions.

To compensate for this limitation, the basic Java security model was originally complemented with a standard extension framework: Java Authentication and Authorization Service. By using JAAS, it is possible to refine the security policy of a Java system by taking into account the user who runs the code, besides the signer of the code and the location from which the code is coming. Starting with Java 2 SDK V1.4, JAAS has been promoted to become an integral part of the core Java platform. JAAS and its relation to J2EE are discussed in Chapter 9 on page 289.