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

[David Hopwood]

Jed Donnelley wrote:
> 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.

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

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

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

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

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

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>