[cap-talk] "ACLs don't" paper rejected from Oakland 09
John Carlson
john.carlson3 at sbcglobal.net
Wed Jan 28 23:21:36 EST 2009
I would start with a description of confused deputy, then move to
section 3. If people
do not know what ACLs or Capabilities are, they can read your
references. I lost you when
you started into the access matrix grid (ho hum). Describe how your
system (capabilities)
effectively stops the confused deputy examples.
In other words, instead of talking about history, then the problem,
and the solution, refer to history
(assuming people know about it or can read your references) and focus
on the problem and solution.
I understand the need to develop a coherent story, it's just that the
coherent story takes too much
of people's time.
John
On Jan 28, 2009, at 6:57 PM, Tyler Close wrote:
> 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.)
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
More information about the cap-talk
mailing list