6 ms·

Are there any FOSS OS with macOS-level security?

• deleted 2y ago
  [deleted]
• Iolaum 2y ago
  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.
  • nicecars 2y ago
    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).
• fsflover 2y ago
  Qubes OS, security-oriented operating system, has a much higher security than MacOS: https://qubes-os.org https://qubes-os.org. Some elevator pitches: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
  • nicecars 2y ago
    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
• p_ing 2y ago
  > 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.
  • bigfatkitten 2y ago
    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.
    • nicecars 2y ago
      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?
      • bigfatkitten 2y ago
        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_Support_Phase_2 https://fedoraproject.org/wiki/Changes/Unified_Kernel_Suppor...
  • nicecars 2y ago
    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.
• evanjrowley 2y ago
  Apple's approach to verified boot is pretty intense: https://support.apple.com/guide/security/boot-process-secac71d5623/web 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 https://media.ccc.de/v/38c3-sixos-a-nix-os-without-systemd Repository for ownerboot: https://codeberg.org/amjoseph/ownerboot https://codeberg.org/amjoseph/ownerboot
  • deleted 2y ago
    [deleted]
  • ignoramous 2y ago
    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://opentitan.org/ https://trustedcomputinggroup.org/ https://trustedcomputinggroup.org/ https://trustedfirmware.org/ https://trustedfirmware.org/