[cap-talk] Confused Deputies in Capability Systems

[Sandro Magi]

David-Sarah Hopwood wrote:
> Sandro Magi wrote:
>>   // implicit coercion of a string to a VettedPath
>>   // that performs the access check at time of creation
>>   public static implicit operator VettedPath(string path)
>>   {
>>     // access check, throws UnauthorizedException
>>     File.AccessCheck(path);
> 
> I'm assuming this check is based on the identity of the direct
> caller of 'operator VettedPath(string)'.

Yes, though 'identity' may not be the evidence used. It's just a rough
idea based on a pattern I devised for reducing errors in other code (see
below), so I'm not yet sure precisely how the access should be verified.
Identity is one obvious possibility for legacy compatibility.

> (If it is based also on indirect callers, then we have a stack
> inspection system: see that section of Tyler's "ACLs Don't" paper
> for general problems with such systems, and see the recent
> Java Calendar exploit for a concrete example.)

Yes, I was trying to avoid stack inspection as it inhibits composition,
and POLA by extension. The vetted type is intended to "wrap up" an
authorization into a communicable value, like a capability, but without
having to change existing ACL-based code.

> The problem is that there is no "appropriate time" to perform an
> identity-based access check. We have only succeeded in moving the
> point at which the confused deputy vulnerability is present to the
> code that triggers the access check. That is, the direct caller
> of 'operator VettedPath(string)' is now the confusable deputy.

Yes, but at least whether the data is verified and the operations
authorized is explicit in the interface.

Code which uses Vetted types is not confusable, code which does not is
confusable. The answer is thus to push vetted types into more code.
Considering it's a simple wrapper with an implicit conversion, the
refactoring required is very low.

We eventually bottom out at user-interface boundaries where a vetted
type may produce a power box, or signal an error to the user.

> Note that although VettedPath can reasonably be trusted (assuming
> that File.AccessCheck is also audited), that does not imply that
> its caller can be.

Trusted with what?

> I should also have mentioned that making the check triggered by
> an implicit conversion, as the above code does, is a particularly
> bad idea.

I generally dislike implicit conversions, but it provides a compile-time
upgrade path for legacy code that was using only unverified data before.

This pattern has proven useful for vetting method arguments. I have
vetting classes to ensure method arguments are non-null, or references
which may be null are marked as such, etc. They all have implicit
conversions so legacy code remains unchanged.

In the scope of the method, I need only inspect the method argument type
to know how carefully I need to handle it. Since the method should be
checking for these properties and throwing exceptions anyway, where's
the harm?

Sandro