The state of Linux security
Linux provides more security features than you can shake a stick at – more often than not it’s users that are a weak point.
Mainstream Linux distros provide a huge amount of security features out of the box. Some have been around for a long time (address space layout randomisation, having services drop root privileges when they don’t need them, mounting removable drives with the noexec option so they can’t launch binaries) and some are quite new (Spectre and microdata sampling protections).
A few desktop Linux distributions (Ubuntu, Mint, Solus, POP!_OS) offer full disk or home directory encryption out of the box too, which we’d highly recommend you do on your laptop, and if you’re handling sensitive data it’s worth considering on your desktop too. Fedora (and its commercial cousin RHEL) enforces Selinux accounting, which takes permissions and access control lists (ACLS) to a new level, sandboxing apps with fine-grained configurations. Apparmor on Ubuntu does much the same.
Disk encryption is usually done through LUKS and device mapper, and will secure data at rest. However, once the encryption password is entered, that data is (physically) accessible as long as the device remains turned on. With home directory encryption, $HOME is usually unlocked until you log out. Similarly, personal data on modern mobile devices is protected by a pin code, pattern or fingerprint. This is why when the FBI or
NCA or another three-letter organisation suspects you’ve been using your devices for no good, they tend to swoop in and grab those off you while you’re using them so that they’re unlocked. Then a USB dongle is usually fitted, which sends benign keystrokes to ensure the device stays awake and doesn’t lock. Usually a power source is connected too, as that would be embarrassing.
Most new software is installed with a safe, sane configuration, but default usernames and passwords are still common. More often than not users have to tweak initial configurations to suit their requirements, and these tweaks only get as far as making the thing work, not making the thing secure. Where this is most dangerous is running services, because you’re pretty much inviting the world to use your machine. You may want the world to see your website, but you don’t want to allow them to abuse the machine running it. On the desktop, web browsers and email clients are the main conduits for nasties, and we tend to cover those in our privacy-centric features. Over the page we’ll show you how to change your password habits with a hardware key, and how to use Ipfire to protect your home networks. As for servers we’ve got all kinds of tips.
Human beings aren’t really username and password people. Anyone who claims that email is dead would do well to recall that it’s often the only way to reset passwords for all those web services we only sign into once in a blue moon. Naturally, we should all be using password managers and that situation should never arise, but to err is human and all that. Still, there are alternatives and augmentations to passwords that provide convenience and security. Major desktops on Linux don’t yet provide the face/retina unlock features of Windows 10, but that will change. In the meantime we can use a variety of other means to log into our glorious desktops and online services.
If your laptop and mobile phone have NFC (near-field communication) capability, then there’s currently not an awful lot you can do with that on Linux. However, the next edition of Chromium, version 81, will introduce Web NFC, which will enable you to authenticate payments or fill in forms with a gentle tap from your phone.
Meanwhile, there are a number of hardware tokens, such as the Nitrokey, Yubikey and Librem Key, that you can use to secure logins to your Linux box and any number of online services, by the magic of time-based one-time passwords (TOTPS) or the FIDO Universal Second Factor (U2F) protocol.
Be all Yubikey can be
Yubico was good enough to provide us with a Yubikey 5 NFC for this feature. Set up will be different for other hardware tokens, but the result will be the same. We’ll use a hardware key as a second factor to log in to our terminals or desktops. This belt-and-braces approach is the same idea as other two-factor authentication (2FA) schemes for web services and apps – text messages being a common second factor. For Yubikeys the required Ubuntu packages are available from a PPA, and other distros will have similar arrangements (check
https://support.yubico.com, on Arch the required packages are in the main repos). Add the PPA with $ sudo add-apt-repository ppa:yubico/stable and install the Yubikey Manager and PAM module with: $ sudo apt-get install yubikey-manager-qt libpam-u2f PAM (pluggable authentication modules) takes care of authenticating logins on Linux and allows developers to not worry about how their applications will authenticate with the system. Display managers (such as Gnome’s GDM or SDDM on KDE Plasma) as well as the console login all use PAM to authenticate. As the name suggests, modules can be added to authenticate by other means, such as fingerprint readers or, as we’ve just done, U2F devices.
Plug in the Yubikey. Our first task now will be to associate it with our username, and store the token that generates:
$ mkdir ~/.config/yubico
$ pamu2fcfg > ~/.config/yubico/u2f_keys
The configuration program is waiting for input, so push the button on the key. If you have other U2F keys, you may want to register those too. With this set up you won’t be able to log if your key is lost or burned, after all. For each additional key plug it in, run:
$ pamu2fcfg -n >> ~/.config/yubico/u2f_keys and give it a gentle tap to append that key to our configuration. The u2f_keys file can be moved outside of your home directory for additional security, but if you do this you’ll need to add the authfile parameter in the PAM directives we’ll add momentarily. First we’ll do a quick safety test, in case the device is malfunctioning, by testing with the sudo command. The desired result is that the command will require both the correct password and the Yubikey to be connected. Run: $ sudo nano /etc/pam.d/sudo and then enter your password to look at the relevant PAM directives.
We’re going to add a line and then keep the file open (this is what makes it a safety test, so please pay attention to this part) while we test it in another terminal window. This way, if the device or PAM module is misbehaving, we don’t need the sudo command (which is no longer useful to us since misbehaviour is afoot) to revert these changes. If we didn’t discover this until we’d tied our login manager to the Yubikey and logged out, things would be very problematic. Below the @include common-auth line add the following: auth required pam_u2f.so Now save, but do not close(!) the file with Ctrl-o, Enter. Open another terminal and run: $ sudo echo It works You’ll be prompted for a password as usual, but if you get it right, nothing will happen until you give your key a tap. If it didn’t work, remove the offending line from the still-open file and safely exit, make a cup of tea, and consider available options. If it did work, you probably still want to remove that line. Once we make logging in to our machine with the key mandatory there’s less point having it protect Sudo as well (unless you enforce a strict post-login key removal and hiding ceremony). Edit the GDM (or whatever display manager you’re using on non-gnome desktops, the syntax is the same) PAM file with:
$ sudo nano /etc/pam.d/gdm-password
Once again add in the pam_u2f.so module below the @include common-auth line, and save and close the file. Log out of the desktop and cross your fingers. The display manager should start as normal, ask for your password as normal, and then… do nothing. There’s no prompt, but at this point you should tap the device. If you don’t do so within 10 seconds, you’ll get a not necessarily correct error about incorrect passwords.
There is perhaps some security by obscurity offered by this slightly jarring user experience. Even if the device remains plugged into the machine at all times, an evil maid (you really should fire them–ed) or other visitor to your quarters might, despite somehow knowing your password, not know there was another piece to the puzzle. If you are more disciplined, removing the device whenever you log out and placing it somewhere safe, you stand to win some security points.
The passwordless evolution of U2F, FIDO2 started in 2018, with a new authentication mechanism, Webauthn,
THE BENEFITS OF HOTP “For situations where relying on clocks is unsatisfactory, there is HOTP, which increments counters on each login.”
which you should read about at https://webauthn. guide. The Webauthn API provides support for fingerprint or facial-recognition sensors. For now though, your best bet is to use TOTP. Many websites now allow authentication by time-based one-time passwords (TOTP) provided by hardware tokens or mobile apps such as Google Authenticator. Once a shared secret is negotiated (us the current time) between parties, the device generates a 6-8 digit code every 30 seconds. This can be verified on the server, and so long as the clocks remain in sync, the user can log in.
For situations where relying on clocks is unsatisfactory, there is HOTP, which increments counters on each login. The Yubico Authenticator works anywhere Google’s does, and is available as a portable Appimage from https://developers.yubico.com/ yubioath-desktop. There’s a mobile app too, and it’s worth considering the benefits of using a hardware token that isn’t your phone (or embedded in it). Phones have a nasty habit of getting lost, broken or moody.