Eval, literal eval, safe eval

[Florian Bösch]

On Sun, Nov 23, 2014 at 12:27 PM, Michał Wadas <michalwadas at gmail.com>
wrote:

> literal_eval description:
> >The string or node provided may only consist of the following Python
> literal structures: strings, numbers, tuples, lists, dicts, booleans, and
> None.
>
Also known as JSON.parse.


> My proposition is "safe eval".
> Safe eval ( eval.safe(string: code, callback) ) should perform theses
> steps:
> - Create isolated realm without capabilities to perform almost any IO
> (implementation dependant - no XHR, no importScript, no require)
> - evaluate code in context of created realm
> - post result of last evaluated expression back to creator realm using
> structured-clone algorithm
> - call callback with returned data
>
> Pros:
> + sandbox offered by language
> + easy to run in other thread
> + quite easy to polyfill
> + servers can send computations to users
> +
> Cons:
> - Realm creation can be costly (but implementations can solve this
> problem in many ways)
> - proposal does not include support for asynchronous operations

evalSandboxed would perhaps be a better term.

Btw. you can do a sort of sandboxed eval today by overriding all names
found in window. There are some caveats however. The so sandboxed code can
still access (and change) object internals, such as
"mystring".constructor.prototype.asdf = function(){ console.log("gotcha");
}.

A sandboxes primary purpose isn't just to restrict access to global
symbols, it's also to prevent it from corrupting the surrounding codes
internals. One way to do that of course would be to have the so sandboxed
code run in total isolation on a separate VM instance, however there's some
issues with that too.

It would often be the case that you'd want to provide an interface to the
sandboxed code. So sandboxing alone isn't quite sufficient, you'd also need
to have a suitable API/syntax to describe interfaces, safe to pass to the
sandboxed code, such that the sanboxed code cannot corrupt any piece of
those interfaces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141123/ecaf1191/attachment.html>