[cap-talk] "ACLs don't" paper rejected from Oakland 09

[Jed Donnelley]

At 06:57 PM 1/28/2009, Tyler Close wrote:
>...
>I've put the oakland09 submission, rejection email, and my updated
>version of the paper at:
>
>http://waterken.sourceforge.net/aclsdont/
>
>...Constructive criticism and productive
>next steps appreciated.
>
>--Tyler

Tyler,

What I did was to:

A.  Read through the thread on cap-talk to this point,

B.  Read the paper, and

C.  Read the reviewer comments.

I made notes as I read the paper and the reviewer comments.  I've
attached those notes in rather raw form below.  Sorry I don't have
time to condense them further.  I hope the additional comments
from another perspective might help some.  I also hope this message
makes it through the size filter.  If not I'll find a way around it.

_______________________


Notes on "ACLs don't":

1.  The initial claim of the paper seems rather modest in some 
regards.  While the claim is a deficiency (logic error) in the "ACL 
model", the only suggested negative consequence of this deficiency 
seems to be the "clickjacking and Cross-
Site Request Forgery attacks that affect many Web 
applications."  These attacks have arisen rather recently and are 
somewhat obscure.  If there is a fundamental logic error in the ACL 
model, doesn't it seem that it would have shown up long, long before 
now and in more prominent form?

2.  "This section examines the ACL and the capability for semantic 
differences." sounds incomplete to me.  Should that be the ACL and 
the capability 'models'?

3.  I think this section could be better stated:
_________________________
The behavior of each
implementation is detailed for an identical scenario
involving three principals, one of which is a software
agent instantiated to mediate an interaction between the
other two principals. The software agent is a Compiler
which compiles source code provided by the User,
and maintains usage statistics for the Vendor. The
introduction of the Protection paper proposes this exact
scenario as a useful way to evaluate an access control
mechanism. As will be discussed, the scenario was
again taken up in a later paper on access control. 1

1. For some readers, the particulars of this scenario may seem a
little dated. In that case, wherever the text talks of the Vendor, think
Web site; for Compiler, think Web browser; and for User, think Web
page. This correspondence is explained in greater depth in the next
section of this paper. After reading some of this section, you may
wish to skip ahead to the subsequent section and then come back.
_________________________

Why not treat the modern example and simply note that it is
equivalent to the historical confused deputy example?  As
stated with the compiler log example the problem at most times
seems irrelevant.

4.  I really like this paragraph:
__________
In contrast to the ACL reference monitor, the capability
reference monitor performs access checks earlier
in the call chain of messages, when the principal
designating a particular object is still known. The
result of an access check is reified as a capability that
can be transferred to other principals, and so used in
messages that combine the permission with those of
the other principals. A message at the end of such
a call chain may exercise permissions contributed by
many principals, each one authorizing some specific,
smaller part of the requested operation. In a capability
language, this construction of messages from capabilities
is expressed using the language's normal argument
passing syntax.
___________

I believe that paragraph contains the essence of the
problem that you're pointing out.

5.  When you discuss stack introspection and the Java
access control model and you note that:

"If the value of the object identifier used in an access
check was determined solely by principals represented
in the call chain, this technique defends against a
Confused Deputy attack."

it seems to me you're being too generous with this model.
While restrictive enough to block the inappropriate access
given to the confused deputy (write access to log.txt)
I believe it's also so restrictive that it doesn't allow
the intended access to log.txt.  It doesn't allow the
common "server" model of access control - namely that if
I'm executing "server" code I should grant access appropriate
for the server.

6.  Minor English - you say, "There are also additional
opportunities for Confused Deputy in a stack introspection
design."

Do you mean Deputies?  Or perhaps Confused Deputy vulnerabilities?


7.  I think this is a good point:
__________
By providing an indivisible representation of an
access matrix entry, a capability essentially enforces
the discussed tracking of the authorizing principal for
every object identifier held by a caller. Since the representation
is indivisible, any principal who had an effect
on the object identifier must also have held the corresponding
permission. Under stack introspection, this
tracking of principals is manually implemented at the
discretion of the application programmer. Since many
capabilities can be provided as arguments to an operation,
independently tracked authorization chains can
correctly authorize multi-argument operations. Such
access decisions cannot be correctly done using stack
introspection, since at best the model supports tracking
of a single authorization chain per operation.
__________


8.  R.e. "The Horton capability protocol [13] provides
a comprehensive way to track delegations, and take
appropriate redress action, in such dynamic multi-party
scenarios."  - cool, good reference.  I was biting
my tongue until I saw that reference.

However, earlier in this paragraph you say, "In
the capability model, accountability is assigned to the
principal at the start of the delegation chain."

As we see with Horton the above understates the flexibility
of the capability model.

I'm not sure how to best redress this disconnect.

Here's a possible suggestion.  Replace what you write
from:

"In the capability model, accountability is assigned to the
principal at the start of the delegation chain. Working
the delegation chain backwards to a point where redress
action can be taken is difficult and sometimes
impossible. Working down the delegation chain from
start to finish is a feasible way for an injured party to
determine an appropriate redress action.
In richer multi-party interactions, a principal may
over time be introduced to new principals. Some of
these introductions may come from distinct principals.
Consequently, a principal has an evolving understanding
of other principals and relationships between
them. The Horton capability protocol [13] provides
a comprehensive way to track delegations, and take
appropriate redress action, in such dynamic multi-party
scenarios."

with:

"When used with simple unwrapped object references the capability
model assigns accountability to the start of a delegation
chain.  However, we see in a mechanism like the Horton
capability protocol [13] that capabilities can be used
for comprehensive delegation tracking and assigning of
responsibility, even to the extent of revoking access
to a capability by reducing the authority of any principle
on the delegation chain (a facility usually attributed even
in a more limited way only to ACLs)."

Perhaps that clause after the last "," is pushing things
a bit, but I hope you get my thinking.


9.  Let me mention a less radical way to make the paper
seem more relevant.  Even if you don't introduce one of
the Web access control problems up front, I think you
could use one or both of them later on instead of the
confused compiler deputy to enhance the relevance of the
paper.  For example, in section 2.7 you discuss ways to
avoid confused deputies, but you still refer to the "old"
compiler example.  Why not use clickjacking or Cross-
Site Request Forgery attacks as an example at this point?

10.  I don't follow what you're getting at in the part of
section 2.7 that deals with ad-hoc checking and web servers.
In particular I don't see how this fits into your arguments
about the inadequacies of the ACL model.

11.  I particularly like this sentence just before your
conclusion section, "Better understanding
of the inability of the ACL model to correctly control
access in multi-party scenarios may help prevent the
continued recurrence of these attacks."

12.  I think your conclusions are well stated.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Regarding the reviewer comments:

13.  Regarding:
_______
Obviously it is commonly agreed that "the view presented in the 
Protection paper that ACLs and capabilities are merely different 
implementation choices for a single access model embodied by the 
access matrix is incorrect."
_______

Huh???  I have never heard anything like that "common" agreement is 
general security discussions.  In particular with regard to:
_______
And while indeed I am not aware of another effort that discusses all 
these issues together, I would assume that any serious system 
security course would touch on most of them in its AC section.
_______

I would like to see an example of some "serious system security 
course" that covers these issues.  I have yet to see one.  I'd be 
very much interested to see how such a course presented this 
topic.  If you can get feedback from the reviewer I'd be interested 
to see this claim backed up.

How about others?  Anybody know of a "serious system security course" 
(published) that covers these issues?

14.  Regarding, "I feel this would be probably suited better as part 
of a paper discussion a novel AC mechanism that solves some of the 
issues." - isn't
that what the Web keys paper does?  It seems to me that this paper is 
pointing out the fundamental underlying flaw in the ACL model that 
gives rise to such problems again and again.

15.  Regarding "If the authors of the paper truly believe they have a 
solution to CSRF, then they should implement it and reap the benefits 
of success."
Huh?  Again isn't that what something like Web keys constitutes?

Perhaps this points out something that should be emphasized in the 
paper.  You could note that there have been various ACL and 
capability implementations, but that the focus of the present paper 
is to show how all ACL implementations include potential 
vulnerability to confused deputies by the way references are passed 
as unprotected data.

16.  I believe this:
_______
The paper says, "Though these victim applications may correctly 
implement traditional access control lists (ACLs), somehow the 
attacker still gains access to resources that are supposed to be 
inaccessible"  However it is not clear where the ACL lies in this 
analysis. Is the browser security policy considered as an ACL? Is the 
ACL something at the victim site?
_______

is easy enough to clarify - though it seems pretty obvious to me and I'm
not sure it will help much with future reviews.

17.  Regarding:
__________
The three main defenses against CSRF are (i) unguessable tokens in 
forms, (ii) checking the referrer header, and (iii) custom headers, 
as implemented with XmlHttpRequest (XHR). What does the capability 
model have to do with these standard defenses?
___________

I think the above is a good point.  It seems clear to me that the 
unguessable token in a form is a capability.  That may not be clear 
to all readers - as it apparently wasn't to this reviewer.  I don't 
understand how (ii), and (iii) relate to the capability model.

18.  I agree that the third reviewer did seem to have a better 
understanding of what the paper was getting at.  While this may be 
true to some extent:
_________
many subsequent papers, many of which on this symposium (e.g. IBAC, 
KeykoS, OASIS, etc.), discuss extensively on the difference, in 
particular when it's matter of delegation.
_________

I believe there is merit in this paper due to it's clear focus on the
fundamental flaw in the ACL model that gives rise to problems like
Cross-Site Request Forgery and clickjacking.  A flaw that is likely
to continue to produce such problems until it is understood and
addressed at a fundamental level - e.g. with a capability implementation.

19.  I find this a curious comment:
________
I am also surprised that delegation was barely mentioned in the paper 
since most of the problems outlined seem to boil down to: 1) hidden 
delegation while it should be made explicit to make evident when the 
Compiler acts on behalf of a User (which user and on which file). 2) 
Use of ACLs instead of capabilities to implement this delegation.
________

I generally agree that delegation is at the heart of problems like
the confused deputy, Cross-Site Request Forgery and clickjacking.
I'm not aware of mechanisms that use ACLs instead of capabilities
to implement delegation.  In some ways this comment reminds me
of that ACL implementation of capabilities in my Managing Domains
paper:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

which amounts to using ACLs at one level to implement object
reference (capability) communication.  I'm not sure what to
say with respect to this comment except that I've never seen
an ACL implementation of delegation in production (others?)
and that if there is such, from my perspective it is simply
an implementation of the capability model.  It's the value
in the underlying capability model over the ACL model for
communicating authorizations that I believe is key.

20.  Regarding, "The paper is rhetoric, in that no new system, 
algorithm, or mechanism is introduced, and there is no evaluation."

I think the paper could be enhanced by noting that there are many
capability implementations that address these delegation problems
but that people seem to keep applying the same flawed ACL
mechanisms - seemingly because of a lack of understanding of
this fundamental underlying flaw in the model.

21.  Regarding, "the paper doesn't really attempt to constructively 
find a solution to the problem using ACLs." - is this somewhat like
the comment by the previous reviewer about not exploring an
ACL-based implementation of delegation?  I have to admit that I'm
not quite sure what that would mean, but I'm somewhat intrigued by
the prospect.  I wonder if somewhat along the lines of the way we
added an auditing of delegation with capabilities (Horton) there
might be a means to do so with ACLs?  My guess is that it would end
up being essentially a capability implementation (e.g. as in the
Managing Domains paper), but I'm not really sure.

22.  This comment by the last reviewer:
__________
I do appreciate this style of paper -- namely one that uses rhetoric 
and thought experiments to make a new insight about system structure, 
design, or architecture.  However, I think the burden on this kind of 
paper is to make a substantial leap, or resolve a long-unresolved 
problem, otherwise the paper might be inconsequential or prone to 
retreading old argument.  This paper didn't really feel like it met 
the burden of a sufficiently new or substantial contribution.
___________

seems to me to deal with some of the discussion I saw on cap-talk before
reading the paper and reviewer's comments (hoping this reverse ordering
might provide some additional insight).

23.  Regarding:

"Thus, the major premise of this paper (capabilities are better than
ACLs) is not a new observation."

I believe it was emphasized (perhaps more needed?) that the contribution
of this paper is to note that the problem with ACLs is fundamental,
by virtue of when and how access control decisions are made in
messaging passing systems - such as the web.


24.  I believe this last reviewer also "gets it".  I believe that thinking
in terms of convincing someone like this reviewer of the value of this
paper would be a good way to proceed in thinking about an update and/or
resubmission.

Sincerely,

--Jed  http://www.webstart.com/jed/