Hacker News Reader

Comment by datadeft | Hacker News Reader

Better yet, we need a new model of running computer programs. I think the good old running a python file through an interpreter that has at least read-only access to ~/ is not cutting it anymore. This is why Apple's additional access (explicitly granting read access to certain user folders to certain applications) is a good step to the right direction.

View on HN

The thing I most want from computing right now is the ability to safely run untrusted code in a sandbox on my own devices.

It feels like we're constantly getting closer to this. We've been mostly able to do this in the browser for years now.

I continue to have high hopes for non-browser WebAssembly. I really, really want to be able to run Python, JavaScript, Rust code etc on my phone and laptop inside a WebAssembly sandbox that tightly limits the filesystem, network, memory and CPU access of that code.

I'm seeing glimpses of this being possible - https://til.simonwillison.net/webassembly/python-in-a-wasm-s... and https://til.simonwillison.net/deno/pyodide-sandbox for example - but it's still not as easy as I want it to be.

While it is perhaps a hamfisted way to approach security, I am getting closer and closer to installing Qubes OS onto my personal machine. A VM boundary between profiles seems the most practical way of keeping private data on my machine.

Everything else feels like trying to patch over the shaky security foundations with just one more abstraction.

Why throw WebAssembly into the mix, especially if you want to run this outside of the browser? What benefit do you see?

WebAssembly should be the world's most robust, well-tested sandboxing technology: it's been running in browsers for five years now, so it's been more extensively tested than anything else.

I want a sandbox that's robust, widely used and widely tested. WebAssembly feels like it should be the best possible option.

If you have a better idea for a sandbox I can use to run untrusted code on my laptop (and phone) I'd love to hear what it is!

Normal machine code runs in even more contexts and has been for much longer. I don't know any numbers on how many mainstream projects are WebAssembly but it feels like a stretch to call it the "worlds most robust and well-tested" anything. And the tech itself doesn't sandbox anything so it just feels like a strange choice.

Use KVM if you're on Linux/Android. It's not about the binaries but where and how it's running, there is 0 isolation in WASM alone, and creating a new runtime to run it outside of browsers will not give you what you're looking for.

Android recently announced they're going the KVM route.

Is it as easy as you want it to be for JS yet? I would think so from your deno example.

The next challenge is finding good, actively maintained WebAssembly binary blobs for all of the languages I care about.

Pyodide provides one that works well for Python.

I'm finding it surprisingly hard to find a good option for JavaScript. QuickJS or one of its forks might work but I've not yet figured out the incantations necessary to do that.

Then there's Lua, Ruby, PHP, etc - ideally I'd like there to be robust, well maintained, well documented WebAssembly versions of any language that I might want to run code from.

Docker doesn’t solve this?

Docker provides virtually no security guarantees on its own and container rights escalation vulnerabilities are a serious threat vector. The default containers provided by many applications are often insecure and ignore recommended security hardening practices. Seehttps://kubernetes.io/docs/concepts/security/overview/ 4 c's of container security.

Sadly it doesn't - Docker isn't specifically designed as a security tool and there are plenty of warnings against using it in this way.

Firecracker is the best I've seen in terms of container security - it was designed by AWS for Lambda and is trusted by people I trust. It's not really packaged for easily running on macOS etc though.

Docker actually worsens this. The default installation of docker makes no effort to prevent host root access from a container. Root in container is root in host

Good idea. We could use a way to restrict visibility of the entine filesystem and only unveil the parts of it that every program declares/needs.

Reply on news.ycombinator.com