1. 32
  1. 25

    When I encounter material like this I just usually skip to the distribution recommendations.

    Avoid distributions that freeze packages as they are often quite behind on security updates.

    This is a common fallacy, and they give their reasoning below, that most security issues does not get a CVE. This is only true if you believe every use-after-free, buffer underflow/overflow and C issues are inherently security issues. You might disagree but I don’t think that is the case as many lack any demonstration of being exploitable. It avoid the actual problem of CVEs and security issues (in my opinion).

    Use a distribution with an init system other than systemd. systemd contains a lot of unnecessary attack surface; it attempts to do far more things than necessary and goes beyond what an init system should do. An init system should not need many lines of code to function properly.

    This is again the same old rambling from anti-systemd enthusiast. This is only true if you consider local exploitability, but I regard this as a non-issue. You have other problems at this point. Since you can’t prevent security issues, and exploitable issues, you should seek out projects that take security issues seriously and demonstrate they can handle them, along with them actually being discovered. Remember, the amount of CVEs in a project is a sign of maturity, not insecurity. I’d be more cautious of software that is popular but has no issues. It means people are not looking.

    Use musl as the default C library. musl is heavily focused on minimality which results in very small attack surface whereas other C libraries such as glibc are overly complex and prone to vulnerabilities. For example, over a hundred vulnerabilities in glibc have been publicly disclosed compared to the very few in musl. While counting CVEs by itself is often an inaccurate statistic, it can sometimes be used to represent an overaching issue such as in this case. musl also has decent exploit mitigations, particularly its new hardened memory allocator.

    Again, I disagree with the premise and the conclusion. While the musl project is great. I don’t think these comparisons are useful and just furthers FOSS maintainers distaste of CVEs.

    Preferably use a distribution that utilizes LibreSSL by default rather than OpenSSL. OpenSSL contains tremendous amounts of totally unnecessary attack surface and follows poor security practices. For example, it still maintains OS/2 and VMS support — ancient operating systems that are multiple decades old. These abhorrent security practices are what led to the dreaded Heartbleed vulnerability. LibreSSL is a fork of OpenSSL by the OpenBSD team that applies superior programming practices and eradicates a lot of attack surface. Within LibreSSL’s first year, it mitigated a large number of vulnerabilities, including a few high severity ones.

    While again, libressl is a cool project (at best). I don’t think it serves the same purpose it did after hearthbleed. OpenSSL has gotten a ton of eyeballs and development time since then and LibreSSL breaking APIs leading to extensive patching upstream makes it hard for proper adoption. It’s also still C so “superior programming practices” is just moot.


    This reads like an ode to some favorite distribution or way of living instead of giving sound advice. If you want to harden you system you should consider a few options. Exploitability and post-exploitability.

    Post-exploitability: If systemd does get pwned, you can still mitigate some attack vectors. This is where compilation flags are important, along with kernel hardening. If this is what you care about, please do secure your system. A lot of the notes here are good in this regard as well. This is where I believe the threat-model from QubesOS comes inn (please correct me on this).

    However, if you care about exploitability following this guide doesn’t give you much. You want a distribution that cares about reacting to security issues, CVEs and applying the appropriate patches. Which distributions are these? I defer to the open-wall distro embargo list usually. Distributions that has the overhead to participate has the intentions of doing the right thing.

    If the distro is not on this list, try look up their security team and figure out if they are organized and publish advisories. This is again a good indication they are trying to do the right thing. But it’s important to realize that security teams in volunteer run distributions can never get all of the CVEs. This can only be done by the 3 enterprise distros: RedHat, Canonical and OpenSUSE. There are collaborations between all of us, but it’s a lot of work.

    Disclaimer: Been contributing to the Arch Linux security team since 2017.

    1. 10

      This article provides all sorts of advice but lacks a threat model. I don’t think its purpose is to provide one, and that’s why caution should be taken when implementing some of this. Really, a defense in depth style approach would be better: assume someone does have root via a local privilege escalation, if that’s what you’re worried about. How do you protect your assets?

      No one that’s running and has to secure a large academic cluster is going to run Gentoo, for instance. They’re probably going to install RHEL. The real question is how your defense in depth works, not if and when someone inevitably pwns your systemd.

      (Of course, if that’s part of your threat model, you may want to include it in your defense in depth too.)

      1. 5

        This article provides all sorts of advice but lacks a threat model.

        Yessss, more of this. We can discuss security but without a proper model of what we are protecting you are just doing a lot of fancy theater without really getting anywhere. Having a realistic model helps you implement proper measures and should be the starting point of any hardening endeavor. I think introducing some concepts such as “exploitability” and “post-exploitability” are maybe bad words, but gives people some words to hang ideas around.

        1. 2

          One thing I’ve heard reiterated is that a checklist is a “bare minimum” when implementing secure systems. This article is a checklist. Like any other checklist, following it exactly will likely result in an unusable system, and only following it will result in a false sense of security.

          1. 2

            Those checklist are usually either guidelines or baselines internal to your company.

            Guidelines are usually thought through and apply the security concepts mentioned above like defense in depth.

            Baselines are the minimum that needs to be done for your system to meet the internal requirements or the company.

            Although, a random checklist on the internet isn’t either of those 2 as it’s totally external to your company.

            For example, no financial institution is going to use Void instead of RHEL because of the support. Neither they will start to upgrade all packages as soon as they’re available without testing it through their change management process.

            1. 2

              following it exactly

              .. will result in a heterogeneous state where you can take all of these systems down that follow this guide to perfection?

              1. 2

                lol, yeah, exactly - at that point, you only need to look at the guide to figure out how to attack anything that used it. Though some checklists are more just best practices. Like, don’t use empty root passwords - that sort of thing. Monotonically increasing security is the idea, but obviously not all checklists are going to do that…

        2. 7

          Oh, almost forgot.

          The most common verified boot implementation is UEFI Secure Boot however this by itself is not a complete implementation as this only verifies the bootloader and kernel, meaning there are ways to bypass this:

          Yay, no anti-Secure Boot FUD. Always a relief.

          UEFI secure boot alone lacks an immutable root of trust so a physical attacker can still reflash the firmware of the device.

          Is wrong, most modern machines has TPMs which works as a immutable root of trust if you are utilizing secure boot. You don’t have to use either of the Intel nor AMD options for this. It would also detect firmware flashing.

          1. 1

            A proper secure boot implementation should be doing measured boot too, no?

            1. 1

              Not “secure boot implementation”, but a “verified boot implementation” would be doing measured boot and secure boot.

              Secure boot itself doesn’t do more then authenticate the files you are booting.

          2. 12

            Use a distribution with an init system other than systemd. systemd contains a lot of unnecessary attack surface; it attempts to do far more things than necessary and goes beyond what an init system should do. An init system should not need many lines of code to function properly.

            I saw this and just closed the tab.

            1. 3

              Right, I get that. But I’d still read over it as you might get an idea or two. But taking it at face value is not really going to give you a lot more then a painfully broken system.

          3. 1

            skips distro recs because that’s always highly subjective, and the starting point shouldn’t matter that much if the focus is on hardening a general linux distro and other comments here already hyperfocus on this

            Okay so this is reminiscent in content to old guides like #! paranoid security guide, installgentoo wiki, etc. The style is much more professional, which is appreciated. Lots of odd software preferences that come from weird places related to the politics of particular projects (lots of anti-systemd style recommendations, which need to be properly justified in this context) embedded in a very in-depth page containing security hardening information relevant for threat models from random off the shelf malware to state-level espionage concerns that assume physical access. I think that can be a bad thing since there is a lack of scope, but on the whole there is a lot of useful knowledge in here, especially for kernel hardening.

            TL;DR : I like guides like these since you can just shop around for security tips that fit your threat model, but I don’t share them around in a broader context because if an inexperienced user took too much of this (especially the occasionally odd software preferences) as fitting their needs they will find themselves with a system that suffers from accessibility issues (install gentoo). They need a corresponding guide to threat modeling.