8.2 Java Permissions

8.2 Java Permissions

In the Java language, an authorization , or permission , is the right to access a protected resource. The java.security package provides the abstract class Permission to represent the right to access a resource. The Permission class is subclassed to represent specific access rights. Several subclasses of this class are available in the Java core API.

You can define your own specific Permission classes by subclassing this class or by using available concrete subclasses, such as java.security.BasicPermission . Custom Permission s designed for network distribution can be signed. At runtime, the JVM will check the signature to authenticate the originator of the code.

Although each Permission class subclasses, directly or indirectly, the Permission class in package java.security , specific access rights are represented by Permission classes that are generally part of the package in which they are most likely to be used. For example, the Permission class FilePermission is part of the java.io package, and the SocketPermission class belongs to the package java.net . Figure 8.3 shows the inheritance tree of the most commonly used Permission classes that are part of J2SE.

8.2.1 Permission Target and Actions

Permission s may have a target and an optional list of actions. A target represents a protected system resource, and an action represents the type of access on the resource. For example, in java.io.FilePermission "C:\AUTOEXEC.BAT", "read, write, execute" , the target object is the local file C:\AUTOEXEC.BAT , and the actions are read, write, and execute. Some Permission s have only a target. For example, the java.lang.RuntimePermission with target "exitVM" protects the JVM against those codes that attempt to exit the JVM, but no action list is associated with this type of resource. Finally, some Permission s may not have a target. This is the case, for example, for java.security.AllPermission , which grants code full access to all the system resources.

8.2.2 The PermissionCollection and Permissions Classes

Associated with the Permission class are also the abstract class java.security.PermissionCollection and the final class java.security.Permissions . The former represents a collection of homogeneous Permission s, such as a set of FilePermission s. The latter is a PermissionCollection subclass and is used to group heterogeneous Permission objects, organized into PermissionCollection s. The relation between the classes Permission , PermissionCollection , and Permissions is shown in Figure 8.4.

Permission classes are responsible for defining the type of PermissionCollection in which they should be grouped. The type of PermissionCollection is defined by overriding the newPermissionCollection() method inherited from the Permission superclass.

8.2.3 The implies() Method in the Permission Class

When implementing a subclass of the Permission class, it is crucial to implement the abstract method implies() , which returns a boolean . Here, a implies b means that granting an application Permission a automatically grants it Permission b too. For example, giving some code AllPermission implies giving all the rest of the Permission s. Similarly, the Permission java.io.FilePermission "/tmp/*", "read" implies the Permission java.io.FilePermission "/tmp/readme.txt", "read" .

The BasicPermission class offers a simple implementation of the implies() method, which is sufficient in most cases for those custom Permissions that have only a target. If the custom Permission requires the concept of an action too, it is advisable to directly subclass the Permission class.

8.2.4 The implies() Method in PermissionCollection and Permissions

The PermissionCollection class also has an implies() method that takes a Permission object as a parameter and returns a boolean . Because Permissions subclasses PermissionCollection , an implies() method that takes a Permission object as a parameter and returns a boolean is also available in the Permissions class.

When implies() is invoked on a Permissions object with a Permission parameter, the Permissions object invokes the implies() method on the PermissionCollection of the specified Permission parameter, passing it the Permission object as a parameter. The PermissionCollection object, in turn , invokes the implies() method with the same Permission parameter on the Permission objects that it contains. The implies() method of the Permissions object returns true if and only if the implies() method of the PermissionCollection object returns true , which happens if and only if the combination of the Permission objects in the PermissionCollection implies the specified Permission .

8.2.5 Permission s Implicitly Equivalent to AllPermission

From what we said about AllPermission , it is clear that much caution is needed when granting this Permission . In this section, we study other Permission s that are implicitly equivalent to AllPermission . Extreme care should be used when granting AllPermission and any of the following Permission s.

• Permission to define the system's SecurityManager . If a code has been granted java.lang.RuntimePermission "createSecurityManager" and java.lang.RuntimePermission "setSecurityManager" , that code is allowed to create and set a new SecurityManager , respectively. However, that code is implicitly granted AllPermission too because the SecurityManager it installs has the authority to enforce its own security policy and may choose to allow access to protected system resources with no restrictions.

• Permission to create a ClassLoader . If a code has been granted java.lang.RuntimePermission "createClassLoader" to create a new java.lang.ClassLoader instance, that code has been potentially granted AllPermission . In fact, a new ClassLoader could choose not to respect the delegation hierarchy, which means that untrusted classes would be allowed to replace trusted classes, including the SecurityManager , thus subverting the security of the JVM. Additionally, because the ClassLoader assigns Permission s to loaded classes, based on the current policy, a malicious ClassLoader could choose to assign AllPermission to particular classes, regardless of the Java system administrator's security policy settings.

• Permission to execute native code. Java code that has been granted java.lang.RuntimePermission "loadLibrary. library_name " is allowed to execute native code. This Permission , however, is implicitly equivalent to AllPermission . In fact, because it runs directly on the underlying operating system, native code bypasses all the Java security restrictions and could potentially steal private information or modify the underlying system.

• Permission to set the system's security policy. Java code that has been granted java.security.SecurityPermission "setProperty.policy.url.1" to set the security property pointing to the current systemwide policy database is equivalent to AllPermission because the systemwide security policy may grant a hacker all the necessary authorizations to successfully mount an attack on the system.