Now that WSLg support (https://github.com/microsoft/wslg) has landed in a release version of windows, another approach to this is to create new WSL distros for specific tasks, and run browsers from them.
I tried doing some full-screen 3D engine development in SDL through WSL2 early this year, and stood up an X server for it. It didn't go well, so I blew away the WSL and tried running VMware Workstation 16. That was okay, but performance was surprisingly poor. I did some Googling and came to suspect that Hyper-V was the culprit. It was difficult, but I managed to extricate Hyper-V from my system and run the VMware Hypervisor instead. Performance is much better now and I don't have any complaints. Now I'm wondering how this graphical WSL setup compares though. Any experience using VMware Workstation to compare it?
> Another approach might be x11docker [5] with Kata Containers [6].
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.
Also, xpra and waypipe are developed with the intent of being used remotely. They do not have any zero-copy provisions to reduce latency and overhead on local-only applications, like you would get with at least the virtio_wl and WSLg approaches.
Well, in the case of WSLg the sandbox is WSL itself (and you can spin up multiple different ones, though they'd hardly qualify as micro VMs). The only part that "only works on Windows" is the RDP client. The rest is specifically developed for Linux and open source. The backend is an extension of FreeRDP, so presumably the FreeRDP client would be just fine on Linux.
As mentioned to open, containers within VMs are a security standard for cloud-native when security is critical.
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.
> 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.
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.
I love this idea but it's broken a bit if webcams and mics can't be used at least for my use-case. If I had some time I'd look into extending that with this project.
If they're USB devices, you can try tweaking the docker-machine VM definition in whatever hypervisor your Mac uses, so that the devices are mounted directly in the VM and are thus available to containers.
Have a look at Qubes OS then : https://qubes-os.org. It's even more secure (hardware VT-d virtualization), with a nice gui and allows to use webcams and microphones securely.
Pulseaudio has network support. You should be able to share your microphone. Of course you need to run pulseaudio inside the container, too. So it's no longer an application container, but a system container.
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.
Some time ago I have done something similar: https://github.com/grzegorzk/ff_in_podman
It's interesting to see, that hardened browser executed from container is actually quite unique setup (and hence, in a way, easy to spot unless many people are using same setup).
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... )