Questions about 0days and OS hardening

From what I understand, Qubes entirely relies on the hypervisor for security. My issue is that it leaves me with a single point of failure. AFAIK Qubes doesn’t automatically harden the Linux distributions it uses by default (Fedora, Debian, Whonix) so I’m thinking of hardening it myself. But this leaves me with a few questions.

  1. Are there any tips/tools I can use to prevent or mitigate the effects of a Xen 0day?

  2. Should I try to harden dom0? Even if it means installing additional software to do so?

  3. Are there any good guides on hardening Linux distributions, especially the ones used in Qubes by default? (Fedora, Debian, Whonix)

1 Like

See this (read-only) thread from the mailing list:

And this:

Also, you may also find this thread interesting:

3 Likes

Qubes OS v4+ does not use typical software virtualization methods. VT-d hardware virtualization it uses was broken only once, and it was done by the Qubes founder: Blue Pill (software) - Wikipedia

2 Likes

Well I’ve been eating some brown pellets often… should I call them Blue Pills?

The key is enabling and disabling hardware or isolating it. The software part is rarely taken by itself. So if you know you are not going to use USB or WiFi or some other piece of hardware that session just disable it in the BIOS. Disposables and drivers are also important.

1 Like

@i2p You are of course right. However the number of security-related issues is not high for Qubes over the last years: Xen Security Advisory (XSA) Tracker | Qubes OS. AFAIK it’s noticeably lower than for any other system.

Just comparing the amount of XSAs to other systems isn’t ideal since you have to run OS’ on top of Xen to do anything, but I get your logic since Xen is the lynchpin of Qubes’ security.

@fiftyfourthparallel Not sure what you mean. I did not compare XSAs, because not all of them are relevant to Qubes security. You should count Qubes Security Bulletins instead, and there are pretty few of them.