> I do most of my coding in a VM now
Perhaps you may be interested in Qubes OS, where you do everything in VMs with a nice UX. My daily driver, can't recommend it enough.
Perhaps you may be interested in Qubes OS, where you do everything in VMs with a nice UX. My daily driver, can't recommend it enough.
I wonder about something like https://secureblue.dev/ though. I'm not comfortable with Fedora and last I heard it wasn't out of Beta or whatever yet. But it uses containers rather than VMs. I'm not a targeted person so I may be happy to have "good enough" security for some performance back.
some corrections:
> last I heard it wasn't out of Beta or whatever yet
It is
> But it uses containers rather than VMs
It doesn't use plain containers for app isolation. We ship the OS itself as a bootable container (https://github.com/bootc-dev/bootc). That doesn't mean we use or recommend using containers for application isolation. Container support is actually disabled by default via our selinux policy restricting userns usage (this can be toggled though, of course). Containers on their own don't provide sandboxing. The syscall filtering for them is extremely weak. Flatpak (which sandboxes via bubblewrap: https://github.com/containers/bubblewrap) can be configured to be reasonably good, but we still encourage the use of VMs if needed. We provide one-click tooling for easily installing virt-manager (https://en.wikipedia.org/wiki/Virt-manager) if desired.
In short though, secureblue and Qubes aren't really analogous. We have different goals and target use cases. There is even an open issue on Qubes to add a template to use secureblue as a guest: https://github.com/QubesOS/qubes-issues/issues/9755
Hearing not to rely on it from the developer of secureblue is pretty strong case. Thanks.
From that article, it looks like perhaps the difference is that snaps are isolated at the app level, whereas qubes is a layer down, where each qube is a kind of workspace with multiple apps potentially installed in it. That seems reasonable enough, though you do have to be willing to pay the disk and mental overhead cost associated with setting up the same tools multiple times, or maintain playbooks/whatever to automate that, or am I going to figure out how to get my one VSCode instance access to the different isolated environments where I need an editor, and if I do that have I basically compromised the whole system model.