Skip to main content

Qubes OS: First Impressions

A few days ago, while browsing security topics online, Qubes OS surfaced—whether via YouTube recommendations or search results, I can't recall precisely. Intrigued by its unique approach to security through compartmentalization, I delved into the documentation and watched some demos. My interest was piqued enough that I felt compelled to install it and give it a try firsthand.

My overall first impression of Qubes OS is highly positive. Had I discovered it earlier, I might have reconsidered starting my hardware password manager project.

Conceptually, Qubes OS is not much different from running a bunch of virtual machines simultaneously. However, its brilliance lies in the seamless desktop integration and the well-designed template system, making it far more user-friendly than a manual VM setup. I was particularly impressed by the concept of disposable VMs for temporary tasks and the clear separation of critical functions like networking (sys-net) and USB handling (sys-usb) into their own isolated VMs.

Although the default Qubes OS environment is Fedora-based, it doesn't feel drastically different from my experiences with Arch or Debian. This reinforces my feeling that the core differences between many Linux distributions are shrinking. It's also a plus that Qubes officially supports templates for Debian and other systems, offering valuable flexibility. (While exploring Qubes, I noted other compartmentalization-focused OS projects exist, like Spectrum OS and RancherOS, though I haven't investigated them yet.)

After using the system for just a few days, I can already see how its compartmentalized approach could be incredibly beneficial for managing different aspects of digital life securely. However, despite my enthusiasm, I'm hesitant to adopt Qubes OS as my daily driver just yet. I encountered a few practical hurdles:

  1. Secure Boot Support: Qubes OS doesn't currently support Secure Boot. This is inconvenient for my dual-boot setup with Windows, as it requires toggling the setting in the BIOS every time I switch operating systems. According to a recent talk, support might arrive with version 4.3, which is encouraging.
  2. Anti Evil Maid (AEM): While AEM is an excellent security concept, its current implementation has significant restrictions that make it difficult to use easily on many systems. My current workaround is just keeping the boot partition on a separate USB drive.
  3. Backup Workflow: The built-in backup tool enforces encryption. While I understand the security rationale, this complicates my preferred strategy of frequent (e.g., hourly) incremental backups to a trusted location. Although tutorials exist for bypassing this, native support for optionally disabling encryption (perhaps with strong warnings) would be a welcome convenience.
  4. Bluetooth: This seems to be a minor point, but Bluetooth isn't supported out-of-the-box and requires additional setup to get working with peripherals.
  5. GPU Passthrough: Setting up GPU passthrough for performance-intensive applications (like gaming) appears non-trivial. This limitation means I'll likely need to keep my Windows installation as a dual boot for gaming purposes.

In conclusion, Qubes OS is a fascinating and powerful operating system with a unique and compelling security architecture. I'm genuinely impressed with its design and potential. However, the current practical limitations prevent me from making it my primary OS at this time. I'll definitely be keeping a close eye on its development, and may revisit it as these areas mature.

Comments

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...

GameConqueror 0.09 -- Linux Game Hacking Tool

If you are a game hacker If you've been looking for a `CheatEngine for Linux` Then you can't miss this. ============================================== GameConqueror is a game hacking tool for linux, it's written in PyGTK and uses scanmem as its backend. It's supposed to be with most useful features of CheatEngine for Linux. Currently, I've implemented almost everything about scanning, involving variant data types and scan types: Data Types: int{8/16/32/64}, float{32/64}, unknown type(int or float) and unknown width(will try each of them), byte array and string Scan Types: equal, greater, less, changed, unchanged, increased(by), decreased(by) This should be enough for most cases, so I decided to release it at the current status. ============================================= Here's how you can get it PPA (for Ubuntu users) https://launchpad.net/~coolwanglu/+archive/scanmem (I've not test it in 32bit environments or Jaunty, do please inform me if it doe...

Fix Google Security Code

Google Security Code (http://g.co/sc) is one type of 2-step verification. This is particularly useful when security keys and passkeys are not available. I have been using it in my LXC containers, until today I found out that it stopped working. It just kept saying "The code is invalid". It is easy to rule out some factors: The code works on other browsers on my laptop. The code works on other devices that are directly connected to the router. So it appears that Google also checks IP addresses besides the security code. Recently I have IPv6 enabled, so most devices that are directly connected to the router have both IPv4 and IPv6 addresses. But  I only enabled IPv4 for my LXC containers. So I guess when a code is generated by device A and used by device B, Google should be able to check that device A and device B are closely located. But in my case, IPv6 address appears on device A but not on device B, which may look suspicious. To fix the problem, I just needed to disable IPv...