a future caller alternative ?

Mark S. Miller erights at google.com
Fri Mar 8 15:27:44 PST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/829f7ae8/attachment.html>


More information about the es-discuss mailing list