[cap-talk] Another "core" principle - confused deputy? not

[Jed Donnelley]

At 07:50 AM 12/26/2006, David Hopwood wrote:
>Jed Donnelley wrote:
><snip>
> > The most important point to note in this regard I believe is that when
> > Carol receives the delegated capability, she does so in a message that
> > in general she has no idea came from "Bob".  Just as in any capability
> > transaction she received it in a message that was the result of a
> > capability invocation and that possibly included other capabilities.
> > In terms of any confused deputy danger Carol can only trust the
> > capabilities that she received in that message - then or into the
> > future.
>
>[I'll switch to using lowercase for names of processes.]
>
>Suppose that carol is a scheduling service with similar functionality to
>'cron' in Unix 
><http://www.opengroup.org/onlinepubs/007908775/xcu/crontab.html>
>or 'Scheduled Tasks' in Windows.
>
>Since carol is a system service, we will assume it is trusted by everyone
>to carry out its designed functionality. (This does not mean that any given
>client of carol necessarily approves of everything that it might do on behalf
>of its other clients.)
>
>Now consider the following events:
>
>   alice has write access to some object, say a file 'foo'.
>   alice delegates this access to bob.
>   alice asks carol to append the string "chime" to foo every hour.
>   bob asks carol to truncate foo to zero bytes every half-hour.
>   alice revokes bob's access to foo.
>
>Clearly the outcome should be that foo stops being truncated every half-hour,
>but continues to have "chime" appended every hour. If we implement revocation
>using a simple membrane (or even just a caretaker in this example), then this
>will be what happens automatically, for a straightforward implementation of
>carol. Any more elaborate kind of delegation tracking/revocation 
>mechanism should
>be designed to preserve this property.

Exactly, and there's no problem with the above - whether using delegation
with responsibility tracking or not.  First I think I should note that
simply because the delegation with identity use of the membrane mechanism
allows use of a multiply delegated capability to be restored if access is
removed from an intermediate identity in the delegation chain, there's nothing
in the mechanism that denies or even suggests/hints that more direct
delegation shouldn't be done.  That is one can certainly have:

foo:R->alice->bob
and independently:
foo:R->alice->carol

and then later the revocation of foo:R->alice->bob by alice.  No problem.

The added value that we're looking for in the case of the multiple
delegations (which I argue are going to be quite important if/when
we have systems that can allow any delegations - even straight
capability copies) is that bob can do his own delegation, have
his delegation revoked and carol can still be given access by any
subject identity further up the delegation chain.

In that case we have:

foo:R->alice->bob
and then
foo:R->alice->bob->carol

Suppose in that case (stretching the analogy a bit) it was bob who
asked carol to append the "chime" text every hour.  Suppose that it
was also some other misbehaving subject that bob had delegated to
(e.g. directly without identity/responsibility tracking) that was
doing the truncation.  Now suppose Alice is told that carol should
have access to the "foo" object delegated by bob regardless of bob's
access.  Note the this could happen either before or after bob's
access is revoked.

Whenever this action is taken by carol (under the above assumptions),
the "chime" again starts getting added to foo without the truncation.

>(Indeed, the rationale that we often give for why it is safe to allow bob to
>delegate authority to carol, is that bob could have proxied this authority for
>carol. If bob loses its access to 'foo', then any delegations of 
>that access to
>carol *must* stop working, otherwise this "proxying rationale" is 
>not valid. It
>should not matter whether carol has access to 'foo' for other 
>reasons, since the
>proxying of *bob's* access would still fail in that case.)

I see this above as a different issue.  Above I believe you're arguing that
bob wants to retain control of the delegation to carol.  That is, bob could
take the attitude that even if alice does want to delegate to carol "around"
bob's delegation to carol that bob still wants to be able to revoke carol's
access.  The problem with this attitude on bob's part is that we know that
alice can delegate directly to carol in any case.  By taking this attitude
(which of course bob is free to do) all bob is doing is making things more
difficult for carol.  In that case bob would be forcing the sort of
re delegation from alice directly to carol and the consequent re mapping of
carol's directory structure and carol's further delegations.

Hmmm.  OK, I think I have an example where there is a difference in these
scenarios.  Suppose bob can communicate to carol but alice can't.  E.g.
alice is confined to only be able to communicate to bob and perhaps the
server S of the foo object.  In that case if bob was to delegate to carol
with identity/responsibility tracking from the existing delegation from
alice, bob would be allowing alice to turn carol's access back on despite
bob's revocation.  Of course that's bob's intent in doing so by adding
a delegation to the existing chain rather than starting a new chain.

If bob did the delegation to carol by starting a new delegation chain,
then of course alice would be unable to bypass bob.  While bob could
do this, I argue that at least for people doing such delegations it
should be recommended practice that Bob delegate by adding on to the
existing delegation chain so that anybody above him in the chain
can indeed bypass him.  As we know, in the case of people we always
have out of band communication means, so the confinement example isn't
relevant.  By starting a new delegation chain Bob can only cause
problems and not exert any relevant additional control.

I believe the confinement example is a rather specialized case.  Also,
since I recommend using direct capability communication at the
inter domain procedure call level, I believe that there where it is
appropriate confinement will always be preserved.  If bob is trying to
confine alice, then of course bob can't even communicate any
capability communicated from alice even directly (let alone with
responsibility tracking delegation) and expect to preserve any
such confinement.

> >>This requires distinguishing between references that eventually 
> give access to
> >>the same object, but could be revoked under different 
> circumstances. In this
> >>case, the only way for Carol to behave correctly after the 
> revocation is for
> >>it to have two references, and lose access via only one of them.)
> >
> > I disagree.  The only way for Carol to properly deal with this delegated
> > capability to avoid confused deputies is to treat it in the context of
> > the invoked capability and the other capabilities in the message, then
> > and into the future.
>
>That is what 'carol' is doing in the scheduler example above. But in order for
>it to do that, it needs to associate a different capability to 'foo' with each
>of the two schedule entries, so that one of them continues working while the
>other fails.

I don't deny that there can be circumstances where there may be such
a need, I do argue that:

1.  This example doesn't hit the mark.  I believe any example with such
a need would have to be deeper, and

2.  I believe all the tools are available in any case in pure capability
systems to deal with confused deputies - whether with this sort of
responsibility tracking by identity or not.  These tools are the
capabilities that arrive in messages that are invocations.  The
mechanism for responsibility tracking by identity is still a pure
capability mechanism and thus provides all the needed tools.

> > It's important to note that this capability could
> > be received from any process, e.g. Ellen, who received the capability
> > by a direct transfer (no responsibility tracking delegation) from Bob.
> > Carol's confused deputy responsibility is to only treat the capability
> > in the trust context of the other capabilities that "she" received in
> > that one message.  She only knows that those other capabilities were
> > owned by the sending process.  Any knowledge of Bob or Alice or another
> > identity must be treated separately.
>
>I hope the above example clarifies that the issue here has nothing to do with
>knowing the identities of callers.\

As I argue above, I believe this example needs more work.  Thanks for taking
time to work on it.

> > At 04:38 PM 12/24/2006, David Hopwood wrote:
> >
> >>...
> >>After reading some other posts in this very large thread, I see 
> that some other
> >>participants may have been intending "Alice", "Bob" and "Carol" to refer to
> >>principals that would normally correspond to human users. 
> Regardless, I think
> >>that the above argument stands, since:
> >>
> >> - principals that correspond to human users are not distinguished
> >>   from principals that don't, in most cap systems,
> >>
> >> - humans can be vulnerable to confused deputy attacks, too.
> >
> > I suggest that you try to come up with a specific example of how this
> > delegation with responsibility tracking can result in a confused deputy.
>
>Here is a refinement of the scheduler example that shows that the 
>same argument
>does stand for delegations between human users. Suppose that the 
>scheduler service
>is now dave, not carol. Carol is a techie who understands the system 
>well, so other
>users are in the habit of asking her to set things up for them.
>
>   Alice has write access to a file 'foo'.
>   Alice delegates this access to Bob.
>   Alice sends email to Carol, including a email-compatible representation of
>     a capability to 'foo', and asking her to arrange for the string 
> "chime" to
>     to be appended to foo every hour.
>   Carol asks dave to append the string "chime" to foo every hour, using the
>     cap from Alice's email.
>   Bob sends email to Carol, including his email-compatible cap to 
> 'foo' delegated
>     from Alice, and asking her to arrange for foo to be truncated 
> to zero bytes
>     every half-hour.
>   Carol asks dave to truncate foo to zero bytes every half-hour, using the
>     cap from Bob's email.
>   Alice revokes Bob's access to foo.
>
>Now, Carol should not have to do anything in order for the 
>half-hourly truncation
>of foo to stop happening. That should stop automatically, because 
>Carol (correctly)
>set it up using Bob's now revoked delegation. It would be a mistake 
>to design the
>system in such a way that the revoked cap passed to dave is 
>automagically switched
>to use the other working cap that Carol still has.

In the above scenario it does stop automatically.  When you refer to 
the "email"
communication of a capability I believe you are just intending direct 
communication
of a capability.  Please note that with the delegation mechanism including
identity tracking there is no intended prohibition of direct communication of
capabilities.  Indeed doing so is still important in many contexts.  While I
can argue (as earlier in this message) that this example isn't one of them, I
believe that normal procedure calls between domains is a situation where
capabilities should be communicated directly.

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