The advice in this checklist is horrendously bad and nobody should follow it. Details:<p>> Restrict /usr partition mount options. Example: UUID=<...> /usr ext4 defaults,nodev,ro 0 2<p>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.<p>> Restrict /proc partition mount options. Example: proc /proc proc defaults,hidepid=2 0 0<p>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.<p>> Polyinstantiated directories<p>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.<p>> Protect Single User Mode with root password. Example: # Edit /etc/sysconfig/init. SINGLE=/sbin/sulogin<p>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.<p>> chmod og-rwx /etc/grub.conf chmod -R og-rwx /etc/grub.d<p>Seems like security through obscurity. Nothing sensitive belongs in either of those places.<p>> ExecShield protection. Example: echo "kernel.exec-shield = 2" > /etc/sysctl.d/50-exec-shield.conf<p>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 <a href="https://yeokhengmeng.com/2018/01/make-the-486-great-again/" rel="nofollow">https://yeokhengmeng.com/2018/01/make-the-486-great-again/</a>, 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.<p>> Update password policy (PAM). Secure /etc/login.defs password policy.<p>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.<p>> Set auto logout inactive users. Example:<p><pre><code> > 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
</code></pre>
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.<p>> unlock_time=never<p>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.<p>> Disable uncommon filesystems.<p>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.