Eval, literal eval, safe eval

[Mark S. Miller]

On Sun, Nov 23, 2014 at 3:38 AM, Florian Bösch <pyalot at gmail.com> wrote:

> 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.
>

SES uses the term "confine", as that's what it does -- much better than
sandboxing.


>
> 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");
> }.
>

Not in SES, by use of Object.freeze, etc, to freeze the primordials of the
SES realm on initialization. We have a design and partial implementation
for CES -- Confined EcmaScript, which is like SES except the primordials
are not frozen. As a polyfill, this wasn't worth completing. With Realm API
support, perhaps we'll revisit.


>
> 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.
>

Among other things, yes.


> 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.
>

See SES.



>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141123/dd3590ec/attachment.html>