W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Are we making a Category Mistake?

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 19 Dec 2009 22:26:57 -0800
Cc: Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
Message-id: <0211EC84-22A5-4D9F-BCBB-80B19EBB6A1E@apple.com>
To: "Mark S. Miller" <erights@google.com>

On Dec 19, 2009, at 9:52 PM, Mark S. Miller wrote:

> Because services A and B at origin O are vulnerable to each other,  
> any permission P granted to A can be obtained by, and exercised by,  
> B. Rephrasing, all the permissions *possessed* by A are identical to  
> the permissions possessed by B, since any permission granted to one  
> can be exercised by either. The limits of what they are permitted to  
> do are identical. I am clarifying this since, from your response, I  
> suspect you thought I disagreed with this.
> Rather, the issue is what permissions are applied to a request  
> issued by A or B. Of the permissions we assume they possess, it does  
> not serve their interests to have all their permissions magically  
> applied to every request they issue whether they like it or not.
> The point of insisting that the relevant permissions be explicitly  
> placed in the message by the requestor is
> 1) so only permissions possessed by the requestor can be applied to  
> the request (I think we all understand this one now), and
> 2) so that, of the permissions possessed by the requestor, only  
> those the requestor chooses to include are applied to this request.
> My point is that G, by adding O to R's ACL, is violating #2. G is  
> taking away B's control over which of the permissions that B (in  
> some sense) possesses are used to determine whether a given request  
> is allowed. This can easily lead to B become confused and thereby  
> abuse-able.
> Both #1 and #2 are essential for avoiding confused deputy problems.  
> In the original scenario, the problem was not that the compiler  
> didn't have permission to the log file. The problem was that the  
> compiler's permission to write the log file was applied, causing the  
> compiler's request to be honored, when the compiler's interests lay  
> in denying that write request. In a system where applied permissions  
> are explicitly chosen by the requestor, the compiler would not have  
> chosen to apply its permission to write the log file to the request  
> to write the output file.

I think you've made your point clear. Setting aside for the moment the  
substantive point:

A) This is not directly analogous to the reason that preflight is per- 
resource. The purpose of the latter is to be more fine-grained about  
the resources to which access is granted, while the argument here is  
about narrowing (to some extent) who gets access. Thus, the novel

B) With that element removed, the argument seems the same as the basic  
pro-capabilities-only argument that has already been previously  

Thus I'm not sure we are going to learn anything new from this  
particular thread. Given the great volume of electrons already  
expended on this topic, let's try to limit ourselves to posts that add  
new information to the discussion.

Received on Sunday, 20 December 2009 06:27:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC