[cap-talk] Stack walking is capability access control?

David Hopwood david.hopwood at industrial-designers.co.uk
Tue May 15 17:04:23 EDT 2007


Sandro Magi wrote:
> There's an interesting PhD proposal to develop a safe reflection
> mechanism that does not violate the parametricity of abstract types [1].
> [1] http://www.cis.upenn.edu/~geoffw/research/papers/phd-proposal.pdf
> 
> In his analysis, the author examined various approaches to controlling
> access to this private state, including capabilities (Section 2.2), but
> he classifies stack walking as capability-based access control:
> 
>   A well-known capability based access control mechanism is the stack
>   inspection based access control introduced in version 1.2 of the Java
>   Virtual Machine (JVM) (Lindholm and Yellin 1999).

Stack walking is not capability-based (certainly not as designed or
implemented in Java 1.2 or later).

> This seems wrong, since stack walking is an implicit subject-based
> security check, rather than object-based. Is that the important
> distinction here, or is it something else?

Yes. Comparing the Java/JVM security model and capabilities, we have:

Similarities:
 - possession of a reference to an object is necessary to invoke it.

 - security partially depends on restricting the object references that
   subjects hold. (In a JVM instance there exist references, possession
   of which would be sufficient to break security regardless of the stack
   checking mechanism.)

Differences:
 - in a capability system, possession of an object reference is always
   sufficient to access it, regardless of the identity of the invoker.
   The object may implement additional access checks dependent on its
   state, but these are not based on the identity of (direct or indirect)
   invokers, unlike the checks done by stack walking.

 - in a pure capability system, an invoked object *cannot* determine the
   identity of any of its invokers (except indirectly by knowing which
   subjects might possess a reference to it).

 - the Java model allows global access to authority-granting objects
   (e.g. new File(pathname)), so it cannot implement confinement, and
   the requirement to possess a reference to an object in order to invoke
   it is not sufficient as a security measure.

The last of these differences makes Java/JVM a non-capability model,
as opposed to a hybrid of capabilities and stack walking. Also, the
stack checks act as an obstacle to delegation, which is essential in
capability-based designs.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>



More information about the cap-talk mailing list