• 9 Posts
  • 137 Comments
Joined 4 months ago
cake
Cake day: July 7th, 2024

help-circle
  • To me, Endless OS seems to be the best fit for you; install it once and you never ever have to give it a second glance for troubleshooting or whatsoever. It achieves this through using a read-only root file system managed by OSTree with apps installed using Flatpak.. This translates to:

    • The most important system-related files being protected from change by yourself and others.
    • Ensurance that your base installation is exactly the same as the one tested and used by its developers. And thus an (in-)direct quality control and maintenance by the very people that work on it.
    • As the base system is not changing beyond what is provided by the devs, installation of applications is relegated to flatpaks (see Flathub for the App Store).
      • Flatpak is a packaging format that doesn’t interact with the base system to install software; think of it like how applications are installed on your phone. With this, you can still install software you need without compromising changes to the base system.







  • I think we’ve probably already spoken on the matter.

    That’s definitely possible. Unfortunately, I don’t recall it 😅.

    Indeed, Lemmy has a serious dearth of users interested and using secure distros over the averages.

    It’s definitely better at this than the platform that starts with an “R” and rhymes with “shit”.

    Thanks for your efforts; I do not know how to follow users on Lemmy but if I did I’d follow you. Do you have a blog/any other forum you’re more active on?

    That’s such a compliment. This is definitely one of the nicest things I’ve read on Lemmy. I really appreciate it.

    Unfortunately, I’m only somewhat active on Lemmy. FWIW, consider checking out the following places if you haven’t yet:

    And, of course, Qubes OS’ forums.

    Personally, I find it difficult to justify the time to learn Secureblue (especially the immutable part) or NixOS on Qubes because custom DispVMs with curated salt states work so well already. I’m interested in use-cases that will improve my security but I haven’t found any dialogue on this yet. If you do have opinions on this and know where I can look, I would greatly appreciate it!

    As I’ve previously alluded to, I don’t have any hands-on experience with Qubes OS yet. So, I don’t think I can contribute meaningfully in this discussion. However, IIRC, there are some discussions found on the forums/discussions page for Qubes OS.




  • Please allow me to link to an earlier comment of mine that goes over this in more length. You may also find it copied-and-pasted down below:


    First of all, apologies for delaying this answer.

    Disclaimer:

    • I’m not an expert. While I try to verify information and only accept it accordingly, I’m still human. Thus, some falsehoods may have slipped through, my memory may have failed me, and/or what’s found below could be based on outdated data.
    • Additionally, I should note that I’m a huge nerd when it comes to ‘immutable’ distros. As a result, I’m very much biased towards secureblue, even if Kicksecure were to address all of their ‘issues’.
    • Furthermore, for the sake of brevity, I’ve chosen to stick closely to the OOTB experience. At times, I may have diverged with Qubes OS, but Qubes OS is so far ahead of the others that it’s in a league of its own.
    • Finally, it’s important to mention that -ultimately- these three systems are Linux’ finest when it comes to security. In a sense, they’re all winners, each with its use cases based on hardware specifications, threat models, and priorities. However, if forced to rank them, I would order them as:

    Qubes OS >> secureblue >~ Kicksecure

    Context: Answering this question puts me in a genuinely conflicted position 😅. I have immense respect for the Kicksecure project, its maintainers and/or developers. Their contributions have been invaluable, inspiring many others to pursue similar goals. Unsurprisingly, some of their work is also found in secureblue. So, to me, it feels unappreciative and/or ungrateful to criticize them beyond what I’ve already done. However, I will honor your request for the sake of providing a comprehensive and balanced perspective on the project’s current state and potential areas for improvement.

    Considerations: It’s important to approach this critique with nuance. Kicksecure has been around for over a decade, and their initial decisions likely made the most sense when they started. However, the Linux ecosystem has changed dramatically over the last few years, causing some of their choices to age less gracefully. Unfortunately, like most similar projects, there’s insufficient manpower to retroactively redo some of their earlier work. Consequently, many current decisions might be made for pragmatic rather than idealistic reasons. Note that the criticisms raised below lean more towards the idealistic side. If resources allowed, I wouldn’t be surprised if the team would love to address these issues. Finally, it’s worth noting that the project has sound justifications for their decisions. It’s simply not all black and white.

    With that out of the way, here’s my additional criticism along with comparisons to Qubes OS and secureblue:

    • Late adoption of beneficial security technologies: Being tied to Debian, while sensible in 2012, now presents a major handicap. Kicksecure is often late to adopt new technologies beneficial for security, such as PipeWire and Wayland. While well-tested products are preferred for security-sensitive systems, PulseAudio and X11 have significant exploits that are absent from PipeWire and Wayland by design. In this case, preferring the known threat over the unproven one is questionable.
      • Qubes OS: Its superior security model makes direct comparisons difficult. However, FWIW, Qubes OS defaults for its VMs to Debian and Fedora. The latter of which is known to push new technologies and adopt them first.
      • secureblue: Based on Fedora Atomic, therefore it also receives these new technologies first.
    • Lack of progress towards a stateless[1] system: Stateless systems improve security by reducing the attack surface and making the system more predictable and easier to verify. They minimize persistent changes, impeding malware’s ability to maintain a foothold and simplifying system recovery after potential compromises. While this is still relatively unexplored territory, NixOS’s impermanence module is a prominent example.
      • Qubes OS: There’s a community-driven step-by-step guide for achieving this.
      • secureblue: Based on Fedora Atomic, which has prioritized combating state since its inception[2]. Its immutable design inherently constrains state compared to traditional distros, with ongoing development promising further improvements.
    • Deprecation of hardened_malloc: This security feature, found in GrapheneOS, was long championed by Kicksecure for Linux on desktop. However, they’ve recently chosen to deprecate it.
      • Qubes OS: Supports VMs with hardened_malloc enabled OOTB, for which Kicksecure used to be a great candidate.
      • secureblue: Continues to support hardened_malloc and has innovatively extended its use to flatpaks.

    1. This paper provides a comprehensive (albeit slightly outdated) exposition on the matter. Note that it covers more than just this topic, so focus on the relevant parts.
    2. Colin Walters, a key figure behind Fedora CoreOS and Fedora Atomic, has written an excellent blog post discussing ‘state’.


  • bsergay@discuss.onlinetoLinux@lemmy.mlNiche Distro Users: Why?
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    3 months ago

    I daily drive secureblue; or, to be more precise, its bluefin-main-userns-hardened image.

    “Why?”, you ask. Because security is my number one priority.

    I dismiss other often mentioned hardened systems for the following reasons:

    • Qubes OS; my laptop doesn’t satisfy its hardware requirements. Otherwise, this would have been my daily driver.
    • Kicksecure; primary reason would be how it’s dependent on backports for security updates.
    • Tails; while excellent for protection against forensics, its security model is far from impressive otherwise. It’s not really meant as a daily driver for general use anyways.
    • Spectrum OS; heavily inspired by Qubes OS and NixOS, which is a big W. Unfortunately, it’s not ready yet.




  • If security is a serious concern of yours, perhaps consider NovaCustom’s offerings instead. Intel BootGuard is coming to their new models (i.e. the 14 inch V54 the 16 inch V56). Add Dasharo’s coreboot, the possibility to disable Intel Management Engine, (soon hardware-based) kill switches, open source EC, ongoing work to get it Qubes OS certified (like how they managed on their NV41) and perhaps even Heads (also like how they did on NV41). We haven’t even talked about how they’ll soon achieve HSI-3 and their plans to tackle Trenchboot next year.

    It’s a lot of good stuff. And simply unheard of for vendors that are Linux-first. Heck, if their ongoing work on lvfs delivers and they manage to put out updates like industry leader (at least in this regard) Dell does[1], they might even be a contender for most secure laptop for general use.

    While it may seem as if I’ve been gushing a lot already, I have not even mentioned how they fare in other important aspects:

    • Communication and support is excellent and a lot better than any other Linux-first vendor; including both Star Labs and TUXEDO.
    • They’re committed to repairability and sustainability. While they definitely can’t compete with Framework in this regard, they do offer spare parts (including motherboard, CPU, fans, cmos battery and a lot more) for up to 7 years.

    It’s a pity that they’re underappreciated and underrated for not putting as much money into advertising as they do on delivering an excellent product.


    1. Dell is very competent in this regard. So, I honestly don’t expect NovaCustom to seriously compete with them. However, I’m already content if they can compete with Lenovo at this.

  • I could probably summarize your experience as “skill issue”.

    I don’t understand the hype of immutables, or usability even.

    I suppose this article/blogpost by Lennart Poettering should suffice. Though, this article/blogpost by Colin Walters is also cool.

    I tried Bazzite today after Nobara nuked itself, and I couldn’t even paste my old Firefox profile since the actual folder apparently sits within the immutable folder structure.

    This is simply false as pointed out by others already.

    I didn’t even have time to reach the software limitations with how fast I tried the next distro.

    You will have a very hard time on Linux with that mindset. And, to be honest, literally any OS you aren’t already familiar with.

    Still hopping though, because apparently Fedora just nukes itself when you try to install codecs

    I wouldn’t be surprised if you just searched this through your favorite search engine and settled with whatever random solution you came across instead of relying upon RPM Fusion’s documentation on the matter.

    and I think I have about every major distro tested by now.

    While this could be true, I wonder what prevented you from sticking with any one of them.

    Linux is cursed.

    It’s definitely a lot harder if you’ve got major skill issues.


  • Thanks for clarifying!

    IMO immutable distros aren’t a best fit for a desktop computer. It can do so much more than gaming and turning it into a dedicated console is a step back if a normal linux distro can do just as well.

    I would personally nuance this to: Current iterations of ‘immutable distros’ that have evolved from traditional distros haven’t matured sufficiently yet to tackle 99.99% of the use cases ‘easily’.” The exact number on the percentage I don’t know. I believe most people that use their PCs as a glorified app launcher should be more than fine. But we start experiencing major difficulties the very moment that (a)kmods are involved; some of which are ‘supported’~ish, while others certainly aren’t.

    But, I simply fail to see why a future iteration would not be able to solve related issues.