Extensible Security Architectures for Java

Dan S. Wallach, Dirk Balfanz, Drew Dean, and Edward W. Felten
Notes by Kevin Walsh

What do we need?

Browsers need a way of controlling/auditing access to system resources by applets. These applets may be untrusted, fully trusted, or semi-trusted, and multiple applets inter-operate in a single environment.

Access to resources should not be transferable, except under monitored conditions.

Hardware control is generally slow, different across platforms, and does not address much other than kernel-user calls and memory access.

Three options presented

• Stack Introspection (used in Netscape/IE)
  • Every entry into a critical piece of code is wrapped by Enable and Disable calls which turn on/off access to a resource. Only code which is trusted with the resource may Enable it.
  • Access is checked on every invocation by examining stack from newest to oldest -- untrusted code may not access anything; semi-trusted and trusted code may access only if the privilege is enabled in that stack frame.
  • If no untrusted code is found and no (semi-)trusted code has the privilege enabled on the stack, use default privilege.
  • Privileges may be propagated only downwards in the stack.
• Capability Systems
  • Use language constructs (private/public methods and data) for security.  If code has a capability (or reference) to something, then it is allowed to use that resource.
  • Must re-write the system API in places to give out references only if the policy allows it, and not rely on static resource access.
  • Capabilities may be transferred from one module to another easily.
• Name Space Management
  • Build security into the run-time linker. Untrusted code may not link with certain classes, or, certain classes may be re-written on a module by module basis (allowing different levels of access to the resource).
  • This can be done within the current Java implementation by using ClassLoaders.

Remarks

Stack introspection seems inherently bad:  It is not intuitive to the programmer, is very difficult to figure out where rights are propagating, and is not very flexible.   Untrusted code may limited in it's ability to use the security mechanism for it's own purposes (to protect itself against other code).  Also, a run-time search of the stack is involved with every access. Further, if limits are imposed on the depth of the stack search (as is done in some systems), a dependence on an unrelated programming issue (functional code design) is mixed in with security decisions.

Capability systems are very intuitive and are a natural way of having security in Java.   However, it can sometimes be clumsy or difficult to implement certain policies.   Containment of rights is an issue.

Namespace management is also intuitive to programmers, and is very simple to understand.  The paper claims that all security decisions must be made at load time, but this doesn't seem quite right -- security policy decisions must be made at link time (substituting one class for another in the namespace), but access decisions can be dynamically.

All systems presented use the notion of Principals, which is basically the name of the company/person who wrote the code.  I don't think this is what we want.   The name of the author may have some influence on security decisions, but policies should be written on a module by module basis.

Also, the user of the browser is (seems to be) consulted for nearly all policy decisions.  It is specifically forbidden for one module to grant rights to another module.  This seems bad -- the user generally can only make top-level security decisions. Internal decisions should be left up to the module which is exporting a resource.