4 ms·
Based on this exploit if not on general principle, it seems advisable to wrap a sandboxing runtime in additional protections. For example codepad.org says: "Whe
by minopret 14y ago
Based on this exploit if not on general principle, it seems advisable to wrap a sandboxing runtime in additional protections.
For example codepad.org says: "When your app is remote code execution, you have to expect security problems. Rather than rely on just the chroot and ptrace supervisor, I've taken some additional precautions: The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections. The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically."
- gngeal 14y agoGiven a sane language and a sane exposed API, it's not difficult to limit what the remote code can do. It's just that bolting a software-based isolation layer ("sandbox") on top of something existing can be expected to yield a few holes in the process. If I were to use anything existing, it would be something like Lua. Just strip away the standard library API and replace it with something strictly under your control.
- justincormack 14y agoLua is much more sane because you have much more control of what is accessible to code than you have in Python.