Comment by MobiusHorizons
1 month ago
I’m sure you are aware the sandbox that requires maintaining is v8 itself. Of course there are ways for the wrapper to break the sandbox by providing too much in thr global context, but short of that, which the application code could easily do as well, I don’t see why a wrapper should require significant resources to maintain beyond consuming regular updates from upstream. Is there some other reason you hold such a high bar for what is basically just python glue code for the underlying v8 embed api?
None of those v8 solutions provide what I need:
1. The ability to restrict the amount of memory that the sandboxed code can use
2. The ability to set a reliable time limit on execution after which the code will be terminated
My third requirement is that a company with real money on the line and a professional security team is actively maintaining the library. I don't want to be the first person to find out about any exploits!
Gotcha I hadn’t factored those capabilities into the concept of sandbox, but I can see why they would be important features.
I will admit I don’t really understand why the library that wraps v8 requires a security team in your view, given that v8 itself definitely has one. I’m trying to understand what you see as the dangerous piece of such code likely to lead to exploits. I’m probably missing something, but I fail to see where the complexity lies.
The biggest one is I don't want someone submitting malicious (or just poorly designed) code that crashes my server - hence the focus on memory and CPU limits.
I also need to limit filesystem access - don't want them stealing private files from elsewhere on the system, or filling the disk with garbage data (again causing a crash).
Network access restrictions are important too - I don't want my server becoming part of some DDoS attack, or an attacker using it to hit supposedly safe internal endpoints (SSRF).