Whilst it's a VM, I've found start-up time for WSL instances to be pretty quick, and it's pretty easy to create and clone a template VM (one approach https://raesene.github.io/blog/2020/05/31/Custom_Pentest_Dis... )
although cmake + vcpkg + vc work just fine, it even does up to C17 if that is more your thing (minus optional annexes).
A quick check there shows the vmmem process on my machine is sitting at 1.3GB with one WSL distribution started, which doesn't seem too bad.
Containers within VMs are a norm for security in cloud-native . Some lessons there could be applied to desktop.
One option is the approach of Spectrum OS . They use crosvm (same as what Firecracker "micro VMs" uses) and virtio_wl .
Another approach might be x11docker  with Kata Containers .
Curiously, the work for WSLg (WSL with graphics)  to support graphical Linux guest VMs could also be applied on a Linux host.
Why all the complexity? Just qemu/kvm and xpra, waypipe, whatever would be way simpler and in turn have way smaller of an attack surface. Same if you don't need virtualisation, just use bubblewrap instead of docker etc. It will even give you more fine grained control and you can just use your distributions package manager to keep everything up to date.
Ah ok, I thought they have an X server running under windows, but apparently not. (Was that in some previous version? I remember reading that.)
> so presumably the FreeRDP client would be just fine on Linux.
Memory sharing would need support by the hypervisor I guess, that probably means hacking FreeRDP, rdp-wayland-backend and the hypervisor :\
Edit: This is the most interesting commit: https://github.com/microsoft/weston-mirror/commit/f590a956c3...
Search for "shared" and "gfxredir"
x11docker is just a (very convenient) security layer for containers which need to expose graphics (and possibly webcam, audio, networking, clipboard, printers...). Kata Containers are just "micro VMs" where you spin up a separate kernel to drop the container into.
Bubblewrap is okay if you trust your kernel, but locking the app away in its own VM with its own kernel gives another layer to bust through.
Yeah, thats what I meant, you can just use kvm and your gui/audio/etc. stuff directly instead of having all the unnessecary complexity and dependency those layers bring along.
> Bubblewrap is okay if you trust your kernel
Thats why I proposed it for when you don't need virtualisation. You can ofc also use it in a VM to further restrict processes.
Kata or crosvm are kind of the only games in town as far as "micro VMs" go.
For Chrome inside a container, I also install the Google Talk plug-in. Unsure if that's still required, but things work well.
: i.e. "--group-add plugdev", "--device /dev/hidraw4", "--device /dev/video4", "--device /dev/snd", "--device /dev/sri" and similar
I used system containers in the past, they are not always easy. No idea whether it would work with podman.
Now that I think about it: The browser obviously uses the display of the host. How? Only over X11 network protocol? That worked in the past, does it still work today? I thought modern browsers would need /dev/dri/? If that is made available, why would Webcams not be possible?
If you read the examples you'll see that they mount /tmp/.X11-unix in the container, thats where the X-Sessions Unix domain socket is. You can do the same for pulseaudio. But you shouldn't. Use Wayland and Pipewire if you are actually interested in using this as a security measure, since they are built for sandboxing.
> I thought modern browsers would need /dev/dri/?
They only need it for hw-acceleration. You can also give the container access to it if you need that.