1. It does list some completely valid options which are good to know. All of them are interesting both from the perspective of learning about more Linux internals and actually locking down access where needed.
2. It mixes security and privacy. Some privacy things may be interesting, but going as far as removing your machine-id? What's the scenario here exactly?
3. It tells you what you can do, but often doesn't say why. What's the threat model? It bounces between things that could be useful for the desktop and for the server. If you're protecting yourself at home, what exactly does blocking ICMP provide you, given it's likely both a flat network and you're registered in both upnp and mdns?
4. Some points I find really questionable: It says to avoid distros with systemd, however systemd was the first one to really bring service sandboxing to the masses. So many issues could be avoided if we used PrivateTmp years ago. Some points are really bad: Avoiding distros that freeze packages (I guess vs rolling distros) is not a trivial change and is not obviously more secure.
5. https://xkcd.com/1200/ - Sure you can put all of those extra options in kernel boot, the extra layers of service separation, spend time hiding identifiers and network options. Unless you're specifically targeted, nobody will ever try that. You'll be owned by some XSS which pulls your login cookie - and the list doesn't even mention Firefox tab containers which can separate that content. Or if someone's targeting developers, your SSH key will get extracted - and the post doesn't even mention hardware SSH keys.
Overall it reminds me of CIS policies. "Here's a CIS certified docker image. It has aida and tcpwrapper on it, because security."
I'm glad that this called out systemd in the very first section, because it told me that the rest of it probably wasn't going to actually talk about anything actually meaningful for security.
Edit: Oh god I hadn't even gotten to the end of that same section where it recommends Gentoo???? This article is written for people who read Cryptonomicon and took it a little too seriously.
Don't see anything wrong with Gentoo in their context.
Author says in disclaimer This guide is focused purely on security and privacy, not performance, usability, or anything else. He's not wrong. Gentoo makes it easier to have compile flags while building your system. Say you want to disable pulseaudio support completely? You can get rid of it completely from anything that might link to it by setting it globally as a flag you want to avoid.
Sure the guide doesn't follow a threat model, but there's still some good advice in there. If someone follows the guide as dogmatic gospel, as a list of rules to follow at all cost, that's on them. If one is responsible for securing down their stack, maybe they should know better than following everything down to the bone as if it's some gospel.
Yeah probably. Its support for easily configuring daemons to run under dynamic users, with private tmp, lesser capabilities, read only root, etc etc makes it quite attractive.
Even more attractive if you’re writing a blog post about hardening Linux against ill specified ill specified threats. Writing a bunch of config files to “lock down” random daemons seems like it’d be right up this guy’s alley
No, I wouldn't. Qubes likely has the most security features out of the box without configuration for the average person trying to lock down their computer. BSD and Arch-flavours certainly have plenty going for them though and I wouldn't speak badly of their intent+outcomes.
systemd has a strong track record of finding and fixing security issues and getting the CVE published. This is important if you want to consider "secure software" and getting things resolved in a timely manner.
People focus on the attack surface, but most of it is local exploits where the threat model is "someone has shell on your box".
Absolutely nothing at all, but it is not a 'more secure choice' than an LTS distribution of a mainline distro and while this guide can't really decide if it's targeting local or server usecases, I can't imagine a worse existence than being responsible for a fleet of servers running Gentoo.
Systemd is evil. What alternatives are there which were designed with security and speed in mind? I would prefer something simple instead of a lot of features.
Inanimate things without preprogrammed social behaviours are neither good nor evil. There are lots of alternative inits and you can use all the same namespacing tricks yourself with unshare and ip. But you'll have to maintain them for each service yourself and that's A LOT of work.
Some of the recommended steps like removing machine-id to prevent fingerprinting are especially funny when the rest of the article perfectly describes how to get your system in a completely uniquely fingerprintable state via obscure knobs most people don't touch.
As you've mentioned, it's a hardening "guide" without specifying a threat model, so its value is very limited anyway.
1. It does list some completely valid options which are good to know. All of them are interesting both from the perspective of learning about more Linux internals and actually locking down access where needed.
2. It mixes security and privacy. Some privacy things may be interesting, but going as far as removing your machine-id? What's the scenario here exactly?
3. It tells you what you can do, but often doesn't say why. What's the threat model? It bounces between things that could be useful for the desktop and for the server. If you're protecting yourself at home, what exactly does blocking ICMP provide you, given it's likely both a flat network and you're registered in both upnp and mdns?
4. Some points I find really questionable: It says to avoid distros with systemd, however systemd was the first one to really bring service sandboxing to the masses. So many issues could be avoided if we used PrivateTmp years ago. Some points are really bad: Avoiding distros that freeze packages (I guess vs rolling distros) is not a trivial change and is not obviously more secure.
5. https://xkcd.com/1200/ - Sure you can put all of those extra options in kernel boot, the extra layers of service separation, spend time hiding identifiers and network options. Unless you're specifically targeted, nobody will ever try that. You'll be owned by some XSS which pulls your login cookie - and the list doesn't even mention Firefox tab containers which can separate that content. Or if someone's targeting developers, your SSH key will get extracted - and the post doesn't even mention hardware SSH keys.
Overall it reminds me of CIS policies. "Here's a CIS certified docker image. It has aida and tcpwrapper on it, because security."