Problem
Docker Desktop for Windows does not appear to provide a supported, documented way to install and persist a custom OCI runtime such as gVisor runsc.
On regular Linux Docker Engine installations, users can configure alternative runtimes in daemon.json and run containers with:
docker run --runtime=runsc ...
For Docker Desktop on Windows, the Docker daemon and its runtime environment are managed by Docker Desktop, so installing runsc inside a user WSL distribution does not make it available to the Docker Desktop engine in a reliable or supported way.
Use Case
This would be useful for developers running semi-trusted/untrusted workloads locally, especially:
- Sandboxed development environments
- Security testing
- Package/build evaluation
- Local CI-like workloads
- Containers with access to mounted source trees or credentials
Docker Desktop already provides isolation from the Windows host, but containers still interact with a Docker Desktop-managed Linux kernel surface. There are different layers of concern:
- Ordinary container compromise can expose bind-mounted source trees, credentials, or build artifacts.
- Container-runtime or namespace escapes can affect the Docker Desktop Linux environment.
- Kernel-level vulnerabilities could potentially affect isolation between workloads sharing that Docker Desktop-managed kernel.
- With the WSL2 backend specifically, shared-kernel or WSL-integration issues could also potentially affect isolation between WSL distros or expose Windows-accessible files and credentials through mounts and interop.
gVisor would add a useful userspace isolation boundary that reduces direct exposure of the Linux kernel syscall surface for semi-trusted workloads.
The request is to make gVisor usable with Docker Desktop for Windows, including the WSL2 and Hyper-V Linux container backends, without requiring users to abandon Docker Desktop and run a separate full Docker Engine installation inside their own WSL distro or VM.
Why This Matters
- Local AI-agent and code-execution workflows are becoming more common.
- Supply chain attacks (e.g. the recent one in
axios) are becoming quite common. So the issue is not just "run trusted libraries" only, since libraries usually have a dependency tree and we should not rely on these trusted libraries constantly auditing their dependency tree. As such, nowadays, a lot of "trusted libraries" can actually be unsafe.
Problem
Docker Desktop for Windows does not appear to provide a supported, documented way to install and persist a custom OCI runtime such as gVisor
runsc.On regular Linux Docker Engine installations, users can configure alternative runtimes in
daemon.jsonand run containers with:For Docker Desktop on Windows, the Docker daemon and its runtime environment are managed by Docker Desktop, so installing
runscinside a user WSL distribution does not make it available to the Docker Desktop engine in a reliable or supported way.Use Case
This would be useful for developers running semi-trusted/untrusted workloads locally, especially:
Docker Desktop already provides isolation from the Windows host, but containers still interact with a Docker Desktop-managed Linux kernel surface. There are different layers of concern:
gVisor would add a useful userspace isolation boundary that reduces direct exposure of the Linux kernel syscall surface for semi-trusted workloads.
The request is to make gVisor usable with Docker Desktop for Windows, including the WSL2 and Hyper-V Linux container backends, without requiring users to abandon Docker Desktop and run a separate full Docker Engine installation inside their own WSL distro or VM.
Why This Matters
axios) are becoming quite common. So the issue is not just "run trusted libraries" only, since libraries usually have a dependency tree and we should not rely on these trusted libraries constantly auditing their dependency tree. As such, nowadays, a lot of "trusted libraries" can actually be unsafe.