W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 13 Dec 2009 15:19:56 -0800
Cc: Adam Barth <w3c@adambarth.com>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, Tyler Close <tyler.close@gmail.com>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
Message-id: <F7A54CCA-F069-4E00-B069-04C6E1EE53CF@apple.com>
To: "Mark S. Miller" <erights@google.com>

I enter this subthread with trepidation, because I do not think the  
Working Group is in a position to engage in a literature review on an  
active research topic. However, a few comments below:

On Dec 13, 2009, at 1:29 PM, Mark S. Miller wrote:

> On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth <w3c@adambarth.com>  
> wrote:
> On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller <erights@google.com>  
> wrote:
> > On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth <w3c@adambarth.com>  
> wrote:
> >> I agree with Jonas.  It seems unlikely we'll be able to
> >> design-by-commitee around a difference in security philosophy  
> dating
> >> back to the 70s.
> >
> > Hi Adam, the whole point of arguing is to settle controversies.  
> That is how
> > human knowledge advances. If after 40 years the ACL side has no  
> defenses
> > left for its position, ACL advocates should have the good grace to  
> concede
> > rather than cite the length of the argument as a reason not to  
> resolve the
> > argument.
>
> I seriously doubt we're going to advance the state of human knowledge
> by debating this topic on this mailing list.  The scientific community
> is better equipped for that than the standards community.
>
>
> AFAICT, the last words on this debate in the scientific literature  
> are the Horton paper <http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf 
> > and the prior refutations it cites:
>
> Because ocaps operate on an anonymous “bearer right” basis, they  
> seem to make reactive control impossible. Indeed, although many  
> historical criticisms of ocaps have since been refuted [11, 16, 10,  
> 17], a remaining unrefuted criticism is that they cannot record who  
> to blame for which action [6]. This lack has led some to forego the  
> benefits of ocaps.
>
> The point of the Horton paper itself is to refute that last criticism.

That paper seems to respond to a criticism of object-capability  
systems. Specifically, it shows a protocol that apparently lets you  
associate communication with an identity in an object capability  
system to allow logging and reactively restricting access. At least  
I'm pretty sure it does, it took me several readings to properly  
undertand it.

This paper does not appear to give an argument that capability models  
are in general superior to other models.

>
> [11] Capability Myths Demolished <http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf 
> > or <http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/ 
> >

Those two don't seem to link to the same paper.

> Referee rejection of Myths at <http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html 
> >. Read carefully, especially Boebert's criticisms.

I'm not sure what we are supposed to conclude from the rejection  
comments (or from a rejected paper in general).

> [16] Verifying the EROS Confinement Mechanism <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577 
> >

The point being made her seems too technical to relate to the current  
discussion (at least to my non-expert understanding).

>
> [10] Robust Composition <http://erights.org/talks/thesis/>. Notice  
> in particular the counter-example to Boebert's famous claim in seven  
> lines of simple code, in Figure 11.2.
>
> [17] Patterns of Safe Collaboration <http://www.evoluware.eu/fsp_thesis.pdf 
> >, which does a formal analysis of (among other things) confused  
> deputy, Boebert's claim, and my counter-example.
>
> [6] Traditional capability-based systems: An analysis of their  
> ability to meet the trusted computer security evaluation criteria. <http://www.webstart.com/jed/papers/P-1935/ 
> >

There seems to be a whole lot of material on whether capability-based  
systems can enforce the *-property. It's not obvious to me how this is  
relevant to the discussion. If my understanding of the *-property is  
correct, it's not a property that we are trying to enforce in the  
context of Web security. But to be fair, I did not know what the *- 
property was until just a few minutes ago, so my opinion cannot be  
considered very well informed.

>
> If you know of any responses to these refutations in the scientific  
> literature, please cite them. If you believe (as I do) that the lack  
> of responses is due to ignorance and avoidance, then either
> 1) the scientific community has shown itself less well equipped to  
> engage in this debate than those who are actively engaged in it --  
> such as us here on this list,
> 2) that the case against these alleged refutations are so obvious  
> that they need not be stated, or
> 3) that the members of the scientific community that cares about  
> these issues have found no flaw in these refutations -- in which  
> case they legitimately should stand as the last word.

The literature you cited seems to mostly be about whether capability  
systems have various technical flaws, and whether they can be made to  
do various things that ACL-based systems can do. This does not seem to  
me to show that the science is settled on how to design security  
systems.

I'm also not sure that this Working Group is an appropriate venue to  
determine the answer to that question in a general way. I don't think  
most of us have the skillset  to review the literature. Beyond that,  
our goal in the Working Group is to do practical security analysis of  
concrete protocols, and if there are flaws, to address them. If there  
are theoretical results that have direct bearing on Working Group  
deliverables, then the best way to provide that information would be  
to explain how they apply in that specific context.

Regards,
Maciej
Received on Sunday, 13 December 2009 23:20:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT