Hacker News new | ask | show | jobs
by techplex 1499 days ago
The approach deno is taking is very interesting where all packages are sandboxed. I'd be interested to hear the author's thoughts on Deno's approach as a mitigation for supply chain attacks. I understand it won't stop all attacks but it would make them significantly harder. ref: https://medium.com/deno-the-complete-reference/sandboxing-in...
2 comments

This is the way. Unfortunately languages like Python will for implementation complexity/backward compatibility reasons never support something like this natively (unless with workarounds/hacks like compiling it to WebAssembly). It's time to phase out languages that don't. The only Python variants that made a foray into this are PyPy[0] and Monte[1]. It's important to make this sandboxing have only a small overhead, and make it work recursively, so external libraries can import partially untrusted external libraries themselves, thus hollowing out the attack surface at every node of the dependency tree.

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...

> “The approach deno is taking is very interesting where all packages are sandboxed.”

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.

> 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?

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