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
presented.
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
