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

[Jed Donnelley]

cap-talk,

This message is in regard to this dialog:

Toby Murray said:
 >>>> In any case in which a service may get more authority than its client
 >>>> from a capability passed to it by its client, the service is potentially
 >>>> confusable.

Jonathan Shapiro replied:
 >>> 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. In
 >>> consequence, any authority granted thereby to the service already fell
 >>> within the client's authority BY DEFINITION.

I like the conciseness of Toby's statement and I agree
with it.  It seems to me that Toby's statement is one
of fact.  We have examples, e.g. recent Horton examples,
where a service (receiver) gets more authority with
the capability that it receives than its client had
through invocations of the capability.  We know that
such situations result in potential deputy confusion.

Perhaps somebody can suggest how Toby's statement could
be reworded to still convey this basic fact and stay
withing the definitions that Jonathan seems to be
using?

I don't expect anybody but possibly Jonathan will
be interested in the details of the dialog below,
but I will mention that there is a discussion below
about whether confused deputies result from bugs
in their implementations or from a lack of needed
information from their environment.

On 2/4/2008 2:15 PM, Jonathan S. Shapiro wrote:
> On Mon, 2008-02-04 at 13:12 -0800, Jed Donnelley wrote:
>> On 2/4/2008 11:04 AM, Jonathan S. Shapiro wrote:
>>> This is of course false. The use of capabilities as
>>> an underlying permissions substrate does not preclude the presence of
>>> buggy programs.
>> A confused deputy is at least a very special case of a
>> "buggy" program - even if one tries to fit it into that
>> category.  The deputy in the "confused" case doesn't
>> have enough information to know how to proceed, bug
>> or no bug.  Perhaps you could call this a "buggy"
>> architecture, but don't blame the deputy (the program).
> 
> 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).

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

Regardless, I agree that confused deputies can arise in
ambient authority systems and in NON-ambient authority
systems, including pure capability systems (e.g. the
Horton examples).

> One additionally requires a correctly coded deputy.

I thought you just agreed above that in the confused
deputy situation the deputy has insufficient information?
Such confusion will happen even with a "correctly coded deputy",
right?  Sorry to come back to this, but the above sentence
really throws me off and suggests a misunderstanding
somewhere.

> One must take great care in this line of argument not to argue against a
> straw man position. It is not interesting, for our purposes, whether a
> pure textbook ACL system has non-survivable design problems w.r.t.
> deputy confusion. UNIX and Windows are not pure textbook ACL systems.
> 
> What we need to do is study these two systems as "augmented ACL
> systems" (if I may be indulged the coinage) and determine in each case
> whether an augmented ACL system provides a substrate on which deputy
> confusion can be evaded.
> 
> I expect that the answer is "no". I only intend to point out here the
> hazard of comparing false swine to real pearls. :-)

I accept the above, and believe the above reasoning is applicable
to all of our discussions - pure capability, hybrid capability, etc.

>>> Provided that it requires capabilities to be designated (i.e. the
>>> capability portion is not an ambient capability system), a hybrid system
>>> (i.e. one intersectiong capabilities and ACLs) is precisely as
>>> unconfused as the system lacking the intersection restrictions. It is,
>>> in fact, strictly less powerful than the pure system.

>> As David Hopwood pointed out, being strictly less powerful
>> doesn't necessarily make it any less likely to result in
>> confused deputies.
> 
> I am not caught up with the exchanges on this thread, so I haven't read
> David's note.

It's tough.  There has been so much recent activity.  Mea culpa.
Sometimes I have time for these discussions and just want to
bring them to conclusions as quickly as possible.  I'm sure
others vary as to the time they have available.

> I did note one error in his use of the term authority,
> which led directly to a fundamental error in his description of what is
> going on when a capability is transferred from a more restricted to less
> restricted domains. No change in authority takes place in this scenario.

Perhaps if I better understand the above paragraph I will understand
what you're getting at.

Take a case where we have Alice and Bob communicating through
a Horton tunnel.  Alice is sending a Carol serviced file
capability to Bob.  This file is board sensitive.  Bob is
on the board and Alice isn't (your recently proposed
"Use-case:" would be similar).

As I've noted in recent messages, it behooves the Horton
PDP to *not* allow this communicated capability to be used
by Bob to access the board sensitive file.  If it did
(which it could do - it's 'just' a matter of the policy
that Horton implements behind the scenes), then this would
be a situation that could result in a confused deputy (Bob).

I think this is exactly the point Toby was making.  If the
Horton policy was to simply require access through a
capability and that the last delegate be on the board,
then Horton would allow Bob access through the capability
communicated by Alice (above), resulting in, as Toby says,
a situation where "a service may get more authority than
its client from a capability passed to it by its client."

You seem to be arguing that this can't happen Jonathan.
That it is somehow a figment induced by inappropriate word
usage.  While I accept that my word usage may not be
optimal by some standards, a situation as I describe above
can certainly happen.  How would you describe it if not
as Toby did?  How can you say that in a case like that
described above "In consequence, any authority granted
thereby to the service already fell within the client's
authority BY DEFINITION." as you do below?  In the above
example Bob has more authority than Alice as a result
of the capability communicated by Alice.  Do we agree
on wording enough to agree on that statement?

>>From first principles, it seems necessary that his position must rely on
> the assumption that a security-sensitive programs will be implemented
> with less care than the same program in a pure capability system. I see
> absolutely no reason to accept this supposition.

I agree with the above, but don't see how it fits in.
Here is the sequence with Toby followed by you Jonathan,
and then me and you again responding:

Toby:
>>>> In any case in which a service may get more authority than its client
>>>> from a capability passed to it by its client, the service is potentially
>>>> confusable.
<Jed note - I like the conciseness of the above statement>
Jonathan:
>>> 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. In
>>> consequence, any authority granted thereby to the service already fell
>>> within the client's authority BY DEFINITION.
Jed:
>> Hmmm.  The above statement is very interesting.  In the above
>> statement you (Jonathan) seem to be switching the definition of
>> the "capability" term to something more like what I used in my
>> Managing Domains paper - namely, whatever authority is available
>> through an "invoke" interface as opposed to focusing on the
>> token itself.
Jonathan:
> Certainly not. I use the term "permissions" to mean the set of
> operations that can be effected by direct invocation of a capability. I
> use the term "authority" to describe the set of operations that can be
> transitively effected as a consequence of a given capability being in
> the possession of a given subject within a given current system
> configuration. This definition of authority is the one used in Miller's
> thesis, and it includes operational effects that may be obtained as a
> consequence of passing the capability to a third party and requesting
> that the third party perform some operation using that capability.

It was your use of the term "capability" that concerned me.
With the use of the term capability that is common on this
list (referring to a token of permission communicable via
a message), I believe what Toby said is possible as noted
above.  From your response I don't think the definition of
"capability" can be at issue.  There is, however, still
something wrong.  I repeat from Toby's statement:

 >>>> In any case in which a service may get more authority than its client
 >>>> from a capability passed to it by its client, the service is potentially
 >>>> confusable.

to which you responded:

 >>> 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.", I agree with Toby that there are situations
where a service may get more authority than its client.  These
are exactly the situations where confused deputies can come
about via capability communication.

>> I believe that common usage on this list is that a "capability"
>> refers to the token that is communicated in the implementation.
> 
> I have not diverged from that usage, so far as I can tell.

Understood.  In that case the problem is elsewhere as noted above.

>> By that definition I agree with what Toby said.  Any "behind the
>> scenes" state can result in the object/process/domain receiving
>> a capability getting more authority from it than the sending
>> object/process/domain had.
> 
> No. This is not consistent with either MarkM's definitions, Toby's
> formalisms, or my own formalisms. I am not objecting here to the
> intuition that something is wrong in this scenario. The problem here
> lies in the use of the term "authority" to characterize what is wrong.
> My objection is definitional, not conceptual. This either means that we
> need a new term or it means that we need to review our definition of
> "authority".
> 
> And of course there are assumptions being made here about the behavior
> of capability transfer within the hybrid system that need not hold about
> hybrid systems in general.

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.
Certainly I interpreted it that way and I believe it is
true in that context.

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

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