4 ms·
You can build a foolproof sandbox, but at the 'OS-level', not at the 'language' level. By disabling syscalls and setting resource limits. You can read more her
by PuercoPop 11y ago
You can build a foolproof sandbox, but at the 'OS-level', not at the 'language' level. By disabling syscalls and setting resource limits.
You can read more here: http://www.eelis.net/geordi/#faq http://www.eelis.net/geordi/#faq
- geofft 11y agoI think the link to Geordi is not quite relevant here (although it is super cool): the claim was that it's hard to build a foolproof sandbox out of eval(). If you're using Geordi, since it's a separate process in a chroot, you can't use eval(). If you're giving up on eval(), you can write a foolproof sandboxed JS evaluator in JS alone. Besides, the hard part with all sandboxes is not making the sandboxing itself solid; that's straightforward. The hard part is giving it a sufficiently rich interface to the outside world to do useful things, while not giving it so rich an interface that it can escape through that hole. All the semi-recent vulnerabilities in qemu, for instance, have been in virtual devices, not in actually emulating a processor. Geordi's story is relatively easy, since all it does is compile code and execute it in an intentionally-minimal interface. JS on a web page has thousands of things it can do to the web page or to the outside world, if you want to implement it according to spec.
- PuercoPop 11y agoMy mistake, You are right. I had read the question as foolproof sandbox that included eval. One can see the banning the syscalls approach as cutting the Gordian knot.