QubesOS – A reasonably secure operating system

>You still have to get through Xen to get to anything I consider of value.

It's not unthinkable, as Xen is huge, at hundreds of kLoCs. But there's an effort[0] to make a Qubes that uses seL4 in place of Xen.

0. https://trustworthy.systems/projects/TS/makatea

I've been using Qubes for the past 2 years while going to school, and I found it really fun and helpful. A lot of professors had me download random closed source software from random websites during the pandemic, and it was easier to download it to a VM than to convince them about Free Software. More than that though it's been really helpful just for my own workflow. I can hit a keybind and start working from essentially a fresh linux install. It's easier to stay on task when each VM is designed to only do one kind of task. It's also nice having debian, fedora, windows, kali, and whonix all easily accessible on the same machine.

The main sticking point for me is that Qubes is reasonably secure from _myself_. I make mistakes. I first started using linux with an Ubuntu install that I broke a year later because I accidentally added in a space when typing `rm -rf ~/Arduino` which made it `rm -rf ~ /Arduino`. On Qubes I can `sudo rm -rf /` on the VM I'm using right now and not break a sweat. I have a keybind to spawn a disposable "airgapped" VM to deal with sensitive or untrusted data, and it helps knowing that even if I mess up with whatever I'm doing, the VM will keep everything reasonably contained.

Some cool things that Qubes has outside of just VMs are its features enabled by the communication between VMs. Notable ones are Split GPG (https://www.qubes-os.org/doc/split-gpg/) which let you use a VM as if it were a smartcard for GPG and Split SSH (https://github.com/Qubes-Community/Contents/blob/master/docs...) which let you isolate your private SSH keys from your VM running your SSH client.

There are some sticking points around Qubes. For instance, I use Tailscale to connect my computers to each other from anywhere. Tailscale's install scripts add their keys to my VM's package manager for updates and installs. The proper way to do this in Qubes is to clone a TemplateVM, run Tailscale's install script, update, install, and then base an AppVM off of it. But that creates an entire new OS taking up storage and requiring updates. You can hack a way around this in an AppVM which saves a considerable amount of space, but it takes a lot of upfront time to do and requires you to manually update it.

Another sticking point is hardware acceleration. The desktop environment has access to hardware acceleration, so it runs fine, but opening videos in AppVMs is all software decoded. I'm on a Thinkpad T580 and it can run 1080p videos, but the fans turn on and can't do 4K. When I want to game or do something GPU heavy I either stream from my tower or completely switch over.

Overall, I'm really happy with Qubes and I'm planning to stick with it on my laptops.

I use Qubes because of one exact feature: single Desktop Environment for windows from different Virtual Machines. And AFAIK there are no alternatives.

Use it for work, development, personal tasks for about 2 years so far.

But it has many restrictions, e.g. gaming is problematic because of this single "main" desktop and trucking cursors bug, recording screen when there are several monitors is bugging and problematic, streaming or working with graphics is problematic, development that requires other virtualization like android (as i heard) is problematic (though docker works, tested).

This OS is enough for my tasks, I like concept of separating activities, e.g. when i share desktop on skype, people see only skype's VMs windows. And single Desktop Env is killer feature.

But because of many restrictions this OS is definitely not for everyone.

Also remote desktop cannot be done at least by usual means. And this is big No if you need to work remotely sometimes.

>If you do malware analysis, Windows VMs in isolation on a throw-away laptop is better. >If you do penetration testing, Windows or regular Linux will be better, too.

I am going to firmly disagree with these two points.

I've been a red teamer at one of the three big cloud providers for over a decade, and a passionate hobbyist with both malware RE and offsec (CTFs, bug bounties, etc). I've reversed easily 2000+ different samples of malware, have more CVEs than I can count (several dozen), and can make my way through a corporate network quicker than almost any known APT group.

I use Windows qubes, both as sandboxes and for certain utilities that only run on Windows, and I do pentesting from Linux-based qubes.

There is precisely one restriction I face with Qubes in my entire line of work: even with two GPU's installed for isolation purposes, Nvidia GPU's (even with FLReset+) do not like being passed through by Xen. Older AMD cards like my RX 580 work fine.

That said, there are only two things I'd have any use out of a GPU for - hash cracking (obvious) and LLM workloads (code generation, to speed up PoC prototyping, tool development, etc).

Fortunately, I have access to a six figure rig dedicated to hash cracking at work, as well as effectively unlimited usage of a non-local code generation LLM.

There is no circumstance in which running Windows on bare metal is ideal or optimal in any way whatsoever for just about any kind of security work.

Linux is better in some ways, but even then, segregating workflows in ring3/userland is a must, and Qubes makes this painless, quick, and easy compared to spinning up a bunch of VMs in your distro of choice.

The USP of Qubes isn't that it does anything magic to make a level of security possible that isn't on other platforms, it's how it makes attaining and maintaining that level of security so effortless and seamless compared to other solutions.

The only alternative I've played with that comes close (imo) is Subgraph OS, but it's really not an exaggeration to say that project is absolutely still in alpha status of development, and I would not yet rely on that for sensitive workloads.

One aspect of what you said that I do agree with and wholeheartedly support is hardware isolation. Even with Qubes, hardware isolation is a fine solution to Xen HV exploits, for the tiny handful that have affected Qubes' Xen implementation.