Extensible Security Architectures for Java

Summary: Presents three techniques for implementing extensible
security policies in Java (that is, policies less restrictive than the
Java 1.0 sandbox).

Overview:

* Three techniques:
  1) Capabilities -- check for permission up front, and then provide
    an unforgeable (type-safe) pointer.
  2) Namespace management -- provide different implementations of
     system classes based on code origin
  3) Stack inspection -- before executing security-critical code, look
     at the stack to see who the caller is.

* Bottom line: all three techniques are potentially secure, but
  provide different tradeoffs (usability, ease-of-implementation,
  etc.)

Comments:

* Like most security papers, this work concentrates on security
  mechanisms at the total expense of security policy.  No discussion
  of how or where these policies are coming from.  The policy problem
  is even harder here than the OS because the security principal is
  code origin instead of a user or a process. The sandbox model
  was restrictive, but at least it obviated security policy.

* All of this relies on specific features of Java--type safety in
  particular.  On at least one occasion, this has been subverted (see
  reference 8 of this paper).  More generally, the JVM has a checkered
  past when it comes to security vulnerabilities.