There are a number of procedures you can follow to make your Linux desktop system more secure, some more advanced than others. We cover some general techniques here.
A firewall may be used to secure connections to your system. If you’re on a public network, the necessity of this may be greater than if you’re on a local trusted network that you control. We would generally recommend that you block incoming connections only, unless you’re using an application firewall such as OpenSnitch or Portmaster.
Red Hat distributions (such as Fedora) are typically configured through firewalld. Red Hat has plenty of documentation regarding this topic. There is also the Uncomplicated Firewall which can be used as an alternative.
All these firewalls use the Netfilter framework and therefore cannot protect against malicious programs running on the system. A malicious program could insert its own rules.
If you are using Flatpak packages, you can revoke their network socket access using Flatseal and prevent those applications from accessing your network. This permission is not bypassable.
If you are using non-classic Snap packages on a system with proper snap confinement support (with both AppArmor and cgroups v1 present), you can use the Snap Store to revoke network permission as well. This is also not bypassable.
There are some additional kernel hardening options such as configuring sysctl keys and kernel command-line parameters which are described in the following pages. We don’t recommend you change these options unless you learn about what they do.
- Recommended sysctl settings
- Recommended boot parameters
- Additional recommendations to reduce the kernel's attack surface
Do not disable unprivileged user namespaces if you use software that relies on it, like: Podman, Docker and LXC containers. The option will prevent this software from working.
Some distributions like Arch Linux have the linux-hardened, kernel package. It includes hardening patches and more security-conscious defaults. Linux-Hardened has
kernel.unprivileged_userns_clone=0 disabled by default. See the warning above about how this might impact you.
Linux Kernel Runtime Guard (LKRG)¶
LKRG is a kernel module that performs runtime integrity check on the kernel to help detect detect exploits against the kernel. LKRG works in a post-detect fashion, meaning that it attempts to respond to unauthorized modifications to the running Linux kernel. The intention is that it will defeat many pre-existing exploits as well as undiscovered vulnerabilities. Some hardened distributions, such as Kicksecure, have documentation.
GRSecurity is a set of kernel patches that attempt to improve security of the Linux kernel. Open source access, however, requires subscription to a paid model.
Simultaneous multithreading (SMT)¶
SMT has been the cause of numerous hardware vulnerabilities, and subsequent patches for those vulnerabilities often come with performance penalties that negate most of the performance gain given by SMT. If you followed the “kernel hardening” section above, some kernel parameters already disable SMT. If the option is available to you, we recommend that you disable it in your firmware as well.
Hardened memory allocator¶
The hardened memory allocator from GrapheneOS can also be used on general Linux distributions. It is available as an AUR package on Arch based distributions, and (though not enabled by default) on Whonix and Kicksecure.
If you are not using openSUSE, consider changing the default umask for both regular user accounts and root to 077. Changing umask to 077 can break snapper on openSUSE and is not recommended.
If you use Toolbox,
/var/log/journal must not have any of those options. If you are on Arch Linux, do not apply
Linux Pluggable Authentication Modules (PAM)¶
On Red Hat distributions you can use
authselect to configure this e.g.:
sudo authselect select <profile_id, default: sssd> with-faillock without-nullok with-pamaccess
USB port protection¶
Secure Boot can be used to secure the boot process by preventing the loading of unsigned UEFI drivers or boot loaders. Some guidance for this is provided in this physical security guide and this verified boot guide.
For further resources on Secure Boot we suggest taking a look at the following for instructional advice:
- The Archwiki’s Secure Boot article. There are two main methods, the first is to use a shim, the second more complete way is to use your own keys.
For background of how Secure Boot works on Linux:
- The Strange State of Authenticated Boot and Disk Encryption on Generic Linux Distributions
- Rod Smith’s Managing EFI Boot Loaders for Linux
- Dealing with Secure Boot
- Controlling Secure Boot
One of the problems with Secure Boot particularly on Linux is that only the chainloader (shim), the boot loader (GRUB), and the kernel are verified and that’s where verification stops. The initramfs is often left unverified, unencrypted, and open up the window for an evil maid attack. There are a few things that can be done to reduce risk such as:
- Creating an EFI Boot Stub that contains the kernel, initramfs and microcode. This EFI stub can then be signed. If you use dracut this can easily be done with the
--uefi-stubswitch or the
- Encrypting the boot partition. However, this has its own issues, the first being that GRUB only supports LUKS1 and not the newer default LUKS2 scheme. As the bootloader runs in protected mode and the encryption module lacks SSE acceleration the boot process will take minutes to complete.
- Using TPM to perform a measured boot.
After setting up Secure Boot it is crucial that you set a “firmware password” (also called a “supervisor password, “BIOS password” or “UEFI password”), otherwise an adversary can simply disable Secure Boot.