Hacker News Reader

Comment by paulryanrogers | Hacker News Reader

> The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source.

Guessing it uses containerization or virtualization, hopefully with no gaps in security.

View on HN

I don’t know that it uses either of those tools as the built-in approach. It could have changed, but last I read, it used V8’s built-in Isolate concept to provide the sandbox and that when an Isolate is created, it is only provided the underlying system access specified by CLI flags or other options e.g. Filesystem, Network, etc...

According to its architecture description ¹, there are no containers or virtualization involved in Deno.

I found deno::CoreIsolate in the source ². Userland process isolation seem to be provided by V8 Isolate.

The execution and security model remind me of recent trend in FaaS, in particular running WebWorkers (or similar), WASM, etc. Found a fascinating presentation about how V8 is used at CloudFlare ³.

"..using V8 isolates instead of containers or VMs, achieving 10x-100x faster cold starts and lower memory footprints.."

---

¹ https://deno.land/manual/contributing/architecture#schematic...

² https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd...

³ Fine-Grained Sandboxing with V8 Isolates - https://www.infoq.com/presentations/cloudflare-v8/

V8 is a sanbox by default, it does not expose any I/O functions. not even to the stadart output.

https://github.com/denoland/deno/blob/9090023c33de7b64ae4142...

Deno runs js in v8 and all syscalls go through the rust runtime. The limitations are pretty coarse (but i'd say a great start).

It's running Javascript, not native code. You virtualize (and containerize, if you believe that's a meaningful security boundary) to handle execution of arbitrary native code --- or of runtimes, like Node.js, that proxy to arbitrary native code. The Deno runtime deliberately doesn't do this.

But couldn’t the code you download easily just execute `rm -rf / --no-preserve-root`? The problem isn’t executing code from a random URL (which NPM still has); it’s that even though there’s a sandbox, there’s still ways out of it.

Not in Deno. To run that, you’d need to shell out, which Deno won’t let you do without explicitly granted permission at the CLI.

You can in Node, because Node bridges the whole platform standard library by default. Deno does the opposite: you have to opt programs into the platform capabilities you want to give them.

Which you will nearly always give permission to do anything useful.

Others have noted Deno has good protections around this, but I would add that it has those because running a package from NPM is in and of itself just executing code from a random URL, and that has caused plenty of problems in the past.

Reply on news.ycombinator.com