Linux Hardening Checklist

I'm not a fan of security checklists that don't provide an explanation or references on why something is or isn't a high priority item.

I doubt a 5 year old hardening is any relevant today. I would stick to a well researched article like Privsec[0] where they explain the reasoning for each step.

[0] https://privsec.dev/posts/linux/desktop-linux-hardening/

I thought about developing a community based open (CC0 licensed) hardening standard and tool which allows giving more details about the system to be hardened to cover even more hardening options. I'm working as an Information Security Auditor and most companies I have audited are using CIS standards for this. While they are free, they are proprietary and you are not allowed to build products on top of these standards. Additionally these standards are relatively generic and I don't know anybody who knows the decision process on their standards. Also, the Windows standards doesn't even recommend using Windows application allowlisting functionalities such as AppLocker or WDAC.

The advice in this checklist is horrendously bad and nobody should follow it. Details:

> Restrict /usr partition mount options. Example: UUID=<...> /usr ext4 defaults,nodev,ro 0 2

Mounting /usr read-only will break system updates, and it's worthless from a security perspective, since nothing in /usr is writable by anyone but root, and root is capable of remounting it read-write. Ditto for the same advice about /boot. Also, nodev is only useful on things unprivileged users can mount, like external media, since on internal partitions like /usr, once again, only root can do mknod, and root can remove the nodev mount option too.

> Restrict /proc partition mount options. Example: proc /proc proc defaults,hidepid=2 0 0

Setting hidepid=2 is a really, really breaking change. I'd never even consider doing that on a production system without extensively testing every piece of it with that on first. And since it's only security-through-obscurity and not real security, it's approximately never worth doing so.

> Polyinstantiated directories

A really common use case of /tmp and /var/tmp is to transfer files between local user accounts, when your home directory is something like a Kerberized NFS mount where you can't give each other direct access. Polyinstantiating those directories breaks that.

> Protect Single User Mode with root password. Example: # Edit /etc/sysconfig/init. SINGLE=/sbin/sulogin

This is actively harmful for security, because now you need to give the root account a password and leave it unlocked, instead of having it locked out and only allowing root access via sudo. And the protection it does offer is trivially bypassable by, e.g., a LiveUSB boot.

> chmod og-rwx /etc/grub.conf chmod -R og-rwx /etc/grub.d

Seems like security through obscurity. Nothing sensitive belongs in either of those places.

> ExecShield protection. Example: echo "kernel.exec-shield = 2" > /etc/sysctl.d/50-exec-shield.conf

ExecShield tries to emulate the NX bit on x86 CPUs that don't have it. All such CPUs are now so old that unless you're doing something like https://yeokhengmeng.com/2018/01/make-the-486-great-again/, any system where it makes sense to use this is so old that the software you'll be running on it will be full of unpatched critical security holes.

> Update password policy (PAM). Secure /etc/login.defs password policy.

This is exactly the kind of password advice that NIST has now has been admitting is harmful for years. You shouldn't require special characters, and you shouldn't require 60-day password changes.

> Set auto logout inactive users. Example:

  > echo "readonly TMOUT=900" >> /etc/profile.d/idle-users.sh
  > echo "readonly HISTFILE" >> /etc/profile.d/idle-users.sh
  > chmod +x /etc/profile.d/idle-users.sh

This fundamentally misunderstands what logout means. If you're logged in to a graphical session and have a bunch of terminal windows open, you don't want each one closing after 15 minutes of idle in itself. And it doesn't even work; if you're idle in a text editor or something, that won't do anything. And it has nothing to do with HISTFILE, so I'm not sure why that's included at all.

> unlock_time=never

This neglects the availability component of the CIA triad. Now it's trivial for an attacker to DoS your system by locking out all of your accounts at once.

> Disable uncommon filesystems.

All EFI hosts need an EFI System Partition that uses vfat, so it's definitely not uncommon. This error is so obvious that it makes me doubt the rest of this list.

Mounting /usr ro would make it hard to apply updates.

Missing "install Crowdstrike"

I see the rationales are on the todo. But this feels useless without it.

It would be nice if it would also mention the reason for each measure.