- Forward


Java Security - Specification
An Introduction to the Internals


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Getting Started
Back SMYC Forward
  • 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
Overview/Review
Back SMYC Forward
  • 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
Permissions
Back SMYC Forward
  • 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)
Permissions (cont.)
Back SMYC Forward
  • 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:
    • permissions
Permissions (cont.)
Back SMYC Forward

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");
Details About Some Existing Specializations
Back SMYC Forward
  • 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
Specializing the Permission Class
Back SMYC Forward
  • 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)
Collections of Permissions
Back SMYC Forward
  • The Class:
    • PermissionCollection
  • Properties:
    • Allows duplicates
  • The implies() Method:
    • Returns true if other is implied by the collection
Collections of Permissions (cont.)
Back SMYC Forward
  • 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)
About Positive Permissions
Back SMYC Forward
  • 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
A Brief Recap
Back SMYC Forward
  • 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
The Fundamental Properties of Code
Back SMYC Forward
  • 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
The CodeSource Class
Back SMYC Forward
  • 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
The Principal Interface
Back SMYC Forward
  • 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
Putting the Pieces Together
Back SMYC Forward
  • 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
Putting the Pieces Together (cont.)
Back SMYC Forward
  • 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)
Things to Be Aware Of
Back SMYC Forward
  • 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)
There's Always More to Learn
Back -