Hardening Your Desktop Linux System's Security¶
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.
You could also set your default firewall zone to drop packets. If you're on a Redhat based distribution, such as Fedora this can be done with the following commands:
firewall-cmd --set-default-zone=drop; firewall-cmd --add-protocol=ipv6-icmp --permanent; firewall-cmd --add-service=dhcpv6-client --permanent;
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.
We strongly recommend that you learn what these options do before applying them. There are also some methods of kernel attack surface reduction and access restrictions to sysfs that can further improve security.
Unprivileged user namespaces can be disabled, due to it being responsible for various privileged escalation vulnerabilities. Some software such as Docker, Podman, and LXC require unprivileged user namespaces to function. If you use these tools you should not disable
Disabling access to
/sys without a proper whitelist will lead to various applications breaking. This will unfortunately be an extremely tedious process for most users. Kicksecure, and by extension, Whonix, has an experimental hide hardware info service which does just this. From our testing, these work perfectly fine on minimal Kicksecure installations and both Qubes-Whonix Workstation and Gateway. If you are using Kicksecure or Whonix, we recommend that you follow the Kicksecure Wiki to enable hide hardware info service.
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 note 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 exploits against the kernel. LKRG works in a post-detect fashion, attempting to respond to unauthorized modifications to the running Linux kernel. While it is bypassable by design, it does stop off-the-shelf malware that does not specifically target LKRG itself. This may make exploits harder to develop and execute on vulnerable systems.
If you can get LKRG and maintain module updates, it provides a worthwhile improvement to security. Debian based distributions can get the LKRG DKMS package from KickSecure's secure repository and the KickSecure documentation has instructions.
GRSecurity is a set of kernel patches that attempt to improve security of the Linux kernel. It requires payment to access the code and is worth using if you have a subscription.
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.
These flags could also be applied to
/root as well, however,
noexec will prevent applications from working that require binary execution in those locations. This includes products such as Flatpak and Snap.
If you use Toolbox,
/var/log/journal must not have any of those options. If you are on Arch Linux, do not apply
SUID allows a user to execute an application as the owner of that application, which in many cases, would be the
root user. Vulnerable SUID executables could lead to privilege escalation vulnerabilities.
It is desirable to remove SUID from as many binaries as possible; however, this takes substantial effort and trial and error on the user's part, as some applications require SUID to function.
Kicksecure, and by extension, Whonix has an experimental permission hardening service and application whitelist to automate SUID removal from most binaries and libraries on the system. From our testing, these work perfectly fine on a minimal Kicksecure installation and both Qubes-Whonix Workstation and Gateway.
If you are using Kicksecure or Whonix, we recommend that you follow the Kicksecure Wiki to enable the permission hardener.
Users of other distributions can adapt the permission hardener to their own system based on the source code linked above.
Secure Time Synchronization¶
Most Linux distributions by default (especially Arch based distributions with
systemd-timesyncd) use un-encrypted NTP for time synchronization. Securing NTP can be achieved by configuring NTS with chronyd or by using swdate on Debian based distributions.
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¶
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. The firmware on most devices is also configured to trust Microsoft's keys for Windows and its partners, leading to a large attacks surface.
To eliminate the need to trust Microsoft's keys, follow the "Using your own keys" section on the Arch Wiki. The important thing that needs to be done here is to replace the OEM's key with your own Platform Key.
- If you enroll your own keys as described above, and your distribution supports Secure Boot by default, you can add your distribution's EFI Key into the list of trusted keys (db keys). It can then be enrolled into the firmware. Then, you should move all of your keys off your local storage device.
- If you enroll your own keys as described above, and your distribution does not support Secure Boot out of the box (like Arch Linux), you have to leave the keys on the disk and setup automatic signing of the kernel and bootloader. If you are using Grub, you can install it with the
--no-shim-lockoption and remove the need for the chainloader.
The second option is to 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-stub switch or the
uefi_stub config option. This option also requires you to leave the keys on the disk to setup automatic signing, which weakens the security model.
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.