Java Security - Enforcement

Java Security - Enforcement
An Introduction to the Internals

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Overview/Review

The Architecture:
- Many participants are involved in Java security
Specification:
- Some of the participants involved in specification are Permission and Policy
Enforcement:
- The topic of this lecture

The SecurityManager

Class

Purpose:
- It is used whenever an enforcement decision needs to be made (i.e., whenever a decision must be made to grant or deny a request)
A "Meta" Point:
- SecurityManager objects need to be protected so only code granted the RuntimePermission with name "createSecurityManager" can construct one

The SecurityManager Class (cont.)

public Object getSecurityContext():
- Returns an encapsulation of the current execution environment
public void checkPermission(Permission permission, Object context):
- Throws a SecurityException (which is an unchecked exception) if the Permission is not granted

The SecurityManager Class (cont.)

An Important Design Consideration:
- Applications might need very different kinds of security (e.g., multilevel security vs. separation-of-duty security) and the SecurityManager class is flexible enough to support this
A Drawback:
- Implementing a SecurityManager is difficult

The AccessController

Class

Purpose:
- A complete access control algorithm
How it Works:
- The checkPermission() methods in SecurityManager delegate to an AccessController object by default

The AccessController Class (cont.)

public static void checkPermission(Permission permission):
- Checks whether the given Permission is allowed in the current execution context (and throws an AccessControlException if it isn't)
public static AccessControlContext getContext():
- Returns the current execution context

The AccessController Class (cont.)

The Algorithm:
- A request is granted if and only if every relevant ProtectionDomain grants the requested Permission
An Observation:
- This is sometimes referred to as the principle of least privilege

Using the ProtectionDomain and/or Policy Objects

Given Static Permissions Only:
- The public boolean implies(Permission permission) method is called to see whether the Permission is granted
Given Some Dynamic Permissions:
- The public boolean implies(ProtectionDomain domain, Permission permission) method of the current Policy is called to to see whether the Permission is granted

A Note about Polymorphism and Inheritance

The Situation:
- A subclass inherits (and does not override) a method from a superclass
- The two classes belong to different ProtectionDomain objects
The Issue:
- When a message is sent to an object of the subclass, which ProtectionDomain should be used?
The Resolution:
- The ProtectionDomain of the class containing the code that is executed is used

A Note about Polymorphism and Inheritance (cont.)

A Different Situation:
- A subclass overrides a method from a superclass
- The two classes belong to different ProtectionDomain objects
What Happens?
- If the method in the subclass calls the method in the superclass then both ProtectionDomain objects are used, otherwise only the ProtectionDomain of the subclass is used

Privileged Operations

The Situation:
- Sometimes one object needs to temporarily grant its permissions to another object
The Solution:
- AccessController has a public static Object doPrivileged(PrivelegedAction action) method that tells the runtime the caller is exercising its permissions

Privileged Operations (cont.)

How It Works:
- The Command Pattern (i.e., a class that realizes the PrivelegedAction<T> interface must have a public T run() method)

The Outline of an Example:

public class ChangePassword implements PrivilegedAction<String>
{
    // Attributes and other methods

    public String run()
    {
      String      result;

      // Do whatever needs to be done

      return result;
    }
}

ChangePassword     action;

action = new ChangePassword(oldPassword, newPassword);
AccessController.doPriveleged(action);

An Important Option

An Observation:
- Though AccessController was created to be the default delegate for SecurityManager it can be used on its own
Some Considerations:
- Even if a SecurityManager has not been installed you can use the static methods in AccessController
- Someone might have installed a custom specialization of SecurityManager so if you want to ensure that AccessController is used you can use it directly