[cap-talk] Manipulating an object with a secondary reference

David Wagner daw at cs.berkeley.edu
Sun Nov 12 14:30:15 CST 2006

Micah Brodsky <micahbro at csail.mit.edu> writes:
>I've got a simple patters question: What's a good way to manipulate an
>object when named by a weak capability but when the necessary access
>permissions are provided by a different, stronger capability? For example,
>if you're passed an object A with a read-only capability to another object
>B, and you want to manipulate object B with greater permissions than A's
>capability, how should you do it?

I guess I probably don't understand.  More importantly, does the
capability to B provide you with the authority you need to get the
job done?  If it does, why not just use it?  Why do you care about how
you got the capability to B?  A capability is a capability, no matter
where it came from, isn't it?

If the capability to B doesn't provide you with enough authority to
get the job done, then you presumably need to change the interface you
expose so that your client (or the entity who instantiated you) provides
you with all the capabilities you need.

Oh, and: what's a read-only capability?

I'm confused enough that I wonder if we're somehow starting with an
incompatible set of implicit premises, or if we're talking two different
languages, or something.  How do capabilities work in your system?
Where does this problem come from?  Sorry that I am so unhelpful.  Maybe
I am coming with some hidden assumptions that distort my thinking.

>Should you just dig through your own
>capabilities hunting for an applicable one?

Naah.  That's basically re-creating ambient authority, and it is a
recipe for confused deputy vulnerabilities.

>(The particular issue in question is actually for a hybrid MLS-capabilities
>system, a successor design to Asbestos. The problem is how to name the
>capability necessary for declassifying a given taint. In Asbestos, the
>capability was uniquely named by twiddling a few bits on the taint's
>identifier. But, this led to a serious weakness where it was hard to provide
>multiple different facet capabilities for a single object. We want to fix
>this, but if you support many different facets, how do you map between them
>and recognize that they refer to the same object? Having proxies seems like
>it would further complicate this situation, although for now, we're not
>planning to support proxies directly.)

I guess I don't understand.  In a language-based object capability system,
you don't "name" capabilities, you just have an object reference, and that
reference allows you to invoke methods on the reference.  For instance,
I don't think you'd want to have an extra layer of indirection that maps
strings ("names") to capabilities.

I don't understand why you want to "map between facets".  That sounds
like something you shouldn't be doing, and where the only answer to
the question "Given one facet, how do I map it into another facet?"
may be to unask the question and re-examine the premises that led you
to ask that question.

A more interesting question is when you would need to be able to
recognize that two capabilities actually represent two facets to the
same underlying object.  Do you have an example application where this
is needed?  Is it sufficient to ask the object to tell you whether those
two are essentially the same?

More information about the cap-talk mailing list