Re: Are we making a Category Mistake?

On Sat, Dec 19, 2009 at 8:58 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 19 Dec 2009, Mark S. Miller wrote:
> >
> > And that is why in my response, I stated "For the same reason, we are
> > not *serving the interests* of an origin by adding that origin's name to
> > the ACL for a resource." [emphasis added] Say that grantor G seeks to
> > grant to service A at origin O permission P to access resource R. Say G
> > does this using the path of least resistance suggested by the CORS
> > mechanism (and repeatedly suggested as a sound practice in this thread)
> > -- by adding O to R's ACL. If service B at origin O is malicious, it can
> > certainly steal P, so that is not my present concern.
> >
> > Rather, if A and B are both "services maintained by different parties
> > hosted on a single origin" O, where A and B are politely trying to stay
> > out of each other's way, then G inadvertently disrupts the correct
> > operation of B by causing permission P to be applied to B's requests
> > merely as a side effect of trying to grant P to A. This does not serve
> > the interests of B, nor of the origin serving as the host for such
> > mutually trusting but separately maintained services.
>
> Indeed. That's why CORS is per-URL on the server, and not per-origin.
> That's exactly Anne's point, and is why CORS is designed to grant
> permissions per-resource and not per-origin, on the server.


Good. I'm glad we're in sync to here.



> (Obviously as
> Adam pointed out, the client side can only be per-origin for historical
> reasons. That's unfortunate, but there it is.)
>

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.



> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
   Cheers,
   --MarkM