Code Centric Security Model

Java Security Series Part 2

Security model

One of the important goals in a secure system is to protect critical resourses. In this context a protection domain is a concept which defines all the entities that can access a particular or group of critical resourses. This concept is extrapolated in Java and is abstracted in java.security.ProtectionDomain class. The protection domain in Java encompasses two details -

• What (code) can access critical resourse - Code Centric Security model
• Who (user) can access critical resourse - User Centric Security model

Code Centric Security Model

With the original Java 1.0, any Java code on the local machine could access any resourse such as file system, runtime properties, network etc as the local applications were completely trusted and were thought to be safe. Only the applications which were remote, as in applets were seen with caution and subjected to security. In this system, the applet code was made to run in what is called "Sand Box" which is nothing but a protection domain for the applet code which has no access to a fixed set of critical resourse.

However, with the introduction of Signed applets in Java 1.1, this sand box was made configurable with applets from different code sources (applet written by different signers and downloaded from different location) could do different things in the sand box. User based on the trust on a signer and location could lax the strict sand box; however, the sand box itself was still protecting only a fixed set of critical resource and hence the Protection domain here was said to be with a fixed boundary.

With the introduction of Java 2 Platform Security in Java 1.2, a regular security framework was designed. In this framework, all code belongs to a Protection Domain and the protection domain determines the resources that are accessible to the code. The protection domain here itself is NOT of fixed boundary as the means to define a critical resource is extensible.

java.security.Persmission

This class abstracts the permissible access on a particular resourse. Java provides a hierarchy of sub-classes from this parent class to provide the notion of different types of access on different resources. For example, FilePermission, SocketPermission etc to specify access to file system resources and network resources.

By further sub-classing this class, custom resource access can be defined - and this is crux to a flexible boundary Protection Domain.

A permission object typically has two attributes - (1) target name - name of a particular target object of a particular type of resource; for example a file named C:\Sandesh.doc (2) action list - all the access privileges on the target object - such as read, write etc.

java.security.ProtectionDomain

This class abstracts the permissible activities that a particular trusted code (trust here implies on the author of the code and the location of download of the code) can perform.

As and when a class is loaded by the class loader, the class loader initializes the Class instance with the protection domain to which it belongs.

In Java 1.4, it encapsulates mainly 3 entities - (1) CodeSource (2) Permissions (3) Principals

java.security.CodeSource

This class abstracts the trusted entity based on which protection domains work and as explained consists of (1) signer of code (2) location of code download

Initialization of ProtectionDomain for a Class instance

As we saw earlier, there are three default class loaders that get installed when JVM is started - (1) Bootstrap class loader (2) Extensions class loader (3) System class loader.

These class loaders are responsible for assigning the right Protection Domain during when defining a class. Bootstrap class loader is of native type and assigns all the System classes (classes present in jre/lib/rt.jar) to System Protection Domain which has AllPermission access rights.

The extension and system class loaders are of type java.net.URLClassLoader which inturn inherits from java.security.SecureClassLoader.

While the extensions class loader loads classes from jre/lib/ext directory and system class loader loads from the CLASSPATH environment variable, their intialization process of the protection domain of classes loaded by them is the same as both of them are of the same type.

java.net.URLClassLoader overrides findClass as expected and here, it first gets the raw bytes from the URLs it knows about and then from the same also gets the signer information and from this constructs a CodeSourse object and then calls defineClass, to define the class.

java.security.SecureClassLoader overrides defineClass. SecureClassLoader maintains a cache of ProtectionDomain using a HashMap with key being the code sourse. It first checks if the ProtectionDomain for the given code sourse is already present in the cache and reuses if cached. Otherwise, it calls getPermissions to get an initial set of permissions for the protection domain. This function is overridden by URLClassLoader which inserts an initial set of permission which allows the code source to -

• If the protocol specified by URL is "file" and the path specified by the URL is a file, then read permission to that file is granted
• If the protocol specified by URL is "file" and the path specified by the URL is a directory, then read permission to all files and directories recursively
• If the protocol specified is anything else, permissions to connect to and accept from URL's network host is allowed.

Please note that SecureClassLoader.getPermissions returns an empty set of permissions because it has no idea on what permissions to give [Note: In JDK 1.3, this method actually initialized the initial permissions with permissions read from java.security.Policy.getPermissions(CodeSource) method. But it seems to support dynamic policies, this has changed in 1.4 and has kind of become redundant.]. SecureClassLoader.defineClass then constructs a java.security.ProtectionDomain object using the code source instance, class loader instance and the initial permissions and associates the ProtectionDomain with the Class.

java.security.PermissionCollection and java.security.Permissions

These are two kinds of containers for the permission objects and the difference between the two being that PermissionCollection is a homogenous set of Permission objects where as Permissions are heterogenous.

Binding permissions to ProtectionDomain

Protection Domain provides a mapping between code source and its permissions. In Java 1.2, SecureClassLoader's getPermissions method read java.security.Policy for the configured permissions for a particular code source. Policy object here is used to decouple the policy configuration from the security framework. Policy is itself an abstract class and expects a provider to provide the actual permissions for the code source. This way, users can plugin custom access management systems to the security framework. By default com.sun.security.PolicyFile gave an implementation where the users could configure permissions in an ASCII file.

Static binding of permissions to Protection Domain is not always a good idea. There are some access management systems which can specify if a security context has a particular permission, but cannot specify all the permissions available for a security context. Also, if permissions are to be more dynamic in nature, static binding will not obviously work. In Java 1.4, dynamic policy binding was introduced. Here, the interaction between ProtectionDomain and Policy object has changed. The way it works in 1.4 is - (1) SecureClassLoader no longer asks the Policy object for permissions during creation of ProtectionDomain object, but returns an empty permissions list (2) Protection domain when queried if a particular permission is implied, first checks the policy if a particular permission is implied. This causes the dynamic behavior, as the permissions are never really bound to the ProtectionDomain object, but loosely coupled using the Policy object. (3) Only if the Policy object does not imply the permission, does the default permissions in the Protection domain object consulted.

By default the policy implementation used is com.sun.security.auth.PolicyFile. A different implementation can be configured by changing the security settings in jre/lib/ext/security/java.security file.

com.sun.security.auth.PolicyFile initializes the permissions by reading jre/lib/ext/security/java.policy file. This configuration can be changed by editing policy.url properties specified in jre/lib/ext/security/java.security