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

[Jonathan S. Shapiro]

On Mon, 2008-02-04 at 17:00 -0800, Jed Donnelley wrote:
> On 2/4/2008 2:15 PM, Jonathan S. Shapiro wrote:
> > I did not say that ambient authority systems could somehow avoid the
> > possibility of a confused deputy. I agree that in such a system, the
> > deputy has insufficient information.
> 
> And I assume you also agree that even in a pure capability
> system like Horton where a confused deputy situation can
> occur with an inappropriate PDP, the deputy has insufficient
> information and so can't be "correctly coded" (below).

I haven't followed the discussion closely enough to know what "PDP"
stands for, and years later I still don't understand what a Horton
system is (because I have never read a consolidated description -- it
may have gone by and I missed it).

Because of this, I can't state an opinion on your question.

> > What I said was that the use of a NON-ambient authority system (we need
> > a catchy term for that) is also insufficient.
> 
> Is there any loss of generality in referring to such systems
> as capability systems?  Do we have examples of NON-ambient
> authority systems that aren't capability systems?  How
> else can NON-ambient authority show up?  Just curious.

I don't know of one today, but I choose not to preclude the possibility
of other non-ambient designs. Split capabilities, at least, appear to
raise an interesting challenge case to consider here.

> > One additionally requires a correctly coded deputy.
> 
> I thought you just agreed above that in the confused
> deputy situation the deputy has insufficient information?

No. I agreed that in an ambient authority system the confused deputy has
insufficient information. In a non-ambient authority system, the
confused deputy may or may not have sufficient information (per some of
the other discussions). Assuming that it DOES have sufficient
information, it can still be confused as a consequence of flawed design
or implementation.

> Such confusion will happen even with a "correctly coded deputy",
> right?

Evidently not, since there do exist examples of UNIX applications
deputizing for multiple parties that appear, in practice, not to become
confused. Granted they are (very) rare, but they exist.

This is why I stated yesterday that we should not argue against straw
men (pure paper ACL systems) but against real, working designs
(typically some form of augmented ACL system).

>  >>> Your statement confuses permission with authority. The service did not
>  >>> get more authority than its client held. The client had sufficient
>  >>> authority to pass the capability into the service domain.
> 
> Why do you believe Toby's statement confused permission with
> authority?  While your last sentence in the above is certainly
> true "The client had sufficient authority to pass the capability
> into the service domain."

Sorry. That should have read "... has sufficient PERMISSION ...".
Authority subsumes this, but the statement was imprecise.

> , I agree with Toby that there are situations
> where a service may get more authority than its client.

Then you share Toby's misuse of terms.

> I believe Toby's statement was intended to apply to any
> sort of a system (pure capability or hybrid) in which
> authority is communicated with capability delegation.

No such system exists. Definitions again. Authority is not communicated
with capability delegation. Authority is an emergent property. What is
communicated with capability delegation is PERMISSIONS.

> Might the confusion be that you are denying that Toby's
> statement applies to some particular implementation?

No. As I said very clearly, I am denying that Toby's choice of technical
terms is appropriate to the point that he is trying to make.

I believe this matter is best clarified by my comments about program
analysis elsewhere.


shap