Re: Are we making a Category Mistake?

On Sat, Dec 19, 2009 at 10:26 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> 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
>
>
The reason the quote from Anne is significant is that it explains *why* the
purpose of preflight is to be more fine grained about resources. This brings
out a new reason why we need to be more fine grained about who gets access.
That CORS advocates recognize the need to be fine grained at the accessee
side of the access relationship but not the accessor side seems inconsistent
to me. If it doesn't seem inconsistent to you, then I simply don't
understand your position.

Your primary defense of CORS rests on the plausibility that DBAD (don't be a
deputy) is practical. Once attention is called to the diversity of loosely
coupled services on each side of the access relationship, I no longer
understand even what it would mean. The "foreign" parties you have to be
wary of now include parts of "yourself". What guidelines would you explain
to B's author, so that B could avoid being a deputy without coordinating
with A's author?


> B) With that element removed, the argument seems the same as the basic
> pro-capabilities-only argument that has already been previously presented.
>
> With that element removed, sure. Further, with all elements of what I am
saying removed, I would seem to be saying nothing at all.



> 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.
>
> Regards,
> Maciej
>
>


-- 
   Cheers,
   --MarkM