a future caller alternative ?

Mark S. Miller erights at google.com
Fri Mar 8 15:33:38 PST 2013


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 <erights at google.com> wrote:

> On Fri, Mar 8, 2013 at 2:38 PM, Kevin Gadd <kevin.gadd at 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 <kpreid at google.com> wrote:
>> > On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd <kevin.gadd at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/8e940fdc/attachment-0001.html>


More information about the es-discuss mailing list