• What is Being Specified:
  • The system resources that may be accessed by a section of code
• What the Specification Looks Like:
  • A mapping from code properties (when running) to a set of permissions

• The Architecture:
  • Many participants are involved in Java security
• Specification:
  • The topic of this lecture
• Enforcement:
  • Some of the participants involved in enforcement are SecurityManager and AccessController

• Defined:
  • The operations that can be performed on a system resource
• Encapsulation:
  • The Permission class
• Important Attributes:
  • Name
  • A list of actions (which is optional if the Permission is just allowed or disallowed)
• Important Methods:
  • abstract boolean implies(Permission other) returns true if this Permission implies other (i.e., if other is a subset of this)

• Two Important Notes:
  • Permission objects represent positive permissions (i.e., approvals) so the absence of a particular permission is implicitly a denial
  • Permission objects are immutable
• Part of the Class Hierarchy:
  • 

An Example

Permission    dataread, exit;

// An example with an action
dataread = new FilePermission("/data/census", "read");

// An example without an action
exit = new RuntimePermission("exitVM");
  

• AllPermission :
  • A "wildcard" (i.e., implies() always returns true) that should only be used sparingly (e.g., to perform system administration)
• BasicPermission :
  • An abstract class that is convenient to specialize when creating permissions that do not have actions

• public abstract String getActions():
  • Returns a String representation of the actions (usually comma-delimited)
• public abstract boolean implies(Permission other):
  • Returns true if this object's actions imply the other object's actions (i.e., if other is a subset of this)

• The Class:
  • PermissionCollection
• Properties:
  • Allows duplicates
• The implies() Method:
  • Returns true if other is implied by the collection

• A Note:
  • PermissionCollection is not parameterized but the formal parameter of the add() method is a Permission
• When You Need Strictly Homogenous Collections:
  • Use the factory method newPermissionCollection() in the Permission class to construct the PermissionCollection
• When You Need Heterogenous Collections:
  • Use the Permissions class (which is actually a collection of strictly homogenous PermissionCollection objects)

• Conflicts are Impossible:
  • Access granted by one Permission can't be denied by another
• Efficiency:
  • The implies() method in the PermissionCollection class can use short-circuiting
• Some Things are Inconvenient:
  • For example, it is tedious to grant all accesses except one

• Remember:
  • We are trying to create a mapping from code properties (when running) to a set of permissions
• Where We Are:
  • We have a way to describe permissions
• What We Need:
  • A way to describe the properties of code when it is running

• Origin (and Authentication Mechanism):
  • Encapsulated in the CodeSource class
• Accountability (i.e., Who/what is the code is running on behalf of?):
  • Encapsulated in the Principal interface

• Constructor:
  • public CodeSource(URL url, Certificate[] certs)
• public boolean implies(CodeSource other):
  • Returns true if other is a subset of this (e.g., http://cs.jmu.edu/ is a subset of http://jmu.edu/) and all of other's certificates are included in this's

• Formal Purpose:
  • A representation of an entity (e.g., an individual, group, or service) to which authorizations/accountability may be attributed
• Informal Purpose:
  • Who/what is running the code

• A ProtectionDomain Object Contains:
  • A CodeSource object
  • A collection of Principal objects
  • A ClassLoader object
  • A PermissionCollection object
• What Happens:
  • When it is loaded, a class is associated with a ProtectionDomain object
  • The JVM maintains a mapping from classes to ProtectionDomain objects

• Some Details:
  • ProtectionDomain objects are normally created by a ClassLoader
  • A ProtectionDomain is only created the first time a CodeSource is encountered (so all classes with the same CodeSource are mapped to the same ProtectionDomain)
• The System Domain:
  • All classes that are part of the core, trusted computing base (i.e., the classes loaded by the bootstrap class loader) are part of the system domain and are granted all permissions (even though they have a null class loader)

• Classes vs. Objects:
  • Permissions are granted to classes (as identified by their CodeSource and ClassLoader) not individual objects
• Static and Dynamic Permissions:
  • Some Permission objects may be bound to a ProtectionDomain at load-time (e.g., by the ClassLoader)
  • Some Permission objects may not be bound to a ProtectionDomain until the ProtectionDomain is used for a security check (e.g., by the Policy)