We have QubesOS at home

QubesOS at home:
KVM + virt-manager

I can’t withstand the lack of GPU acceleration no more. I decided that my threat model is not that high, but I like to compartmentalize things.

Unfortunately, QubesOS doesn’t have an option just to use it with GPU acceleration and lessened security, as in some other cases like enabling SMT or using it on machines that don’t meet system requirements, still benefiting from other security improvements.

So I decided just to use different VMs with KVM for different purposes. I did some tests and, surprisingly for me, 3d acceleration is pretty decent and might be enough for my needs. But I’m planning to utilize GPU passthrough for some specific cases anyway.

Maybe someone here using similar setup could give me some directions?

Still not sure what distro to use for “Dom0”. Looking at Fedora Workstation since it has decent default security. It won’t be isolated from internet, like Dom0 in Qubes, but I intend to use it only to run virt-manager/gnome-boxes and VPN with firewall killswitch. And for copying things between VMs.

I’m afraid that Fedora Workstation is too bloated for this use-case, and I can choose something with less possible attack surface and more optimized. I was thinking of Secureblue, it looks quite appealing, but it seems like one-person hobbyist project that can vanish at any time (looking at you, Ted), plus I have to put trust in more parties, like uBlue developers, and I’m not ready to do this with my “Dom0”. But would for sure use it in some VM.

And I don’t really want DIY Linux, I just need it to mostly work out of the box, so maybe I’ll stick with Fedora Workstation.

Some other recommendations, personal experience, opinions, pitfalls, guides?

I don’t really know what to look at, would appreciate any input.

2 Likes

I believe QubesOS uses Fedora for dom0 and it is a recommended distro, so if you’re going to manage your own virtual machines on Linux without turning to a more “DIY” solution, Fedora Workstation just makes sense.

That’s a fair concern, but it has been around for some time and if I’m not mistaken, you should be able to re-base onto Fedora Silverblue should Secureblue go south, so you might not have anything to lose. (Fact check me on that.)

If you can’t decide, pick Fedora Workstation since it’s probably going to offer an easier out of the box experience and it’ll definitely stick around for the long-term.

Jonah wrote this when comparing VM setups and QubesOS setups:

But even then, choosing between the two is still highly dependent on one’s threat model, and it’s good that you put yours into consideration.

On the other hand, a flaw specific to QubesOS is that it still uses X11, so apps in the same qube can interact a great deal.

Edit: I think this could also be worth mentioning: ChromeOS can use Crostini VMs to isolate apps, and using VMs on MacOS provides both security through both compartimentalization and firmware/hardware security

Using KVM on a Linux machine to compartmentalize parts of your life is analogous to what Qubes is doing. However, the implementation and tooling of each have different objectives and therefore different tradeoffs.

  • Qubes integrates guest OS windows with the host windowing system and color codes them, which makes it feel like using a normal computer. Using virt-manager is more clunky.

  • Qubes has a secure and very manual implementation of clipboard sharing, while virt-manager could sync your clipboard without you knowing.

  • Qubes keeps dom0 extremely minimal to reduce trusted codebase, while using KVM machines on top of a host system used for other tasks has higher attack surface.

Just a few obvious examples I thought of. Btw, using virt-manager on Secureblue can be a pain because all those packages have to be layered, but it can be done.

I use Proxmox to handle the underlying OS, its not dom0 though.

Qubes is still the best but I think Proxmox is good enough for less extreme threat models. It is Debian based, but I think if it is good enough for enterprise use, it should be good enough for most people.

It does, but since Dom0 mostly isolated from everything else, Qubes can use outdated Fedora with x11.
I will definitely use Gnome because of secure Wayland implementation.

Well, complete re-basing still looks like a too big commitment for me, I might just try to implement manually some of its features and probably some features from Brace.

I do understand that Qubes is superior in terms of security. But I mostly concerned with some degree of privacy preservation, so my threat model include mostly regular apps trying to access everything they can, and not these apps trying to exploit my machine. But I want to do it securely too, without sacrificing usability too much.

This and secure file sharing are the things that I will definitely miss, so I have to learn how to do it less risky.

And even more I will miss USB isolation. When I disconnect USB devices from VMs, they would connect to host, which is not ideal.
Same with PCI devices, which I’m going to passthrough.
Maybe I will find a way to block them from host, limiting their use for VMs only, but I’m not sure that this will have real security benefits and not just illusion of improved security.

The real problem is that I’m not knowledgeable enough to determine such things. QubesOS has very helpful documentation with established view on best security practices and a lot of guides for different cases.

And guides I can find about using virtual machines are mostly centered on absolutely different purposes and problems.

I guess it will be more optimized and resource-efficient for such tasks, but Debian+LTS kernel with web-based interface and orientation on remote management doesn’t sound appealing to me.

Well, think about it, its the VMs/client OS that needs to be on the bleeding edge, wihle the underlying system doesnt really need to change much because it handles a specific and dedicated single task (running VMs).

If you run this on a local network that you control, there shouldn’t be any issue because you are behind a firewall/NAT (you are, right?)