[cap-talk] "ACLs don't" paper rejected from Oakland 09
Tyler Close
tyler.close at gmail.com
Wed Jan 28 20:57:46 EST 2009
Hi all,
This past fall, in the wake of the clickjacking news, I set about
writing a paper to clearly explain to the world why ACLs, and derived
works, cannot possibly work for access control in multi-user systems
like the Web. I thought I did a pretty good job, and so submitted it
to the Oakland security conference. Unfortunately, I was unable to get
my point across to the reviewers. I thought a coherent argument
explaining why ACLs don't actually do any of the things they are
commonly believed to do would be an important contribution. AFAICT,
the reviewers believe the ACL model has already fallen into complete
disrepute, but simultaneously don't seem to quite get it. Other
reviewers seem to have missed sections of the paper where I thought I
clearly answered questions they seem to still have.
I've put the oakland09 submission, rejection email, and my updated
version of the paper at:
http://waterken.sourceforge.net/aclsdont/
I'm feeling demoralized now. Constructive criticism and productive
next steps appreciated.
--Tyler
-----Original Message-----
From: oakland09-pcchairs-l at cs.cornell.edu
[mailto:oakland09-pcchairs-l at cs.cornell.edu]
Sent: Wednesday, January 28, 2009 5:46 PM
To: Close, Tyler J.
Cc: Andrew Myers
Subject: [Oakland09] Rejected paper #31 "ACLs don't"
Dear Tyler Close,
We are sorry to inform you that your submission, "ACLs don't", was not
selected for publication by the program committee for the 2009 IEEE
Symposium on Security and Privacy. The selection process was highly
competitive, with only 26 of 254 submissions selected.
Reviewers' comments are included below and are available at the reviewing
website:
http://oakland09.cs.cornell.edu/oakland09/paper.php?p=31
We hope that these reviews will be useful to you.
Thank you for submitting to IEEE Security and Privacy, and we hope to
see you at the conference in May!
Best regards,
Andrew Myers and Dave Evans,
Co-Chairs, 2009 IEEE Symposium on Security and Privacy Program Committee
===========================================================================
Oakland09 Review #31A
Updated Tuesday 2 Dec 2008 4:07:57pm EST
---------------------------------------------------------------------------
Paper #31: ACLs don't
---------------------------------------------------------------------------
Overall merit: 3. Weak reject: will not argue against
Reviewer confidence: 3. Confident
Correctness: 4. Convincing
Presentation: 4. Well written
Relevance: 4. This is a reasonable venue for this
paper
Novelty: 2. Probably done before
===== Summary of paper =====
This paper discusses limitations of the ACL model in multi-principal settings.
===== Recommendation =====
This paper discusses limitations of the ACL model in multi-principal settings.
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."
This knowledge has been around for decades however. ACLs differ from
capabilities in dozen ways or more. Simply countering a claim made in
the original papers on AC might not be very relevant. It would be more
interesting to see if the nuances discussed here have not been
presented elsewhere also.
I might be biased, but while reading the paper I was trying to
identify items that I was not aware of before. 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.
Ultimately, I feel this would be probably suited better as part of a
paper discussion a novel AC mechanism that solves some of the issues
-- e.g., in the context of a a browser AC plugin that defends against
CSS or similar etc.
Finally, the paper has not been anonymized properly. The
acknowledgment section should probably have been eliminated.
===========================================================================
Oakland09 Review #31B
Updated Friday 19 Dec 2008 4:41:46am EST
---------------------------------------------------------------------------
Paper #31: ACLs don't
---------------------------------------------------------------------------
Overall merit: 2. Reject: will argue to reject
Reviewer confidence: 3. Confident
Correctness: 2. Unconvincing
Presentation: 2. Hard to follow
Relevance: 3. Not sure whether it belongs here or
in another venue
Novelty: 3. Unsurprising next step
===== Summary of paper =====
This paper purports to show a limitation of ACLs: The ACL model is
unable to make correct access decisions for interactions involving
more than two principals, since required information is not retained
across message sends.
The critique is based on CSRF and clickjacking; which are web attacks
that involve 3 parties: a dishonest site, an honest user, and an
honest site (the victim).
===== Recommendation =====
The contribution of this paper is not evident. The discussion about
limitations of ACL and advantages of capability model is a high-level,
almost philosophical treatment of the topic.
What specific measures could be used to prevent CSRF? How would they
be implemented in the browser, or at a web site? 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
===== Comments for authors =====
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?
In analysis of CSFR, the paper says, "Although the CSRF article makes
no reference to the Confused Deputy attack or capabilities, the
suggested defense is effectively to transition the application away
from the ACL model and to the capability model". It is not clear this
this reviwer what the paper is talking about. The three main defenses
against CSRF are (i) unguessable tokes 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 defensesw?
The author(s) similarly does not seem to be aware of the current
defense against simple clickfraud that uses randomized links. These
are arguably meant to be capability like, but still defeated by
clickjacking attacks.
The discussion of web phenomena seems simplistic and uninformed about
topics that are readily available on the web.
===========================================================================
Oakland09 Review #31C
Updated Wednesday 14 Jan 2009 6:24:44pm EST
---------------------------------------------------------------------------
Paper #31: ACLs don't
---------------------------------------------------------------------------
Overall merit: 3. Weak reject: will not argue against
Reviewer confidence: 3. Confident
Correctness: 4. Convincing
Presentation: 5. Lucid and eloquent
Relevance: 5. This is the natural home for this
paper
Novelty: 3. Unsurprising next step
===== Summary of paper =====
The paper gives a well written overview of how ACLs work, pointing out
subtle and important difference with respect to the capability
mechanism.
It shows that recent attacks such as Cross-Site Request Forgery and
clickjacking are instances of the Confused Deputy attack. It suggests
also how to solve this problem using the capability model rather than
ACLs.
===== Recommendation =====
The paper is very well written and it can be actually used as a good
class paper to explain the differences between ACLs and capabilities.
Many of the reported observation already appear here and there sparse
in the security literature, however this paper has the merit to write
all of them consistently in a single note. This is also a paper that
explains in depth the Confused Deputy problem.
===== Comments for authors =====
It is true the Protection paper didn't discuss on the fundamental
differences between ACL and capabilities. However, 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 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 act on behalf of a User (which user and on which file). 2)
Use of ACLs instead of capabilities to implement this delegation.
===========================================================================
Oakland09 Review #31D
Updated Tuesday 13 Jan 2009 2:06:40am EST
---------------------------------------------------------------------------
Paper #31: ACLs don't
---------------------------------------------------------------------------
Overall merit: 2. Reject: will argue to reject
Reviewer confidence: 3. Confident
Correctness: 3. Plausible
Presentation: 4. Well written
Relevance: 3. Not sure whether it belongs here or
in another venue
Novelty: 2. Probably done before
===== Summary of paper =====
This paper argues that ACL-based protection systems are inferior to
capability-based ones in the case of multi-principal interactions,
since these interactions are prone to confused deputy attacks. The
paper develops this idea using the "tried and true"
users/compiler/vendor example often mentioned in the literature, but
also shows how the points apply to Web scenarios. The paper spends
time explaining the limitations of ACLs, some time describing how
capabilities are better in some scenarios, and some time describing
CSRF and clickjacking attacks in this vein. The paper is rhetoric, in
that no new system, algorithm, or mechanism is introduced, and there
is no evaluation.
===== Recommendation =====
The paper didn't feel like it had enough "raw meat" -- many of the
capability vs. ACL arguments mentioned in this paper have been the
topic of religious wars in historical systems over the past three
decades, and confused deputy attacks have been understood for some
time (as has the fact that CSRF and clickjacking are instances of the
confused deputy problem).
I didn't entirely agree with the conclusion that capabilities solve
the problems, or that ACLs cannot solve the problem; the paper doesn't
really attempt to constructively find a solution to the problem using
ACLs.
The paper doesn't discuss alternative protection models that attempt
to solve exactly these kinds of problems (e.g., information flow
control -- see, for example, some of the recent work in the OS
community on this topic, such as Flume or HiStar).
===== Comments for authors =====
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.
ACLs vs. capabilities have been long debated in many systems. The
confused deputy article referenced in this paper ([8]) essentially
makes the same pro-capability argument as the paper itself:
capabilities bundle together the designation of the object that the
deputy should operate on with the permission to access that object.
Thus, the major premise of this paper (capabilities are better than
ACLs) is not a new observation.
CSRF and clickjacking have been recognized for several years now as
examples of the confused deputy problem. (See, for example:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?isnumber=4446683&arnumber=4446703
http://www.cgisecurity.com/csrf-faq.html
http://waterken.sourceforge.net/clickjacking/
It's true that ACLs don't bundle object designation with permission,
but the specific compiler/user/vendor problem can be solved with
argument validation -- the compiler verifies that the output file is a
file that the user invoking the compiler is allowed to access before
writing to it.
Solutions other than capabilities would work, such as an
information-flow based solution. (I agree this is harder to apply to
the web.)
The acknowledgements section is not appropriate for an anonymized
submission -- it leaks too much information about who may have
authored the paper. (It's fine for a camera ready, of course.)
More information about the cap-talk
mailing list