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

[Jed Donnelley]

At 04:01 PM 12/24/2006, David Hopwood wrote:
>Jed at Webstart wrote:
> > In the message above you seem to suggest that if a revocation
> > happens and it stops somebody from doing their work, that's
> > OK.  If the revocation is as intended and the person should no
> > longer have access, then of course it is more than OK, it's
> > what should happen.
> >
> > However, in the case we've been discussing (
> >
> > 1.  Alice -> Bob -> Carol -> Dave  ("->" indicates delegates to),
> >
> > 2.  Bob's access is revoked,
> >
> > 3.  Carol is introduced to Alice and Alice decides that Carol
> > should be trusted with the authority delegated to her from
> > Alice via Bob.
> >
> > ) this is not the intent and I regard it as very far from OK.
> > Because of #3 both Carol and Dave should continue to be
> > able to exercise the authority granted to them from Alice
> > by Bob.
>
>But should Carol continue to have access *via the same reference as before*?
>I claim not: indeed, I think it is essential to security (and intended by
>Alice) that Carol should lose access via that reference.
>
>While it may be seen as convenient that Carol continues to have access via
>the same reference, this is absolutely the wrong thing from the point of view
>of preventing confused deputy attacks. Bob (for example) may still be in a
>position to provoke Carol into using that reference in a way that is no longer
>intended, after the revocation.
>
>(Note that Carol is a process, not a human user, and therefore is 
>fundamentally
>incapable of understanding the reasons why it may have been requested to
>perform any given operation. This is also true if Carol happens to be a
>"user agent" process. The only way we can avoid confused deputy attacks is to
>ensure that processes do not need any intelligence to determine when they can
>use a particular reference.

This is an excellent point.  However, I don't believe the delegation with
responsibility tracking introduces any new danger from confused deputies.

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.

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

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.
I don't believe it's possible.  In all cases a process receiving a
capability must treat it in the context of the received message.
This mechanism is pure object-capability and thus provides as much
information as it's possible to get in order to protect against
confused deputies.

This is an important issue that I want to get right for our
write-up on this approach, so I definitely want to follow up
if any such "attack" is possible.

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