[cap-talk] Capabilities giving up control?

[Jed Donnelley]

At 09:01 PM 1/17/2008, David Hopwood wrote:
>Toby Murray wrote:
> > Jed, and others who believe that non-delegatable authorities can have no
> > use in security:
> >
> > Why does your drivers' license have your photo on it?
>
>Because a driver's license represents (primarily) the authority to prove
>that a named and photographed person can legally drive. If it were
>delegated, it would still be the authority to prove that *that* person
>can legally drive.
>
>Suppose that a police officer stops my car while I am driving it. He's
>stood at the side of the road to avoid the traffic, so I pass my
>license to the front-seat passenger, who then passes it to the police
>officer.
>
>A non-delegatable capability would be akin to a license that I can't
>let out of my hand for a second, even for the most trivial of delegations
>like this one (which is exactly analogous to passing a capability via
>some helper object that is trusted, but in a separate protection domain).

Interesting point.  It seems to me a bit like my note that the picture
is essentially an authentication.

However, to explore this point a bit further, what about the
argument that this approach (an authority mechanism that
shows that a single subject has an authority) works for
people, why shouldn't it be effective in computer systems?

Just to blue sky a bit, what about a mechanism that authorizes
a single process access to something.  E.g. a message signed
by some authorizer (kernel) that this file is available for
reading to this process.  Like the case of the driver's license,
it can be communicated but doesn't do any more authorizing.
It is effectively non-delegatable.  Would that provide any
useful value?

For me the answer is clearly no.  I see no value in blocking
delegation that can happen by proxy in any case *and* I
believe that the ability to delegate provides the positive
security/integrity value of enabling protected decomposition.
I believe the essential semantics is the important point
here, not the mechanism.  A signed "license" like above
would suffice for non-delegatable authority, the DEMOS
"pass once" capability suffices, even a per process ACL
mechanism (as awkward as that might be) would suffice.

I just believe the semantics are what's not worthwhile
for computer systems.  In my opinion if there is a
reasonable argument that such non-delegatable semantics
are valuable then the object capability model is
rejected as insufficient.  The mechanism that Toby
and Duncan demonstrate in their paper (or any of
the above) won't save it.  It's the basic model that's
insufficient.  If you need non-delegatability to
unconfined subjects then you need a different model
IMO.

--Jed  http://www.webstart.com/jed-signature.html