[cap-talk] Confused deputies in hybrid systems (weekend activity apology)

[Jonathan S. Shapiro]

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.

What I said was that the use of a NON-ambient authority system (we need
a catchy term for that) is also insufficient. One additionally requires
a correctly coded deputy.

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

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

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

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

Certainly not. I use the term "permisisons" 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.

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

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


shap