wslcontainers
Ask AI wslc 2.9.4.0

wslc security: isolation model, limits and preview caveats

Updated 2026-07-27 · 6 min read · wslc public preview

wslc containers run inside a dedicated Hyper-V utility VM. This means stronger isolation than Docker Desktop on WSL 2 — which shares a single Linux kernel across all containers — but weaker than a full VM boundary. The isolation model is similar to Hyper-V isolated Windows containers.

Isolation comparison

Security propertywslc 2.9.4Docker Desktop (WSL 2)Docker Desktop (Hyper-V)
Kernel isolationOwn VMShared kernelOwn VM
--privileged modeNot recognisedSupportedSupported
cap-add / cap-dropNoYesYes
seccomp profilesNoYesYes
AppArmor / SELinuxNoYesYes
Read-only rootfsNo explicit flag--read-only--read-only
User namespaces-u flag--userns--userns

What the VM boundary gives you

  • A kernel exploit in a container cannot read memory from another container's processes because they run in separate VMs. On WSL 2 Docker Desktop, every container shares one Linux kernel.
  • The container cannot access the Windows host filesystem unless a directory is explicitly bind-mounted.
  • There is no Docker socket to mount — so a compromised container cannot escape by mounting /var/run/docker.sock.

Current limitations

  • No fine-grained capability control. You cannot drop CAP_NET_RAW or add CAP_SYS_PTRACE — the flags are not recognized.
  • No seccomp or mandatory access control. The container can make any syscall the kernel supports.
  • No image signing or content trust. Docker Content Trust (DCT) and Notary have no equivalent.
  • Preview software. wslc is a public preview with a changing command surface. Do not use it as a security boundary for production workloads until it reaches general availability.

Practical hardening checklist

  • Never run as root. Use -u 1000:1000 or a distro user. There is no --privileged to accidentally enable, which removes one footgun, but root is still the default.
  • Bind-mount only what is needed. The container cannot see the Windows host at all unless you share a directory. Share the narrowest path, not C:/.
  • Keep the utility VM updated. wsl --update ships kernel and wslc fixes; run it on a schedule the way you patch a host.
  • Prefer named volumes for container data. Files written through a bind mount land on the Windows filesystem with Linux ownership — use a named volume when the data should stay inside the VM.
  • Treat the preview as untrusted for production. No seccomp, no MAC, no content trust. The isolation is strong but the feature set is unfinished; re-evaluate at GA.

Related guides