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

Geoffrey Alan Washburn geoffw at cis.upenn.edu
Tue May 15 18:37:29 EDT 2007


David Hopwood wrote:

> 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.

	I cannot really address what you've said without knowing which set of 
definitions you are working from.  You seem to be assuming a rather 
complicated notion of capabilities.  For my purposes, I am defining a 
capability as a "token" that can be used to perform some action.  Given 
that, "plain vanilla" stack inspection can be abstractly seen as 
capability based access control.  Why?  Because every program written 
against a stack inspection model can be transformed, for example by a 
continuation passing transformation, into one where a capability is 
passed from function to function during invocation.  All that is 
happening in stack inspection is that you are storing the capabilities 
on the stack.  For more information on this I suggest looking at 
Pottier, Skalka, and Smith's paper "A Systematic Approach to Static 
Access Control" to see how this may be done.



More information about the cap-talk mailing list