[cap-talk] Confused deputies in hybrid systems (was: Loss of control)

[David Hopwood]

Mark Miller wrote:
> On Feb 2, 2008 4:58 PM, David Hopwood
> <david.hopwood at industrial-designers.co.uk> wrote:
>> Alan Karp had written:
>>  > [...]  Actually, I was thinking along the lines of an additional, non-ocap
>>  > check. [...] For example, "This capability can only be used by clients in
>>  > my domain."
> 
>> [...] As I replied to Sandro, the main
>> issue is that:
>>
>>    "If the domain restriction [mentioned by Alan Karp] prevents any attacks,
>>     then confused deputies in the domain become possible vectors for those
>>     attacks."
>>
>> Conversely, if there are no attacks prevented by the domain restriction,
>> then it is providing no security benefit.
> 
> This puts the point more clearly than I've ever been able to. Thanks!
> 
> But the issue isn't specific to hybrid vs ocaps. It can arise in pure
> ocap systems when doing rights amplification or IBAC. For example, it
> can arise in Horton when Who attribution is used to deny access.

In one sense, that is a hybrid system, even if it is built on a pure
ocap system.

> The stance we suggest in the Horton paper is that Who attribution should
> only be used reactively -- to shut off further access in reaction to
> past abuse. Confused deputies do indeed become possible vectors for
> circumventing such reactive denial of access -- but only at the cost
> of tarnishing the reputation of that deputy's Who, leading to
> eventually denying access to those confusable deputies as well.

I agree with this.

> Similarly, if Alan's additional non-ocap domain check exists only to
> be used reactively, then I think it may be as benign as the
> reactive-only use of Horton. I am now confused about how different
> Horton actually is different from a hybrid ocap system such as Alan
> suggested.

I can't speak for Alan, but what he described seemed to be purely an
access control mechanism (like the login check in the example below).
It's a bit problematic to provide people with an access control mechanism
and then expect them not to use it for access control, even if you tell
them not to.

More generally, if we have several security mechanisms of differing
known strengths, then all else being equal, we should only provide the
strongest one(s). Otherwise the weaker ones will be an attractive
nuisance for users. (Of course, it's not quite that simple; mechanisms
are not totally ordered in strength, and they may have different costs
according to various metrics -- although there is no general rule that
more secure mechanisms must have higher costs.)

>> Does this clarify the issue sufficiently? If it doesn't, I will try to come
>> up with a more concrete example.
> 
> Concrete examples always help. I suspect they'd help a lot here. ;)

FooCo runs a mailing list which it uses for collaborative projects with
BarCo. Alice at FooCo, Bob at FooCo, and Mallory at BarCo are subscribed to this
list. FooCo also runs a web server that uses YURLs, but performs additional
access checks using a cookie-based login.

Alice creates a document which contains FooCo proprietary information,
and puts it on the web server marked as only readable by FooCo logins.
She also writes an email about the collaborative project, which is
mostly fine for BarCo employees to read, but also contains a YURL to
the document. She reasons (incorrectly, but plausibly), that it is
okay to send this email to the list because the login check will only
allow the document to be accessed by FooCo employees.

Bob logs in to the server using his FooCo login to read the document.
But (assume that) the combination of Bob's web browser and the server is
vulnerable to an XSRF attack, so if Mallory can get Bob to access an
exploit web page while he is logged in, Mallory can obtain the document.

Note that Alice did not rely on any security property that the system
did not claim to enforce. Since Alice could just send a copy of the
document if she wanted to, mandatory access control is not enforceable
here. The need is for VOC, but the cookie-based access check is a poor
implementation of that, because it is vulnerable to confused deputy attacks.

Not all identity-based mechanisms are equally vulnerable. In this example,
using rights amplification in some way that does not result in Bob
*implicitly* presenting his FooCo credentials, would solve at least the
immediate vulnerability.

-- 
David Hopwood