First thing I do on a fresh QubesOS install is keep the foundation clean. Anything that touches the system—sys-net, sys-firewall, sys-usb, sys-whonix, all the service qubes—stays minimal. I don’t install a thing into the templates attached to those qubes. Same goes for the default DVM. Clean base, minimal attack surface.

When I need to install apps, I don’t contaminate the original templates. I clone the template, rename it, and point my daily App Qubes (personal, work, etc.) to the clone. So if Fedora ships as fedora-41-xfce, mine becomes fedora-41-xfce-custom, and that’s where the apps I need get installed.

If I’m building a sensitive qube—banking, crypto, whatever—I’ll clone the untouched template again and keep that one lean too. Only install what I need. Nothing more.

And this applies to everything in Qubes: Fedora, Debian, Whonix, Arch, Kali… whatever template you bring in. The rule is simple—keep the base template pristine, do your work in cloned templates, and let compartmentalization actually mean something.

Keeping things minimal, isolated, and compartmentalized is one of the cleanest OPSEC habits you can build in QubesOS.

#IKITAO #QubesOS #OPSEC #INFOSEC

Reply to this note

Please Login to reply.

Discussion

@Ava Thanks for the tip. Do you have a dedicated machine for Qubes or do you dual boot? I had trouble with the latter.

I use a dedicated machine. It’s not recommended to dual-boot Qubes because even if the Qubes install is encrypted, /boot isn’t. A second OS can modify it and compromise Qubes before it loads.

Sharing hardware also means the other OS can tamper with BIOS/UEFI firmware, which puts the entire system at risk.

Anti Evil Maid can alert you if /boot was changed, but it can’t prevent it or undo the damage.

It’s also recommended to buy new hardware if you’re serious about security. And if you’re looking to run QubesOS on a dedicated machine, the hardware compatibility list is your friend. With Qubes, newer doesn’t always mean compatible.

It should be noted that the unofficial community-recommended hardware list is for 4.1, and we are on 4.2.4 with 4.3-rc3 already released for testing, but you can find good recommendations and answers on the forum.

https://doc.qubes-os.org/en/latest/user/hardware/system-requirements.html#choosing-hardware

https://www.qubes-os.org/hcl/

https://doc.qubes-os.org/en/latest/user/hardware/certified-hardware/certified-hardware.html

https://forum.qubes-os.org/t/5560

Isn't the BIOS/UEFI firmware closed source? Meaning the attack vector is by intelligence agencies being allowed to install their blobs into the image pre signing?

Put code in boot sector to change BIOS settings, undoes any security for a backdoor.

Some BIOS can be locked with a pin code.

Thank you for taking the time to give such a thoughtful answer.

I use own templates, based on Debian Minimal and Fedora Minimal.

Starting from scratch is a valid approach.

Do you believe in the one template per application strategy?

Not for everything, but for some things, yes. It depends on the application, the attack surface, and the threat model.

If an app touches identity, finances, private comms, or needs special networking—Signal, banking, crypto wallets, torrenting—then it gets its own minimal template. Clean base, small attack surface, no bleedover.

It’s also utilitarian and performance-based. For example, I have a dedicated template and AppQube for gaming.

But for normal day-to-day stuff—if the apps share the same identity and the same risk profile, putting them in one template keeps things sane and still respects compartmentalization.

I isolate by threat model, not by religion.

Thanks for the reply, I appreciate the perspective.

nostr:nprofile1qqsyawyrzrttfmv4cmtx5w2m85702kdct7hv3amfrkhagpdf9cz46mgprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qy3hwumn8ghj7enfd36x2u3wdehhxarj9emkjmn99ulkwmr0vfskc0tpd3kqng2s9w Do you have a backup strategy for Qubes? I ask because when I ran it previously I had data on many different cubes. Thanks!