Qubes OS, security-oriented operating system, has a much higher security than MacOS: https://qubes-os.org.

Some elevator pitches: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15

QubesOS lacks Secure Boot implementation and has insufficient boot chain protection. Its security heavily relies on OS isolation through the Xen hypervisor, though it remains vulnerable to attacks on the hypervisor itself. Furthermore, the operating systems running inside maintain the same characteristics as typical Linux distributions (incomplete exploit mitigation features, weak kernel protection mechanisms, insufficient system call and memory protection), and the security within containers remains limited (unless running an OS with macOS-level security, the internal OS security remains inadequate).

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.

> QubesOS lacks Secure Boot implementation and has insufficient boot chain protection.

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

Apple's approach to verified boot is pretty intense: https://support.apple.com/guide/security/boot-process-secac7...

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

Android and ChromeOS also do secure, trusted, and verified boot.

There's open standards around this, and I believe it is Google that's for the most part shepherding those:

https://opentitan.org/

https://trustedcomputinggroup.org/

https://trustedfirmware.org/

Yes, Fedora Silverblue would be my recommendation for something balancing security but being mainstream enough.

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.

Fedora Silverblue's Secure Boot is also primarily for UEFI support and not fundamentally designed to create a boot chain or detect attacks on the OS. Additionally, it has weaknesses in kernel protection mechanisms (insufficient kernel module loading restrictions), inadequate system call protection, and incomplete memory protection mechanisms. While its immutable design is notable, the detection and defense mechanisms against base system attacks are inadequate, with limited security verification of the rpm-ostree system itself.

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).

> macOS have superior security compared to standard Linux/BSD distributions even at the software level

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.

There is a huge gap between what's available for Linux (ie the Android and ChromeOS boot systems), and what the mainstream Linux distributions actually implement.

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.

I agree. I haven't seen any Linux OS with proper security featuring dm-verity-based Secure Boot (except for documentation in Arch explaining how to implement it).

Most distributions cannot be considered security-hardened by default.

What do you think is causing this situation?

I assume lack of priority because it's boring, compared with the shiny features developers tend to care about.

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...

While Linux systems like ChromeOS and Android could be considered sufficiently hardened, mainstream distributions generally don't prioritize security, with developers simply creating what they prefer. They lack comprehensive security features like those found in macOS (e.g., SIP, XProtect, MRT, Gatekeeper and other multi-layered protection mechanisms).

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.

> 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.

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.

Yet all these security features fail due to the insecure browser, Safari, not implementing site isolation.

What exactly is your threat model?

Safari actually implements Site Isolation. Process-per-tab isolation was introduced in Safari 15 in 2021, and site isolation features were further enhanced in Safari 16.4.

This is false, https://news.ycombinator.com/item?id=42859836