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).
Harden and secure browsers in containers, with GUI
21–30 of 32 posts
Re: Harden and secure browsers in containers, with GUI
#22I was just looking into various approaches to use process isolation for security on the desktop in Linux. Containers within VMs are a norm for security in cloud-native [1]. Some lessons there could be applied to desktop. One option is the approach of Spectrum OS [2]. They use crosvm (same as what Firecracker "micro VMs" uses) and virtio_wl [3][4]. Another approach might be x11docker [5] with Kata Containers [6]. Curi…
> 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 dat…
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.
Re: Harden and secure browsers in containers, with GUI
#23Earlier quoted context omitted.
> 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 dat…
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…
> 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.
Re: Harden and secure browsers in containers, with GUI
#24Earlier quoted context omitted.
> 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 dat…
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.
I didn't know virtio_wl, it looks pretty neat. WSLg doesn't seem to have too much focus on sandboxing and only works on windows :(
Re: Harden and secure browsers in containers, with GUI
#25Earlier quoted context omitted.
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…
> 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 tho…
x11docker is really just a ~10K lines bash script. You'd just be reinventing or copying parts of it.
Kata or crosvm are kind of the only games in town as far as "micro VMs" go.
Re: Harden and secure browsers in containers, with GUI
#26Earlier quoted context omitted.
I have used SDL on Windows with VC++ since 20 years now, so why bother at all with WSL?
I do basically all my development in Linux. I just wanted to be able to also do some of that work on a particular Windows system sometimes.
Fair enough,
although cmake + vcpkg + vc work just fine, it even does up to C17 if that is more your thing (minus optional annexes).
Re: Harden and secure browsers in containers, with GUI
#27Earlier quoted context omitted.
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.
I didn't know virtio_wl, it looks pretty neat. WSLg doesn't seem to have too much focus on sandboxing and only works on windows :(
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.
Re: Harden and secure browsers in containers, with GUI
#28Earlier quoted context omitted.
I didn't know virtio_wl, it looks pretty neat. WSLg doesn't seem to have too much focus on sandboxing and only works on windows :(
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.
> The only part that "only works on Windows" is the RDP client.
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 :\
Re: Harden and secure browsers in containers, with GUI
#29Earlier quoted context omitted.
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.
> The only part that "only works on Windows" is the RDP client. 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 :\
I haven't really looked at this yet: https://github.com/microsoft/weston-mirror/tree/working/libw...
Edit: This is the most interesting commit: https://github.com/microsoft/weston-mirror/commit/f590a956c3...
Search for "shared" and "gfxredir"
Re: Harden and secure browsers in containers, with GUI
#30Earlier quoted context omitted.
For the (few) docker-based browser containers I use, I simply bind-mount[1] the relative devices and (in Chrome) it all just works. For Chrome inside a container, I also install the Google Talk plug-in. Unsure if that's still required, but things work well. [1]: i.e. "--group-add plugdev", "--device /dev/hidraw4", "--device /dev/video4", "--device /dev/snd", "--device /dev/sri" and similar
I almost don't want to ask as I know the answer is likely to be not great but can this also be done on mac?
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.