Are there any FOSS desktop OS with equivalent security, including proper verified boot and exploit mitigations? If not, why?
Some elevator pitches: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Regarding the elevator pitches provided, QubesOS emphasizes "hardware isolation" and makes claims such as being "better than physical air-gap," though in practice it operates at the virtualization level. The system's fundamental security considerations could benefit from more detailed explanation. The suggestion to store passwords in plain text (even in cases of Xen escape, offline status wouldn't provide protection, and storing in plain text presents risks) might lead to misconceptions about security. While the endorsement by Edward Snowden is noted, it would be helpful to focus more on the technical aspects and implementation details.
Insufficient for what? I'm writing this from Librem 15 with Heads and Librem Key, which confirm that every boot my boot chain wasn't compromised. The whole configuration relies exclusively on free software, unlike proprietary secure boot, which I do not trust. (Also Intel ME is disabled and neutralized.) See also:
https://www.youtube.com/watch?v=hx9MS1_1e2c (#HITB2019AMS D1T1 - TOCTOU Attacks Against Secure Boot And BootGuard - Trammell Hudson & Peter Bosch)
https://forum.qubes-os.org/t/how-exactly-is-heads-pureboot-s...
> Its security heavily relies on OS isolation through the Xen hypervisor, though it remains vulnerable to attacks on the hypervisor itself.
Most vulnerabilities in Xen do not affect Qubes OS at all: https://www.qubes-os.org/security/xsa/
> Furthermore, the operating systems running inside maintain the same characteristics as typical Linux distributions
You misinterpret the Qubes' approach to security. If your VM is compromised, no hardening will save your data (https://xkcd.com/1200/). I'm not using the same VM for everything but dedicated VMs for bank, email, HN, instant messaging and so on. A malware on a random website would only get the access to an empty VM, nothing more.
On Qubes, you should compartmentalize your digital live into security domains, such that you never run anything untrusted in trusted ones and never have anything valuable in untrusted ones. With such approach, hardening is irrelevant. More examples: https://www.qubes-os.org/news/2022/10/28/how-to-organize-you.... See also: https://github.com/QubesOS/qubes-issues/issues/9717#issuecom.... I'm not saying that hardening is useless (Qubes developers are working on it), but it's a much lower improvement in security compared with the first step, i.e., compartmentalization.
> Regarding the elevator pitches provided
Thanks for the critic of my elevator pitches.
> The system's fundamental security considerations could benefit from more detailed explanation.
Indeed, a link like this, https://www.qubes-os.org/doc/architecture/, might be good to add.
> makes claims such as being "better than physical air-gap," though in practice it operates at the virtualization level
Yes, it operates at virtualization level, what's wrong with that? Unless your airgapped computer doesn't exchange files with other computers at all, you are vulnerable to attacks. The linked document shows a detailed explanation of the threat model and when virtualization is more secure. See also: https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...
> The suggestion to store passwords in plain text (even in cases of Xen escape, offline status wouldn't provide protection, and storing in plain text presents risks) might lead to misconceptions about security.
Last time a relevant escape (affecting the current Qubes architecture) was found in 2006 by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_%28software%29
Recently I learned about an interesting approach to this through a presentation at CCC about a small project known as sixos. Go to the part at 18m27s where ownerboot is presented: https://media.ccc.de/v/38c3-sixos-a-nix-os-without-systemd
Repository for ownerboot: https://codeberg.org/amjoseph/ownerboot
There's open standards around this, and I believe it is Google that's for the most part shepherding those:
If you want more mainstream you could go with vanilla Fedora or some spins if you are opinionated about your desktop environment.
If you want more security you can look at things like QubesOS.
Linux distributions' exploit mitigation features include basic ASLR, DEP, and RELRO, but their implementations are incomplete. Advanced protection features like those found in macOS (such as PAC, Pointer Authentication, strict stack protection, and JIT spray attack prevention) are either not implemented by default or are limited in scope.
Resolving these issues would require an enormous investment of time and cost to apply parameters and patches, and these solutions are not available by default.
While QubesOS's approach is interesting, it lacks Secure Boot, and its security relies on sandboxing through OS isolation via the Xen hypervisor, while the operating systems within still contain the aforementioned issues (though running a macOS-level secure OS in QubesOS might be a solution).
What evidence do you have to state that claim?
> including proper verified boot and exploit mitigations? If not, why?
Any operating system with TPM and Secure Boot support has this, Windows, Linux, and FreeBSD is in the planning stages for Secure Boot.
It sounds like you're unaware of the available security features that have been available for a significant amount of time on x86.
On the whole, the distros do a terrible job. If you can modify the initrd (which you can on all of them by default), it's game over.
And that's just secure boot. Linux has no real equivalent to TCC, for example.
Most distributions cannot be considered security-hardened by default.
What do you think is causing this situation?
There's some promising work happening in Fedora land with unified kernel images, undoubtedly due to demand from Red Hat's corporate and government customers.
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor...
Secure Boot on most Linux distributions, except for a few that implement TPM-based Secure Boot like ChromeOS Flex and custom Linux builds, is merely intended for UEFI support and Windows dual-boot compatibility, rather than being a genuine mechanism for detecting OS image tampering.
What exactly is your threat model?
So basically Linux distros without DM-Verity and TPM support? Basically not boot chain verified?
ChromeOS uses coreboot vboot and Flex may use secure boot, but I haven't seen a ChromiumOS fork signed to work with UEFI secure boot, or worse coreboot with vboot, while a Linux distro it's possible with secure boot (I'm not sure about vboot), but to secure it and the software to a similar level, I feel it would just become similar to ChromiumOS, because there's so much software on Linux that is not isolated. I think Flatpak has way too many permissive permissions that even allow access to home directory and system permissions by default. Android apps are better, albeit ChromiumOS doesn't have Android apps enabled, are built with memory safe Java/Kotlin, with denied by default permissions.
QubesOS does isolate Linux applications better than ChromiumOS, but it's just because you can have multiple virtual machines to isolate each Linux application. AFAIK ChromiumOS just uses one virtual machine + container?
It is technically possible to apply DM-Verity but I've only had experience setting it up via initramfs, I heard Android applies it directly from the kernel. Making DM-Verity work on a lot of distros would completely change the way traditional Linux works, and would ideally require something similar to Android and ChromeOS way of working by system updates, to apply those root images. (Or maybe remake a root image, but I want to reduce privilege as much as possible.)
And not just that, traditional Linux out of the gate lets the end-user use root, or a privilege escalation software like sudo/doas, whereas Android/ChromeOS has no root access by default.