I use QubesOS with detached boot partition on 2 duplicated USB drives with any data that rests on the SSD/HDDs being encrypted with LUKS2. Whonix gateway is proxied through a VPN qube to hide Tor IPs (can't hide communication patterns) without bridges since bridge IPs can be farmed. Sometimes Tor through I2P outproxy or vice-versa or with different anonymizing network overlays. Clients used for browsing are only opened in on-RAM ephemeral qubes with no access to permanent storage. Attack surface is quite minimum since no extra things added like USB mouse and no PV qubes (aside from sys-usb and sys-net) are used for launching HVM qubes with qemu stub domains unless very necessary and every other qube on the system gets shut down first to keep information leakage minimum. A veracrypt volume with hidden storage on a permanent qube for data storage and plausible deniability.
what's your setup like?
Anonymous · 2026-07-24 21:49 [#11931][report] >>25573 Just basic bitch qubes, I don't have a threat model that sees a use-case for proxychaining onions or includes evil maid attacks(my qubes machine stays locked in the lab or on my person at all times) so whonix qubes are good enough for me. Do you have a threat model that necessitates this or is this an academic/recreational exercise?
Anonymous · 2026-07-24 22:30 [#11934][report] >>25574 >is this an academic/recreational exercise? no, this setup has a very practical purpose
near or nation state level remote actors with access to process-inside-namespace-sandbox-to-root kind of vulnerabilities. since it's not practical to slap seccomp on top without changing source code or even whole architecture of the applications
the hypervisor kernel is actually written with security in mind unlike linux and has less attack surface. they try to conform to some MISRA rules.
though I agree Xen isn't the best compared to say microkernels with mathematical proofs but it's still terrificly more secure without giving up too much convenience and compatibility