This is not a post about how secure or insecure Linux is. I have no interest in that debate, especially since I can, and do, harden my systems how I see fit.
Linux distributions do come with certain security mechanisms, but unless specified otherwise, they are not “hardened” systems. General-purpose distributions often have to find a balance between security and usability. Certain hardening options may have an impact on performance or break certain functions that most regular users may need. So these are often left out and it is to the user’s discretion to enable them.
That is the purpose of this post.
There are many ways to harden a system, the most basic ones being enabling a firewall (with good rules) and making sure you have either SELinux or Apparmor up and running, but another simple way is to use sysctls and boot parameters on top of them.
Before I continue, this post assumes that you know what sysctl is, and understand what Grub boot parameters are.
What will follow is based on recommendations from the Kernel Self Protection Project (KSPP), and a few things of my own. It’s also important to remember that these will not make you invulnerable (there’s no such thing) since security is highly contextual. Other necessary steps may be needed to add more protections based on your threat model. The settings here are merely an extra, they reduce attack surface and are useful regardless of threat model.
# Hardening-project repository
Because I use these things across all systems (main desktop, laptop, multiple VMs), I have put all the necessary files in a Git repository located at: https://github.com/I-LeCorbeau/hardening-project.
The kernel.config/kernel.diff files will not be discussed here (leaving it for part 2). What matters are the files in sysctl.d and grub.d. The settings in these files are distribution agnostic, so they should work regardless of what you use. However, they were made on a Debian system, which means you may have to adjust certain settings.
For example, Debian already has init_on_alloc=1 built in the kernel, hence its absence from the grub boot parameters. Other distributions may or may not have it enabled, so it’s a good idea to verify. Keeping an option even if it’s built in the kernel will not do anything bad, mind you, but there’s no reason to leave them on either.
Another example is randomize_kstack_offset=on. Unfortunately, the kernel version in Debian does not support this option, but on kernels 5.13 and above, this should be added to the boot parameters.
Verify what boot parameters are used by your distro of choice using the following command:
cat /proc/cmdline
Verifying the sysctl values (kernel config) used by your distribution is as simple as typing the sysctl option command (with root privileges), e.g.
sysctl kernel.kptr_restrict
This would output the set vallue, e.g.
kernel.kptr_restrict = 1
You can then comment out or remove the ones that are already set to the same value as the ones in the files provided in the repo.
# Usage
Before you use these, make sure you understand what each option does.
- First, make sure your system has procps and sysctl (package name will vary from distro to distro).
- Clone the repository:
git clone https://github.com/I-LeCorbeau/hardening-project.git
From this point on you will need root privileges.
- Copy sysctl configs to /etc/sysctl.d:
cp /path/to/repo/sysctl.d/{01-hardening.conf,02-hardening_net.conf} /etc/sysctl.d/
There are two sysctl configuration files, 01-hardening.conf and 02-hardening_net.conf. The second file contains mostly commented out options, since some network environments require that these stay disabled. It’s up to you to enable them.
- Copy the grub config file. This will not touch the default grub config.
cp /path/to/repo/grub.d/01_hardening.cfg /etc/default/grub.d/
- Update grub
update-grub
- Reboot, and done.
# Performance and usability impact
As I have said in the introduction, most of these settings are disabled by distributions due to their potential impact on performance and usability. So, is there really such a thing?
From my end, I have not noticed any performance impact. It doesn’t mean there aren’t any, it could simply mean that it is not noticeable (unless you look for it). Mind you, this is going to depend heavily on use case. I don’t play games, and this is where the biggest impact may be felt.
Aside from that, boot time, compiling software, watching videos and what not don’t seem to be noticeably impacted, be it on my main system, VMs or my old ass laptop. Your mileage may vary, but as far as I’m concerned, a small performance impact is worth the extra security.
But on that, your opinion may differ.
LeCorbeau's Vault 