3 ms·

QubesOS lacks Secure Boot implementation and has insufficient boot chain protection. Its security heavily relies on OS isolation through the Xen hypervisor, tho

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.

fsflover 2y ago
> 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 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-secure/23092 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/ 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/ 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-your-qubes/ https://www.qubes-os.org/news/2022/10/28/how-to-organize-you.... See also: https://github.com/QubesOS/qubes-issues/issues/9717#issuecomment-2603438914 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/ 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-using-a-separate-physical-machine 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 https://en.wikipedia.org/wiki/Blue_Pill_%28software%29

fsflover 2y ago

> 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 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-secure/23092 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/ 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/ 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-your-qubes/ https://www.qubes-os.org/news/2022/10/28/how-to-organize-you.... See also: https://github.com/QubesOS/qubes-issues/issues/9717#issuecomment-2603438914 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/ 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-using-a-separate-physical-machine 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 https://en.wikipedia.org/wiki/Blue_Pill_%28software%29