On Sun, Nov 23, 2014 at 3:38 AM, Florian Bösch <[email protected]> wrote:
> On Sun, Nov 23, 2014 at 12:27 PM, Michał Wadas <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
