Adrian Mettler's thesis < http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-244.html> is about Joe-E, which brings ocaps to Java is a very similar way to how we bring ocaps to JS. The Joe-E project is at <https://code.google.com/p/joe-e/>. The really important thing about Adrian's thesis is it clearly articulates a new goal that has been implicit in much previous ocap work but not previously explained: "reviewable security".
On Fri, Mar 8, 2013 at 3:27 PM, Mark S. Miller <erig...@google.com> wrote: > On Fri, Mar 8, 2013 at 2:38 PM, Kevin Gadd <kevin.g...@gmail.com> wrote: > >> Is this 'references constitute permissions' design philosophy written >> up on the wiki somewhere so I can understand the motivations behind >> it? > > > Apologies for multiple instances of self-citation below. > > Not on the EcmaScript wiki, except by reference to "object-capability" or > "ocap". Other wikis with good material: < > http://en.wikipedia.org/wiki/Object-capability_model> and < > http://wiki.erights.org/wiki/Main_Page>. Many people have said that my < > http://erights.org/talks/thesis/markm-thesis.pdf> and < > http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf> are good starting points. > > For the application of these ideas to JavaScript, I am also partial to the > talks I gave at VUB: <http://www.youtube.com/watch?v=w9hHHvhZ_HY> and < > http://www.youtube.com/watch?v=oBqeDYETXME>. These are part one and part > two of an extended talk but had to be accessible to people who could only > attend one. If you watch both, you can skip something like the first 10 > minutes of the second one. > > For introductions, another favorite of mine is Marc Stiegler's < > http://www.youtube.com/watch?v=eL5o4PFuxTY> "The Lazy Programmer's Guide > to Secure Computing". > > There is much much else on this topic, but these are good places to start. > Others no doubt have other favorite papers, pages, or presentations. > Without overwhelming the list, it would be good to see some of these posted. > > > >> It feels a dramatic divergence from the origin-based security >> model, > > > Indeed! Origin-based security has been a nightmare. > > > >> and it's complex enough in practice that I assume I won't be >> able to participate in any discussion involving security unless I >> thoroughly understand your motivations in advocating this model and >> using it to justify the removal of features. >> > > I certainly agree that you should learn this model. I hope that once you > do you'll agree that it's actually much simpler *and* much more expressive > than the security you're used to. > > > >> >> Re: stack inspection, I'm aware of it being used in scenarios other >> than Java. Is there some conclusive proof out there that stack >> inspection is fundamentally unworkable, or is it merely just >> intrinsically flawed as exposed in Java? I would not leap from the >> latter to the former, but I'm also not a CS researcher. My goal here >> was merely to list out real world use cases for stack walking that I >> have encountered in real applications, some of which can't be easily >> implemented without it. >> > > My favorite explanation is Tyler's < > http://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf>. See Fred > Spiessen's <http://www.evoluware.eu/fsp_thesis.pdf> for a more formal and > somewhat different treatment. > > > >> >> -kg >> >> On Fri, Mar 8, 2013 at 2:28 PM, Kevin Reid <kpr...@google.com> wrote: >> > On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd <kevin.g...@gmail.com> >> wrote: >> >> >> >> The Error.stack strawman is a great start at making Error.stack's >> >> contents machine-readable, but doesn't remotely approach being a >> >> solution for use cases previously addressed by Function.caller. >> >> >> >> I don't really understand the security argument in this case. Being >> >> able to identify the particular function at offset N in the stack >> >> shouldn't expose any privileged information >> > >> > >> > The problem is exposing the ability to invoke the function. Not >> 'privileged' >> > information, but 'privileged' operations. >> > >> >> >> >> If anything, being able to cheaply and reliably walk >> >> the stack to - for example - identify your caller would allow you to >> >> implement some interesting security patterns in your own code, if for >> >> some reason you were trying to do sandboxing and code access security >> >> in pure JS. If specified correctly you could make it possible to walk >> >> the stack and ensure that the information you're getting isn't being >> >> spoofed, which would allow you to reliably limit callers of a given >> >> 'protected' function to a fixed whitelist of trusted functions, >> >> something you can't do by parsing a dead stack trace. >> > >> > >> > Java tried stack inspection. It has failed. It has been responsible for >> > quite a few vulnerabilities (of the sort which allow Java applets to >> break >> > their sandbox) and does not compose well. >> > >> >> >> >> Apologies if I've missed some huge design philosophy underpinning the >> >> design of ES6/ES7 re: security/sandboxing; I also don't really >> >> know/understand how Caja fits into the picture. >> > >> > >> > References constitute permissions. To have a reference to a function is >> to >> > be able to invoke it is to have the permission. >> > >> >> >> >> -- >> -kg >> > > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
