[cap-talk] Toby's Confused deputy statement (was: Re: Confused deputies in hybrid systems)

[Toby Murray]

On Tue, 2008-02-05 at 10:34 -0500, Jonathan S. Shapiro wrote:
> After about three seconds thought, how about:
> 
>   In any case in which a service may get more PERMISSION than its
>   client gets PERMISSION from a capability passed to it by its client,
>   the service is potentially confusable.
> 

See my later message in which I tried to say the same thing. I also
generalised it further to

In any case in which a service may get more AUTHORITY from a capability
passed to it by its client, than the client can from the same capability
without using the service, then the service is potentially confusable.

How would we measure such a thing?

1. Define the service's authority once it possesses the capability.

2. Define the client's authority with the capability but ignoring all
authority that arises from invoking the service (i.e. all effects the
client can cause by invoking the service).

If 1. includes any effect that is not in 2. then the service is
confusable.
 
Note that if we ignore causation and consider only permission, then thsi
collapses to your definition above.

> I think this is closer to what we want, but I confess that it disturbs
> me. If this is right (and I think that it probably is, modulo further
> refinement), then it follows that the sealer/unseal operation pair
> renders a service potentially confusable.
> 
> > However, as I see it, the service does have more authority than the
> > client, since the client must rely on the service in order to exercise
> > its authority granted by the capability, while the service need not rely
> > on anyone but itself -- it certainly need not rely on the client.
> 
> I said this in another note, but let me repeat it here in the interests
> of maintaining discussion coherence.
> 
> The problem here is one of analytic detail. If we are prepared to
> analyze the behavior of the service (i.e. its program) then it may be
> possible to draw sensible distinctions between the authority of the
> service and the authority of its client.
> 
> But in the absence of such analysis, I believe that we must proceed more
> conservatively, and assume that the service obeys the will of its
> clients. Under this assumption, and excluding other environmentally
> imposed restrictions, the client's authority is presumptively identical
> to the service's authority.
> 

Essentially you're assuming the service is akin to a proxy then?

Something that presents an interface of

invokeCap(c, msg, args)

You send the server a capability, c, and some message name, msg, and
some arguments, args, and it performs the invocation c.msg(args) and
returns the results.

This certainly seems to be the sort of program that is the most likely
to be confused, because it is happy to weild all of its ambient
authority on behalf of all of its clients.