That's something that WebAssembly can't do well either, even if its boundary is secure. Creating a new sandbox means having to start a new instance "from the outside", the virtual machine doesn't have this capability built in.
This is the access security problem, there is another that almost all programming languages and virtual machines haven't even tried to solve, especially in a platform independent way: resource security. If an untrusted program cannot access anything but its own memory, but can still go in an infinite loop or allocate all memory and bring the whole system to a halt, the security architecture isn't as complete as it could (should) be.
Especially combined with process serialization[2], a system that implemented both of these security aspects correctly would make very interesting programs possible.
[0] https://doc.pypy.org/en/latest/sandbox.html [1] https://monte.readthedocs.io/en/latest/intro.html [2] https://stackless.readthedocs.io/en/2.7-slp/library/stackles...
Can anyone clarify this?
My understanding is that packages are not sandboxed, but your entire Deno process is. Meaning that if one part of my app requires full read/write access then any package included in my app also gets it. Is that correct?
Such sandboxing is a secure default, and can help to limit the scope of a supply chain attack, sure, but this doesn’t make packages inherently more secure.
Per-package sandboxing would be cool, although I’m not sure how that would work.
Yes. There has been a discussion on per dependency permissions several times but the conclusions is that it would be difficult to implement and get right semantically. See https://github.com/denoland/deno/issues/171