Adventures in the programming jungle

Java Security Architecture

Main Concepts :

• Protection Domain ( java.security.ProtectionDomain )

A fundamental concept and important building block of system security is the protection domain . A domain can be scoped by the set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which permissions are granted.

The protection domain concept serves as a convenient mechanism for grouping and isolation between units of protection. For example, it is possible (but not yet provided as a built-in feature) to separate protection domains from interacting with each other so that any permitted interaction must be either through trusted system code or explicitly allowed by the domains concerned.

Protection domains generally fall into two distinct categories: system domain and application domain.
It is important that all protected external resources, such as the file system, the networking facility, and the screen and keyboard, be accessible only via system domains.

A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Protection domains are determined by the policy currently in effect. The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions, as illustrated by the figure below.

• Permissions ( java.security.Permission )

The permission classes represent access to system resources. In essence, permissions determine whether access to a resource of the JVM is granted or denied. The java.security.Permission class is an abstract class and is subclassed, as appropriate, to represent specific accesses.

An applet or an application using a security manager can obtain access to a system resource only if it has permission.

Commonly used permissions :

1. java.security.Permission This abstract class is the ancestor of all permissions. It defines the essential functionalities required for all permissions.
2. java.security.BasicPermission The BasicPermission class extends the Permission class. It can be used as the base class for permissions that want to follow the same naming convention as BasicPermission.
3. java.security.Permissions This class is designed to hold a heterogeneous collection of permissions. Basically, it is a collection of java.security.PermissionCollection objects.
4. java.io.FilePermission
5. java.net.SocketPermission This class represents access to a network via sockets.
6. java.util.PropertyPermission
7. java.lang.RuntimePermission
8. java.awt.AWTPermission

• Policy (java.security.Policy)

The Java 2 security policy defines the protection domains for all running Java code with access privileges and a set of permissions such as read and write access or making a connection to a host.

The system security policy for a Java application environment, specifying which permissions are available for code from various sources, is represented by a Policy object. More specifically, it is represented by a Policy subclass providing an implementation of the abstract methods in the Policy class.

In order for an applet (or an application running under a SecurityManager) to be allowed to perform secured actions, such as reading or writing a file, the applet (or application) must be granted permission for that particular action.

In the Policy reference implementation, the policy can be specified within one or more policy configuration files. The configuration files indicate what permissions are allowed for code from specified code sources. Each configuration file must be encoded in UTF-8.

A user or an administrator externally configures the policy file for a J2SE runtime environment using an ASCII text file or a serialized binary file representing a Policy class. In a J2SE environment, the default system-wide security policy file java.policy is located at <JRE_HOME>/lib/security/ directory. The policy file location is defined in the security properties file with a java.security setting, which is located at <JRE_HOME>/lib/security/java.security.

Examples of policies :

The following policy grants permission a.b.Foo to code signed by Roland:

grant signedBy "Roland" {
permission a.b.Foo;
};

The following grants a FilePermission to all code (regardless of the signer and/or codeBase):

grant {
permission java.io.FilePermission ".tmp", "read";
};

The following grants two permissions to code that is signed by both Li and Roland:

grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.util.PropertyPermission "user.*";
};

The following grants two permissions to code that is signed by Li and that comes from http://java.sun.com:

grant codeBase "http://java.sun.com/*", signedBy "Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.io.SocketPermission "*", "connect";
};

The following grants two permissions to code that is signed by both Li and Roland, and only if the bytecodes implementing com.abc.TVPermission are genuinely signed by Li.

grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission com.abc.TVPermission "channel-5", "watch",
signedBy "Li";
};

• Access Controller (java.security.AccessController)

The AccessController class is used for three purposes :

1. to decide whether an access to a critical system resource is to be allowed or denied, based on the security policy currently in effect,
2. to mark code as being “privileged”, thus affecting subsequent access determinations.
3. to obtain a “snapshot” of the current calling context so access-control decisions from a different context can be made with respect to the saved context.

• SecurityManager ( java.lang.SecurityManager )

Each Java application can have its own security manager that acts as its primary security guard against malicious attacks. The security manager enforces the required security policy of an application by performing runtime checks and authorizing access, thereby protecting resources from malicious operations.
Under the hood, it uses the Java security policy file to decide which set of permissions are granted to the classes. However, when untrusted classes and third-party applications use the JVM, the Java security manager applies the security policy associated with the JVM to identify malicious operations. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. In cases where the SecurityManager detects a security policy violation, the JVM will throw an AccessControlException or a SecurityException.

In a Java application, the security manager is set by the setSecurityManager method in class System. And the current security manager is obtained via the getSecurityManager method.

If you wish to have your applications use a SecurityManager and security policy, start up the JVM with the -Djava.security.manager option and you can also specify a security policy file using the policies in the -Djava.security.policy option as JVM arguments. If you enable the Java Security Manager in your application but do not specify a security policy file, then the Java Security Manager uses the default security policies defined in the java.policy file in the $JAVA_HOME/jre/lib/security directory.

• SecurityManager versus AccessController

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.

Java Applet Security

Currently, all Java 2 SDK system code invokes SecurityManager methods to check the policy currently in effect and perform access control checks. There is typically a security manager (SecurityManager implementation) installed whenever an applet is running; the appletviewer and most browsers, including those from Netscape and Microsoft, install a security manager.

A security manager is not automatically installed when an application is running. To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java Virtual Machine with the new “-Djava.security.manager” command-line argument (which sets the value of the java.security.manager property), as in

java -Djava.security.manager SomeApp

or the application itself must call the setSecurityManager method in the java.lang.System class to install a security manager.

It is possible to specify on the command line a particular security manager to be utilized, by following “-Djava.security.manager” with an equals and the name of the class to be used as the security manager, as in

java -Djava.security.manager=COM.abc.MySecMgr SomeApp

Trusted applets

An applet can be considered trusted, based on the following factors:

1. Applets installed on a local filesystem or executed on a localhost.
2. Signed applets provide a way to verify that the applet is downloaded from a reliable source and can be trusted to run with the permissions granted in the policy file.

The Java 2 platform requires an executable applet class to be packaged into a JAR file before it is signed. The JAR file is signed using the private key of the applet creator. The signature is verified using its public key by the client user of the JAR file. The public key certificate is sent along with the JAR file to any client recipients who will use the applet. The client who receives the certificate uses it to authenticate the signature on the JAR file. To sign the applet, we need to obtain a certificate that is capable of code signing. For all production purposes, you must always obtain a certificate from a CA such as VeriSign, Thawte, or some other CA.

A trusted applet is executed as a normal application (it follows the policy file).

Untrusted applets

Here is a list of the security restrictions that Java 2 technology environments normally impose on applets running in a browser:
1. An applet can utilize only its own code and is not allowed to load libraries or define native methods.
2. An applet cannot read or write files on the host that is executing it.
3. An applet can make network connections only to the host from which it was downloaded.
4. An applet cannot start any program on the local host.
5. An applet is restricted from reading the following system properties: java.home, java.classpath, user.name, user.dir, user.home

Java WebStart Security

When you launch one of the applications shown in the Java WebStart desktop, the classes needed to run that application are downloaded from the Web server.
This behavior is similar to that of an applet. However, once downloaded, the classes are stored locally. This allows for a faster startup on subsequent uses of the application. Better yet, each time you try to run that application, the system checks to see if any updates are available
on the Web server, and if any updates exist, just the needed changes are downloaded. This ensures that the application is always ready to run, even if your computer is not connected to the network, while also ensuring that the most up-to-date version possible is used. All this occurs with no need for an installation phase.

JWS also allows defining security attributes for client-side Java applications and their access to local resources, such as file system access, making network connections, and so on. These security attributes are specified using XML tags in the JNLP descriptor file.

The JNLP descriptor defines the application access privileges to the local and network resources. In addition, JWS allows the use of digital signatures for signing JAR files in order to verify the application origin and its integrity so that it can be trusted before it is downloaded to a client machine. The certificate used to sign the JAR files is verified using the trusted certificates in the client keystore. This helps users avoid starting malicious applications and inadvertent downloads without knowing the originating source of the application.

When running an application that requests unrestricted access to the local machine, the user will be initially presented with a dialog that explains the origin of the application or vendor and allows the user to grant additional privileges to the application. Furthermore, when an application requires the use of a local machine’s resources and does not have a signed JAR file, Java Web Start will allow the user to explicitly grant the application the access via a Security Advisory dialog. For example, if a client Java application needed to be able to paste information into the Windows OS clipboard facility, a dialog box similar to the one shown in the next figure would appear.

Security Advisory dialog for application attempting to access the clipboard

Additional dialog windows will appear when an application attempts to access the local resources of a client machine, such as the filesystem, as displayed in the next figure.

Security Advisory dialog for application attempting to access the filesystem

Users can grant applications access to the local machine in the following areas:

1. Storing the current state of the application on the local machine
2. Viewing the contents of local files
3. Saving files to the local machine
4. Opening files to the local machine
5. Reading/writing to random access files on the local machine
6. Printing from the local machine

JNPL file

The root element is tagged as <jnlp>, which contains the four core sub-elements: information, security, resources, and application-desc.

To enforce security, the <security> element is used to specify the required permissions. The security element provides two permission options: <all-permissions/> to provide an application with full access to the client’s local computing resources, and <j2ee-application-client-permissions/> to provide a selected set of permissions that includes socket permissions, clipboard access permission, printing permission, and so forth. Example 3-19 is a JNLP file that shows putting all the elements including a <security> element setting with all permissions.
Example of JNLP file showing <security> elements

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="file:///c:/testarea/jnlp/">
<information>
<title>My Signed Jar</title>
<vendor>Core Security Patterns</vendor>
<homepage href="http://www.sec-patterns.com/signed" />
<description>Java Web start example</description>
</information>
<offline-allowed/>
<security>
<all-permission/>
</security>
<resources>
<j2se version="1.2+" />
<jar href="SignedClientApp.jar"/>
</resources>
<application-desc main-class="SignedClientApp" />
</jnlp

Bibliography:

Mikalai Zaikin SCEA 5 study guide
Java Web Start
Java Security Management Tools
JavaTM Web Start version 1.5.0 – Frequently Asked Questions (FAQ)
Java^TM 2 Platform Security Architecture (V 1.2)