a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Mar 8 15:54:58 PST 2013


Mark,
  that is an exhaustive list of links and talks but how many real use cases
where we let the user inject any sort of script code in the website and we
inject malicious libraries we are not aware, compared with the number of
all website that would never suffer any problem with this ?

Comparing Java Applets with JavaScript is a no-go, Java had privileged
access to the system, nothing caller could achieve in all it's possible
evil forms, neither eval could do much there.

I think there are no real use cases where caller is dangerous if not few
academic purpose attempts to make it safer, and you seemed to work in
probably all of them ... ask devs out there how many are using those
libraries.

As summary, you ask us to bring real cases where caller is needed, I would
do the other way around: bring real cases in the real world where caller
could be such disaster because trusting user inputs and blindly include
external libraries are not, again, real world use cases ... not the
majority of them, am I wrong ?

I see this like "don't use SQKL ever because there could be SQL injections"
... sense? None for me :-/




On Fri, Mar 8, 2013 at 3:33 PM, Mark S. Miller <erights at google.com> wrote:

> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/071ca19c/attachment-0001.html>


More information about the es-discuss mailing list