It's an eternal problem. How can you best protect your computer from all the threats that being connected to a network brings? It's as much a concern for corporate system administrators as it is for everyday computer users. For Linux system administrators, it's one thing to protect a single system with permissions, but it's another matter altogether to protect a network when all your users can be physically located elsewhere.
Since 2015, the Linux Foundation has published a Security Checklist on GitHub, making the guidelines available to Linux admins everywhere. Sysadmins are encouraged to fork the checklist and then customize it for their own users. At the time of this writing in December 2018, 324 forks were recorded in the GitHub repository.
Although the guidelines are focused on laptops that connect to company servers, every Linux user who can sign in as root (that is, be a system administrator) will find useful tips and software recommendations to keep their systems safer, if not entirely bullet-proof.
In this article, I highlight some of the most important recommendations and provide some relevant tips from my own experience.
Let's start with a brief history lesson. Computers nearly always have had an interface that allowed its firmware to hand over control of the system to humans. In the early days of IBM-compatible personal computing, that interface was called the Basic Input Output System (BIOS). This system worked just fine for a long time. There was a security problem with the BIOS, however. The BIOS didn't care whether the operating system that it was told was taking over was actually an operating system. Some folks developed malware, called rootkits, that seized control of the computer on which it was loaded, and the infected computer did the rootkit's bidding instead of the OS it was impersonating.
The solution (many years later) is the Unified Extensible Firmware Interface (UEFI), which began implementation in most Windows-based PCs in 2011. Among other things, UEFI contained the Secure Boot feature, requiring an operating system to present a digital signature that matched one in the UEFI database. Since Microsoft developed this standard and defined the approved signatures, Windows machines were preferred. For nearly two years after the standard was introduced, Linux installations often were rejected by Secure Boot. The Linux Foundation, among others, developed workarounds that allowed both replacement of pre-installed Windows and multibooting systems with a bootloader allowing users to select the OS at boot time.
Today, nearly every PC and laptop running UEFI and Secure Boot also can run Linux with little extra effort. The Linux Foundation checklist calls running with Secure Boot an essential piece of a secure Linux system. Chances are good that your laptop is running under the UEFI, as long as it was built after 2011.
If you're already running Linux on your laptop, look for the efi folder on your system:
ls /sys/firmware/efi/
If you're installing Linux on a new machine, you may want to check your distribution's documentation to confirm that it will boot under Secure Boot. [See Kyle Rankin's article "Tamper-Evident Boot with Heads" for more on securing the boot process.]
If you're not persuaded, or for some reason you can't get Secure Boot working with your distribution, the checklist offers an alternative called Anti Evil Maid (AEM). Created and maintained by the QubesOS project, Anti Evil Maid flips the authentication paradigm by "authenticating machine to the user".
AEM runs on systems using dracut/initramfs, including (besides QubesOS) Fedora, Red Hat Enterprise, openSUSE, SUSE Linux Enterprise, Debian and Gentoo.
To get started with AEM, simply download the code from GitHub and review the setup instructions in the README.
Secure Boot and UEFI are designed to protect the boot sector, so make sure that the UEFI configuration tool is password-protected. Manufacturers may limit the length of such a password, so check that as well.
If you're lucky, you can set up the system to require the UEFI password to boot the system. This ability is considered "nice to have", but not essential, especially if your disk is encrypted, and you shut down/restart the machine regularly.
Say you're ready to install Linux on a machine. There are two things to check before choosing a distribution:
All of your partitions (home, root and swap) will carry a big pile of sensitive data that likely will make some evil-doer very happy should it get loose. If your system can use the bootloader from an encrypted /boot partition, you should do that too.
The reigning standard for Linux disk encryption is the Linux Unified Key System (LUKS). This system, including the dm-crypt package, encrypts the disk with the strong AES-256 encryption algorithm. It also supports multi-user logins into the operating system.
Ideally, your selected distribution will include dm-crypt/LUKS as part of its installation package. If not, ensure that it's available in a repository. The package has different names, but searching for "LUKS" in your package manager should find the right package. If you encrypt your disk after initial system install, be sure to back up your system to a remote location first, as dm-crypt will wipe the existing partitions!
Security Enhanced Linux (SELinux) was originally developed by the US National Security Agency (NSA) in 2000 and merged into the Linux kernel in 2003. SELinux is a Mandatory Access Controls (MAC) system designed to extend core permissions. For those suspicious of the NSA's intent, the code is released under the GNU General Public License. The system was considered to be more of a hindrance by many at the beginning, but the Linux Foundation guidelines declare that it's "mature, robust, and has come a long way since its initial rollout".
Nonetheless, the Linux Foundation says that SELinux "will have limited security benefits on the workstation", because most desktop-type applications an ordinary user runs would be unconfined. The Linux Foundation recommendation is don't turn off SELinux if you run Red Hat or another distribution that uses SELinux for security, but leave its default settings alone.
Many distributions prefer AppArmor to enhance Linux system security. This Role-Based Access Control (RBAC) is easier to configure than SELinux, and it will better protect your network-facing applications.
The checklist recommends creating and using two "distinct, robust, equally strong passphrases" if you are the only user of your machine. One passphrase is for your administrative tasks (unlocking your encrypted disk, bootloader and other root tasks), and a separate passphrase is for your user account and also is to open your password manager for all the other accounts you have.
If someone else uses your machine, you should have a third passphrase for unlocking the disk. That way, you can continue to manage the machine as root, but your ordinary users can unlock their own files.
You still may pause when reading about "passphrases". You know about passwords, and you know (at least in theory) that p@ssw0rd really doesn't keep anything safe. The problem is that the more secure your passwords are, the harder they are to remember. Passphrases—a series of words that you can memorize that no one else can crack—are so much better!
Don't forget Passphrase Rule #1: don't use "The future is already here—it's just not evenly distributed" or some other phrase that you think is cool, geeky but obscure. Chances are the phrase isn't so obscure. If you want to use a quote from classic literature, you might choose "Future is obscure more like a granfalloon" instead.
Once you have installed your Linux distribution, and your data and Swap partitions are encrypted, you should tweak a few more settings to get the system in better shape.
Obsolete kernel modules: FireWire and Thunderbolt standards were created to make it easier for multiple devices to connect to a laptop or desktop system. They, along with ExpressCard, allowed connecting devices to have full direct memory access to your system—really nice when you're the only one trying to access the machine with another device. It's not so good when attackers are everywhere, including unprotected coffee-shop WiFi.
Since more secure technologies have been developed, you don't need these kernel modules. Although newer machines may not have these ports (and you're better off if they don't), you should blacklist those kernel modules. Open /etc/modprobe.d/blacklist-dma.conf and add these lines:
blacklist firewire-core
blacklist thunderbolt
Readable root mail: your system sets up mailboxes for every user on the system, and that email box is likely open at username@systemname. By "every user", I include root. The system automatically sends messages to root's system email. These messages can include security reports and other important notifications. You may be like me and not add that mailbox to your email reader, so the mailbox fills up with important unread email.
Are you suddenly getting the feeling that you may not know what horrible security breaches may have already happened that you don't even know about? You can fix this relatively easily. Forward system mail to an account that is in your email reader. Open /etc/aliases (as root) in your favorite text editor, and add these recommended lines:
#Person who should get root's email
root: mike@example.com
Close incoming sshd ports: Secure SHell (SSH) is a wonderful thing, but you probably don't need to allow other machines (even with a passphrase!) to connect to this laptop. Without a really good reason to allow incoming secure connections, don't do it. Check your firewall settings, as they vary from distribution to distribution, and filter out incoming sshd requests. Then disable the sshd service with these systemd commands:
systemctl disable sshd.service
systemctl stop sshd.service
Updates: I'm obsessive about updating my software, partly because I've always wanted the latest and greatest stuff, but also because updates fix bugs and security holes. Although I have my complaints with KDE's Discover update service, I still am almost gleeful when I'm told I have updates ready to install.
You may be one of those people who had an automatic update go badly, rendering your system useless. Perhaps you update software on a case-by-case basis, reading carefully what exactly an update is intended to fix. You read carefully every security bulletin that comes out on your system, and update accordingly.
The Linux Foundation checklist recommends turning on automatic updates, but if you fall into the camp of wary updaters, you should at least permit automatic notifications of available updates. Combine that with immediate response to any security bulletins you receive from your distribution, and you should be in good shape.
As a security-conscious Linux user, you probably have a backup regimen already in place. In case you don't, the checklist offers a set of guidelines you should be able to follow:
Okay, Linux is installed, and it's as secure as you can make it. You have a backup strategy in place, so you can protect your work if something bad happens. Now you're ready for day-to-day use of your Linux computer. You're still not done with security. As the checklist puts it, "The world of IT security is a rabbit hole with no bottom."
As a "non-exhaustive list", the Linux Foundation offers a set of best practices for day-to-day use:
The Linux Foundation checklist expresses concern that web browsers offer "the largest and most exposed attack surface on your system. It is a tool written specifically to download and execute untrusted, frequently hostile code." As an essential means to mitigate the size of this attack surface, the checklist recommends using two browsers for all online activity:
Install Privacy Badger, HTTPS Everywhere and uMatrix plugins on both browsers. Add Firejail on Firefox for sandbox protection. These plugins make it less likely that your browsing data is being collected across the web. uMatrix is apparently so effective at preventing active third-party content from loading on your screen, it makes it a bit of a hassle to use the web at all, so install it with caution!
I use Privacy Badger and HTTPS Everywhere on Firefox, and I feel like that's enough to protect me on the web. I'll continue to think about this last recommendation (using browsers based on what I'm doing). Interesting to consider though.
In this article, I've gone over the "essential" recommendations on the checklist and some of the "nice" options. The checklist offers a few items for the paranoid among us as well. Be sure to check out the whole list, with more links and discussion points, and see also the Resources section for this article.