Add Linux hardening guide

[MightyCaoCao]

As we all know, Linux isn't the most secure operating system. I think it would be nice to link to or write up a hardening guide, so that people are not just more private, but also more secure at the same time.

For example: archlinux' or madaidan's.

[Mikaela]

There used to be beginnings of something like this in the old wiki.privacytools.io regarding CPU vulnarabilities which were decided to be too advanced subject for being listed on the main page.

[freddy-m]

I'd be in favour of bringing back the Wiki. It had a lot of potential, however it was never harnessed for several reasons.

[TommyTran732]

I can write guides for Fedora and Arch.

[dngray]

I think something like this if it were included might be appropriate content for the wiki.

I'm reluctant to have guides that people blindly follow, or might conflict with default configurations (breaking things) though. Obviously any kind would need to be tested, and note would need to be made to what specific distributions it is tested on.

[elitejake]

Where is the wiki now?

[dngray]

it hasn't yet been migrated.

[freddy-m]

That, or it could be a blog post. Depends which is most aplicable?

[SkewedZeppelin]

Re: https://madaidans-insecurities.github.io

I strongly disagree with many of their points and can't stand how many people constantly point to them and parrot them.
That isn't to say a lot of what they say isn't correct.
People just putting a square box in a round hole even if what they need is a triangle.

Instead I propose my Brace package.
It has a wide coverage of reasonably sane defaults
It supports Arch, Debian, Fedora, and openSUSE.
Packages are built for them via CI.
https://github.com/divestedcg/brace

https://gitlab.com/divested/brace/-/jobs/artifacts/master/browse?job=build_rpm
https://gitlab.com/divested/brace/-/jobs/artifacts/master/browse?job=build_arch
https://gitlab.com/divested/brace/-/jobs/artifacts/master/browse?job=build_deb

[TommyTran732]

Also, things like a GNOME + Wayland + Pipewire setup should be promoted. That would solve the inherent insecurities of X11. Then we can have Flatpak + Flatseal which provides some permission controls (network socket access, pulse audio socket access, etc). We could also recommend apps that work nicely with Portals, which reduces the need to grant a Flatpak package with broad filesystem permissions. Pipewire should also be promoted as the Audio server, as the PipeWire API does provide permission control for microphone permissions. Apps which use the PipeWire API will have to request permission to access our mics, and we don't need to grant them access to the pulse audio socket, which has no permission control whatsoever.

[SkewedZeppelin]

I've personally considered Wayland daily drivable since late 2016 (around 3.22), and it has only improved since.
PipeWire is a drop-in replacement for most cases.
These need to become the standard.

[TommyTran732]

I've personally considered Wayland daily drivable since late 2016 (around 3.22), and it has only improved since. PipeWire is a drop-in replacement for most cases. These need to become the standard.

Yeah, which brings me to the question about Firejail. It doesn't seem to support portals, so how do you plan to handle file permission access and prompts for audio recording and whatnot? I think the Flatpak's way of doing it (with portal support) is better.

[rusty-snake]

dbus-user filter
dbus-user.talk org.freedesktop.portal.*

env GTK_USE_PORTAL=1
env GSETTINGS_BACKEND=keyfile
env XDG_CONFIG_HOME=/home/me/.private-xdg-config-for-foobar

Yes, this should be better integrated, but you can do it already with firejail.

[JnTon]

A lot of things they say are actually correct. While I do not agree 100% with what they say, there are a lot of things one must be aware off:

1. Linux is not fool proof. Linux Desktop lacks many security features and permission controls. You have to be aware of those issues to work around them.
2. Usually you have to pick between the 2 evils: the stock rom with Google Apps and services or use a custom ROM which massively ruins security, to the point that if anyone has access to your phone even just for a minute or two can install persistent malware (because verified boot is none existent and the Android system itself is not encrypted). The only way to retain the security of Android while not having Google on it is to have a device with proper verified boot support and a rom which is signed.
3. Yes, adding uBlock Origin makes you more fingerprintable. Turning on uBlock Origin additional filters make you even more fingerprintable. The only way to do adblocking is to use a browser with a built in adblocker and is fingerprinting resistent out of the box like Bromite or Brave.
4. You can never block all trackers, and attempting to block them using a bunch of extensions make you more fingerprintable. How about using the incognito mode and let the trackers do whatever they want? At the end of the day, they are completely gone after you close your browser and cannot track you the next time you browse the web? The only way to block some of them is to have a default tracker blocker like Brave, which every single Brave user uses so you can blend in instead of sticking out like a sore thumb with your very special configuration.
5. Having a device so insecure that anyone with 1-2 minutes access to it can flash persistent malware on it (any ROM which does not support verified boot) is not "reasonable" imo.
6. Firefox is not fingerprinting resistent by default, and the resist fingerprinting setting doesn't solve it. You can try it on EFF CoverYourTrack. It doesn't hide your system fonts, your audio context, and etc. You have to change additional settings in about:config to hide those, at which point, you will be pretty damn unique because it is very unlikely that anyone on the internet will have the exact same configuration as you.
7. Firejail has a big attack surface, I am not quite sure if using it is a good idea. Even if we were to completely ignore that fact, Firejail also does nothing to prevent an application of being launched outside of the sandbox. I can just call /usr/bin/firefox instead of firefox to launch it outside of Firejail and you would get no indications of that. Firejail is also a PITA to set up - if your favorite application doesn't have a premade profile, you have to launch it and see what files it needs access to, then specify it in a whitelist profile. It is quite tedious to say the least.

@SkewedZeppelin in addittion to the things @TommyTran732 already said I would like to add that:

Don't use Android, unless it is a Pixel with GrapheneOS

1. In Madidans' guide it's not written to "don't use android unless it is a Pixel with GrapheneOS" in opposite it says to "stick to mobile devices" and the use of GrapheneOS on Pixel phone is just recommended as the best option: "Use either the stock operating system or preferably, GrapheneOS on a Pixel >=3. Do not root your device, do not keep your bootloader unlocked and stay away from alternative operating systems like LineageOS as they substantially worsen the security model.".

But "oh yea here is the Linux hardening guide... don't use it"

2. There are two main problems: the first one is explained into disclaimer and the second one at the end of the guide:

DISCLAIMER: Do not attempt to apply anything in this article if you do not know exactly what you are doing. This guide is focused purely on security and privacy, not performance, usability, or anything else.

Despite the hardening you have done, you must remember that Linux is still a fundamentally flawed operating system and no amount of hardening can ever fix it fully.

[JnTon]

I would also add that in Madidans' Linux Hardening Guide there are cited other guides:

• Arch Linux Security wiki page [this one was already cited by you]
• Whonix Documentation
• NSA RHEL 5 Hardening Guide (slightly outdated but contains useful information nevertheless)
• KSPP recommended kernel settings
• kconfig-hardened-check

[dngray]

The main issue is these things can't simply be implemented by those who don't know what the "hardening" actually does. To do so, is to blindly tell people to "run these commands".

The other reason we haven't offered such guides on the main website, is because they must be kept up to date with each release, and there are many different distributions which all behave somewhat differently. An update could break something which a user may not know how to fix.

The problem with Madaidans' Linux Hardening Guide, and other docs that he is written is he very much give absolute instructions without a real good alternative. Just take the first one there:

• Use a distribution with an init system other than systemd. systemd contains a lot of unnecessary attack surface

I've seen him admit to using Arch Linux, so, what does he run a different init daemon on that? What is a user supposed to do with this information?

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

So now you're basically looking at Gentoo or Alpine Linux. That's not really advice we can honestly give users who are transitioning from Windows, to something that respects their privacy a bit more.

In other places he preaches that "Windows is best for security", the fact of the matter is, regarding Windows it is not good for privacy unless you do things to it, to make it so. In enterprise environments those things are done by the windows server admins when they create their group policies.

We're simply not going to write guides telling people to poke sysctl keys. That is poor quality, and it really should not be up to the user to understand those things.

[JnTon]

I've seen him admit to using Arch Linux, so, what does he run a different init daemon on that?

On his Telegram/Matrix bridged group Madaidan openly says that he uses Arch but he has specified many times that he doesn't use it for security, repeating that this OS suffers many security issues (e.g.: https://t.me/spitetech/6706; https://t.me/spitetech/109014; https://t.me/spitetech/342999) as well he has stressed that his personal preference doesn't equate to his security advice (e.g.: https://t.me/spitetech/150861).

In other places he preaches that "Windows is best for security"

He never says that "Windows is best for security":

• he says that Android (and especially GrapheneOS, excluding custom roms like LineageOS) is the best option: "stick to mobile devices" and "Use either the stock operating system or preferably, GrapheneOS on a Pixel >=3. Do not root your device, do not keep your bootloader unlocked and stay away from alternative operating systems like LineageOS as they substantially worsen the security model." [source]

• he says that between Windows and GNU/Linux the first one is a better option from a security point of view, but either ChromeOS, macOS and Android (especially this one as said in the first point) are a better option than most GNU/Linux distribution. [source]

the fact of the matter is, regarding Windows it is not good for privacy unless you do things to it, to make it so.

Deactivating telemetry on Windows is pretty easy and it does not need to be blindly followed by the average user:

1. The first step is to activate Windows, it can be followed the official way or the "unofficial one" (parenthesis points refer to the "unofficial", be aware that depending on the place you live this operation may be not completely legal and that the following activation procedure is made for Windows 10 but with the right changes can be easily adapted to Windows 11):
   (2.) Go to Settings ------> Update & security ------> Activation --------> Change product key
   (3.) Enter the following generic product key and click Next. Follow the prompts all the way through.
   (4.) XGVPP-NMH47-7TTHJ-W3FW7-8HV2C [source]
   (5.) Now reboot the computer
   (6.) Use massgravel's HWID activation method: https://github.com/massgravel/Microsoft-Activation-Scripts§
2. (7.) Follow the official guidelines to deactivate telemetry: https://docs.microsoft.com/en-us/windows/privacy/configure-windows-diagnostic-data-in-your-organization

I also want to point out two things:

• Privacy is impossible to enforce in a system, unless that system is secure.[source] So it is more coherent and reasonable to use OSs like Android, ChromeOS, macOS and Windows where the telemetry can be easily deactivated (and without compromising performance, usability and so on) and security is pretty high in principle, in contrast to use OSs like most GNU/Linux distributions where telemetry may be low or disabled by default but also security is very low and to improve it users have to lose in performance, usability and things like that (and in many case, as you pointed out, it's required advanced IT knowledge and most people don't have it).

• @dngray most of your criticism do not attack Madaidan's arguments but his person, making a strawman and practically ignoring and cherry picking his statements.

[LunaGNUisance]

@JnTon As someone who has linked Madaidan's pages before, I think they're worthwhile for enumerating GNU/Linux's security issues, but my threat model is such that I personally can't acquiesce to some of the things that are said. I think that a number of the issues are overwrought and Madaidan makes the issues out to be bigger than they are. I don't mean to say that GNU/Linux distributions are perfectly secure; I wouldn't rely on any operating system for that. On a desktop system, the most major determinant of security is the user. It doesn't matter how secure, how minimal, or how little attack surface the user's system has, if the user ignores warnings, disables security features, and pulls down their firewalls so they can run a shady executable, or just visits a website that exploits a zero day.

I believe the most important aspect of security is awareness, which is why I think Madaidan's articles are important for raising these questions and issues. Security has to be balanced with other important things, from privacy to convenience, and also usability.

You make the argument that "privacy is impossible to enforce in a system, unless that system is secure." I have two problems with this:

1. There is no secure system. It doesn't exist today. You will still find adversaries like the NSO Group who find zero days and tear down the brightest examples of security that Madaidan enumerates, while many of their attacks would not have worked on a desktop computer. This is why a threat model matters.
2. The most insecure system, if it is never breached, is able to enforce privacy. Your privacy isn't breached until your system is breached, which could happen tomorrow, or never.

I'm not saying that it isn't important to have a system that is best-equipped to protect you, and for developers to continue focusing on securing their software; I am instead saying that I think the area most overlooked when it comes to security is the user. And the critical piece of the puzzle missing with Madaidan's recommendations is, "what is your threat model?" You wouldn't recommend one car to every person because the specs and the performance are the highest, would you?

My last criticism is that even on a secure system, it may not be possible to enforce privacy. You have to trust that your operating system will respect your choices (even if its motivations aren't in your best interests), that it won't revert them after an update, or that new privacy threats will arise, or that you won't make a mistake and miss something. Perhaps this is an acceptable risk for you; perhaps it isn't.

I personally prefer isopenbsdsecu.re to Madaidan's site because it is much more in-depth, enumerates many more issues and doesn't make recommendations about what you should do. If Madaidan is going to do that, more factors and context (i.e. a threat model) needs to be considered.

That's my personal take.

[rusty-snake]

privacy is impossible to enforce in a system, unless that system is secure

Actually I would say that the security of a system is the upper limit of privacy you can enforce.

[dngray]

This was done in https://privacyguides.org/linux-desktop/#privacy-tweaks and below.