privacyguides.org/docs/linux-desktop/hardening.en.md
Jonah Aragon b88beee846
Reduce reliance on external web resources (#1093)
Signed-off-by: Daniel Gray <dng@disroot.org>
2022-04-25 00:26:23 +09:30

11 KiB
Raw Blame History

title icon
System Hardening material/monitor-lock

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.

Firewalls

A firewall may be used to secure connections to your system. If youre on a public network, the necessity of this may be greater than if youre on a local trusted network that you control. We would generally recommend that you block incoming connections only, unless youre 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.

Consider blocking all ports which are not well known or “privileged ports”. That is, ports from 1025 up to 65535. Block both TCP and UDP after the operating system is installed.

If you use Fedora, consider removing the whitelist for for smb-client and mdns services if you do not use them.

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.

Kernel hardening

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 dont recommend you change these options unless you learn about what they do.

Note that setting kernel.unprivileged_userns_clone=0 will stop Flatpak, Snap (that depend on browser-sandbox), Electron based AppImages, Podman, Docker, and LXC containers from working. Do not set this flag if you are using container products.

Linux-Hardened

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.

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 be used on Linux distributions. It is available by default on Whonix and is available as an AUR package on Arch based distributions. If you are using the AUR package, consider setting up LD_PRELOAD as described in the Arch Wiki.

Umask

If you are not using openSUSE, consider changing the default umask for both regular users and root to 077. Changing umask to 077 can break snapper on openSUSE and is not recommended.

Mountpoint hardening

Consider adding the following options nodev, noexec, and nosuid to mountpoints which do not need them. Typically, these could be applied to /boot, /boot/efi, /home, /root, and /var.

If you use Toolbox, /var/log/journal must not have any of those options. If you are on Arch Linux, do not apply noexec to /var/tmp.

Linux Pluggable Authentication Modules (PAM)

There is also further hardening to PAM to secure authentication to your system. This guide has some tips on this.

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

On systems where pam_faillock is not available, consider using pam_tally2 instead.

USB port protection

To better protect your USB ports from attacks such as BadUSB we recommend USBGuard. USBGuard has documentation as does the Arch Wiki.

Another alternative option if youre using the linux-hardened is the deny_new_usb sysctl. See Preventing USB Attacks with linux-hardened.

Secure Boot

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:

For background of how Secure Boot works on Linux:

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 thats 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:

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.

These recommendations can make you a little more resistant to evil maid attacks, but they not good as a proper verified boot process such as that found on Android, ChromeOS or Windows.

--8<-- "includes/abbreviations.en.md"