FW: Proposal: safeEval

[Mike Samuel]

On Wed, Jun 20, 2018 at 9:52 PM doodad-js Admin <doodadjs at gmail.com> wrote:

> Thanks
>
>
>
> *How can we discuss your idea separately from the library?*
>
>
>
> I’m more thinking at the runtime level than at the “user land”. To be
> honest, I don’t care of “safeEval” on “user land”.
>

You seem to be asking for criticism, but seem to not want criticism of the
only thing that has enough detail for criticism.


> *You talk about options and ACLs but the only hint as to what those might
> mean is the library*
>
> *How would the idea work if not by tree filtering?  AdSAFE did that but
> writing AdSAFE was very different from writing vanilla JS.*
>
>
>
> Yeah, sorry. The purpose is to offer something like “opcode” filtering,
> but in a more expressive and user-friendly way.
>

EcmaScript is specified as a tree interpreter that produces completion
records, not in terms of an ISA.
The spec does not define opcodes, and you've provided no reason to believe
that opcode filtering would provide a better balance between security and
ease of writing than AST filtering.

Having written a JS sandbox, I'm skeptical that either approach would work.
All successful approaches have combined static analysis with at least 2 of
1. large dedicated runtime libraries,
2. source code rewriting, and
3. separation/isolation via realm/origin/worker.
Any pair of these are going to require detailed correctness arguments to
pass muster.

I don't see how we could compare the benefits of your proposal to any other
without a lot more detail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180621/811e1a17/attachment.html>