[cap-talk] Confused Deputies in Capability Systems
David-Sarah Hopwood
david.hopwood at industrial-designers.co.uk
Sat Feb 7 16:32:53 EST 2009
Toby Murray wrote:
> The general point about confused deputies is that (1) they perform
> actions that their clients cannot perform, (2) incorrectly in response
> to designations sent by some clients.
>
> The last discussion raised point (1) -- that confused deputies
> necessarily can perform actions that their clients cannot. I'm adding
> point (2) -- that these actions are performed "incorrectly" only (in
> fact, I'd say *by definition*) because either the service has failed to
> perform input validation or because it shouldn't be responding to a
> particular client -- the client shouldn't have gotten access to the
> service.
I'm still not seeing why you think that either input validation or
client *identity* are relevant.
In the compiler confused deputy example, for instance, input validation is
neither necessary nor sufficient to prevent the attack. If the file path
remains a string (or other forgeable designator), then there is no
validation that the compiler could do on it, in the ACL case, that would
reliably prevent the attack (given that we do not trust it to duplicate
the access controls of the underlying system). And without any validation
bv the compiler but with the file path replaced by a capability, the
attack is reliably prevented, because there is no rights amplification
in this example. The compiler will only write to the output file if the
client was already authorized to write to it. If there are multiple
levels of delegation, then *each* client must have been authorized to
write to the file.
Similarly, it really does not matter, for the purpose of access control [*],
what the client's identity is; only whether it is authorized to write to
the file, which depends only on whether it is able to pass a write
capability to it.
Most practical examples of confused deputy (with a single level of
delegation) are essentially isomorphic to the compiler example -- it's
a good example in that respect. This does not by itself exclude that
input validation or client identity might be relevant in more complicated
examples, but you haven't made that case.
[*] It might matter for logging or for debugging of the access control
behaviour, but that's what capability-based delegation-tracking
protocols are proposed for.
--
David-Sarah Hopwood ⚥
More information about the cap-talk
mailing list