Forgot to put it on the article, but the latest Python requires the Wasmer rc.5 to run! (the final release will be coming very soon)
curl https://get.wasmer.io -sSfL | sh -s "v6.1.0-rc.5"
wasmer run python/python wasmer run python/python@=0.2.0My previous attempts are described here:
- https://til.simonwillison.net/deno/pyodide-sandbox
- https://til.simonwillison.net/webassembly/python-in-a-wasm-s...
pyodide venv .venv-pyodide
source .venv-pyodide/bin/activate
see https://pyodide.org/en/stable/development/building-packages-...
> Pyodide provides an experimental command line runner for testing packages against Pyodide. Using it requires nodejs version 20 or newer.
Looks like it's a recent addition?
I want a robust sandbox I can run untrusted code in, outside of the browser.
error: Spawn failed
╰─▶ 1: compile error: Validate("exceptions proposal not enabled (at offset 0x191a)")
```
We unfortunately didn't get the final release out quite in time...
curl https://get.wasmer.io -sSfL | sh -s "v6.1.0-rc.5"
wasmer run python/python"wasmer run python/python@=0.2.0" on the same machine gets me into Python 3.12.0 almost instantly.
So please wait a bit - subsequent runs will be fast, since compiled Python will be cached.
Any chance `wasmer run python/python` might download a pre-compiled version in the future?
It did give me one warning message:
% wasmer run python/python
Python 3.13.0rc2 (heads/feat/dl-dirty:152184da8f, Aug 28 2025, 23:40:30) [Clang 21.1.0-rc2 ([email protected]:wasix-org/llvm-project.git 70df5e11515124124a4 on wasix
Type "help", "copyright", "credits" or "license" for more information.
warning: can't use pyrepl: No module named 'msvcrt'
>>>Ideally we would download the compiled artifacts instead of compiling as Simon commented... it will be a much better experience for everyone!
What’s the use case? Is it the sandboxing? Is it easier than running Python in a container?
The vulnerability is in kernel syscalls. More info here: https://news.ycombinator.com/item?id=32319067
If you're going to make containers hard to escape, you need to host them under a hypervisor that keeps them apart. Firecracker was invented for this.
Perspective is everything, I guess. You look at that three year old comment and think it's not particularly informative. I look at that comment and see an experienced infosec pro at Fly.io, who runs billions of container workloads and doesn't trust the cgroups+namespaces security boundary enough so goes to the trouble of running Firecracker instead. (There are other reasons they landed there, but the security angle's part of it.)
Anyway if you want some links, here are a few. If you want more, I'm sure you can find 'em.
CVE-2022-0492: https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups
CVE-2022-0847: https://www.datadoghq.com/blog/engineering/dirty-pipe-contai...
CVE-2023-2640: https://www.crowdstrike.com/en-us/blog/crowdstrike-discovers...
CVE-2024-21626: https://nvd.nist.gov/vuln/detail/cve-2024-21626
Some are covered off by good container deployment hygiene and reducing privilege, but from my POV it looks like the container devs are plugging their fingers in a barrel that keeps springing new leaks.
(To be fair, modern Docker's a lot better than it used to be. If you run your container unprivileged and don't give it extra capabilities and don't change syscall filters or MAC policies, you've closed off quite a bit of the attack surface, though far from all of it.)
But keep in mind that shared-kernel containers are only as secure as the kernel, and today's secure kernel syscall can turn insecure tomorrow as the kernel evolves. There are other solutions to that (look into gVisor and ask yourself why Google went to the trouble to make it -- and the answer is not "because Docker's security mechanisms are good enough"), but if you want peace of mind I believe it's better to sidestep the whole issue by using a hypervisor that's smaller and much more auditable than a whole Linux kernel shared across many containers.
So if your docker container gets vulnerable and it can somehow break through a container, I think that with default sudo docker, you might get sudo privileges whereas in default podman, you would be having it as a user run executable and might need another zero day or smth to have sudo privilege y'know?
When was the last time we have heard container escape actually happening?
It's probably better to make some kind of risk assessment and decide whether you're willing to accept this risk for your users / business. And what you can do to mitigate this risk. The truth is the risk is always there and gets smaller as you add several isolation mechanisms to make it insignificant.
I think you meant “container escape is not as difficult as VM escape.” A malicious workload doesn’t need to be root inside the container, the attack surface is the shared linux kernel.
Not allowing root in a container might mitigate a container getting root access outside of a namespace. But if an escape succeeds the attacker could leverage yet another privilege escalation mechanism to go from non-root to root
Like it's also possible in a VM.
What about running non privileged containers! You need really to open some doors to make it easier!
Breaking out of a VM requires a hypervisor vulnerability, which are rare.
Breaking out of a shared-kernel container requires a kernel syscall vulnerability, which are common. The syscall attack surface is huge, and much of it is exploitable even by unprivileged processes.
I posted this thread elsewhere here, but for more info: https://news.ycombinator.com/item?id=32319067
Firecracker is meant to be secure but it's a lot harder to work with.
You can almost think of a prompt injection attack as a supply chain attack - but regular supply chain attacks are a concern too, what if an LLM installs a new version of an NPM package that turns out to have been deliberately infected with malware that can escape a container?
With reverse proxy you can log requests, or filter them if needed, restrict the allowed domains, do packet inspection if you want to go crazy mode.
And if an actor is able to tailor fit a prompt to escape docker, I think you have bigger issues in your supply chain.
I feel this wasm is bad solution. What it brings a VM or docker can't do?
And escaping a docker container is not that simple, require a lot of heavy lifting and not always possible.
I want to build software that regular users can install on their own machines. Telling them they have to install Docker first is a huge piece of friction that I would rather avoid!
The lack of network support for WASM fits my needs very well. I don't want users running untrusted code which participates in DDoS attacks, for example.
I've been trying to find a robust, reliable and easy way to run a Python process in WebAssembly (outside of a browser) for a few years.