Security for Linux on the desktop
A story about thinking about the risks that face desktop machines, and how to mitigate them in Linux.
A story about thinking about the risks that face desktop machines, and how to mitigate them in Linux.
Modern operating systems have advanced a tremendous amount in terms of security in recent years. Windows 10, for example, provides an outstanding set of services such as a firewall, malware detection agent and sane permissions escalation system that mean it’s now much more difficult to inadvertently foot-gun ourselves, and both Windows and Mac now ship with persistent automatic updates enabled.
While the story on Linux has improved, Linux invariably has a very different audience than the aforementioned desktop systems. In the case of Linux (particularly Debian), very little is shipped configured for “thoughtless” security, and the owner is expected to fill in this software and configuration stack to mitigate the particular set of risks.
Determining risk
At this point I deliberately want to express the non-authoritative nature of this article:
I have not done any statistical analysis of the threats that face desktop devices. The below advice is basically a thought exercise and mental modelling based on hearsay.
However I still believe it’s useful to ground each of the below recommendations in the context of the risks that it’s supposed to mitigate. Accordingly, let’s evaluate a set of risks, and determine the appropriate actions. The list below is roughly ordered in the order I would be thinking about it.
Please note the list is very specific to people who run Linux on the desktop. For a more general set of guidelines, check out the excellent “Watch your hack” documentation.
Risk: Ourselves
Perhaps the most common cause of data loss that I experience is simple human error. I have destroyed many, many more machines that I have had hacked (or hacked). Accordingly, it’s perhaps best to consider ourselves our greatest threat.
Institute a backup strategy
In my case, I essentially consider my desktop machine a disposable entity, and any work that should be kept must be checked in to a third party system by the end of the day (usually git).
However, in some cases it may be reasonable to pick chunks of the machine (such as the $HOME directory) and periodically back it up, just to prevent the inadvertent lost of work in progress. In this case, it’s perhaps worth looking at tarsnap.
Take due care when operating the vehicle
In nearly all case when I’ve destroyed a desktop machine, it has a been as a result of executing a command as root too quickly. The two safeguards I have in place for this are:
Leave the sudo password enabled. It’s a nice safety net that forces you to re-read the command you just entered before
rm -rf /*.Never do operations directly as root. Though it’s super frustrating that
/var/lib/dockerisrwx------, it’s much worse losing/var/lib.
Don’t open that email
Though I haven’t yet seen an example of a colleague getting hacked through an ostensibly correct mail, I know there have been attempts to inject malware onto our machines through these mails.
If there are attachments on emails that are from untrusted third parties, don’t open them. Especially if they’re from “IT”.
Risk: “Helpful” internet buddies
Perhaps the next most common issue I’ve seen, especially with inexperienced systems administrators (including at one point me) is simply executing commands without understanding first what they’re doing. This comes in a range of flavours, such as:
sudo !!(run last command as sudo because it didn’t work and i don’t know maybe sudo works)Copying and pasting from a tutorial into the terminal
curl | sudo bash -(run this random code from the internet)
Be choosy about your buddies
It’s extremely difficult when first starting out in this industry to achieve any speed without simply adhering to the guidelines stipulated by someone that you trust. However, it’s perhaps the best advice to be picky about who you trust.
Be patient and take time to understand
Additionally, take the time to understand each thing that you’re executing, and why. While it’s annoying and slow at first, it still must be done at some point and you may as well get started now.
Risk: Known, vulnerable software
Linux on the desktop is essentially no different from Linux on the server. Linux powers vast chunks of the internet, and those who wish to capitalise on this pre-built infrastructure by stealing data, compute time or other resources are well invested in finding areas in which they can exploit the software for their own gain. These same risks apply to Linux on the desktop.
Enable automatic updates
This one is remarkably simple to solve; just as in production or across other systems, enable automatic updates and alert when they fail. Most Linux operating systems provide an extremely stable base and providing that certain rules are followed during the administration of these systems, automatic updates do not seem to cause undue risk.
Use software from a package manager and trusted sources
Only software that is actively managed will be kept up to date. Accordingly, it’s generally a good idea to use the systems software (package) management resources to both install and manage software as much as possible.
Where software is not packaged by the Linux distribution themselves, it’s often available in a vendors registry directly.
It’s worth noting, not all registries are equal. Be picky about who’s registry you add.
Risk: A stolen laptop
While this article is titled “Linux on the desktop”, it’s been some years since I’ve owned a full desktop machine. I, like i’m sure many others, use a laptop as my primary computer (I recommend the Dell XPS series — they’re excellent).
Unfortunately, the nature of laptops is sometimes they go missing — be that at a conference while the laptop is in a bag, or at a train station or simply inadvertently broken.
Encrypt the disk
The problem with a laptop that has been stolen is it is in an essentially unknown state; all key material etc must be presumed restored (through some sort of disk image or boot and chroot).
However, we can render the disk unrecoverable (or at least, very difficult to recover) through the use of LUKS full disk encryption. Configured at the Linux install time, this prevents reading the disk until the password is given and the disk is decrypted.
Use hardware tokens for authentication
There are many different kinds of authentication that are possible to access a laptop. However, perhaps my favourite to kill the utility of the machine is to use a hardware token, such as Yubikey, for authentication operations.
It’s possible to set this up in a number of ways:
I have a couple of these keys, and they’re required to access nearly all services I operate with on a daily basis.
Risk: Service access over the network
Linux systems are extremely prolific to manage distributed computation tasks. Services such as MySQL, Redis, NGINX, Apache are all common names and probably familiar to you as a Linux on the desktop user.
All of these services are designed to be used over the network. Unfortunately, Linux on the desktop presents the unique combination of a sense of safety (it’s hard to imagine people remotely hack this computer right here) and ad-hoc, unmaintained services on the machine.
One trivial example is MySQL. Given a users development role at a company, they may install MySQL directly on their desktop to emulate an environment for development, or to run some nebulous production task. Because our developer is on a time budget, they simply use some easy to remember combination for the password: “root” and “root”.
However, MySQL is a combination of both a network service and one that can be abused for code execution. More specifically, if a nefarious co-worker gains network access to our developers machine, they might try “root” and “root”. They will then be able to abuse the MySQL pager command to run arbitrary further commands, establish a reverse shell and generally set about further breaking into our developers machine.
Implement a firewall
The simplest solution to this is to implement a deny-only firewall. There are many Linux firewalls to play with, but I have found that the firewalld firewall (in addition to its GUI) is perhaps the simplest to configure and run across a variety of connections.
This immediately cuts off the ability of all users to connect to a given machine unless our aforementioned lazy developer explicitly allows them access.
Risk: Malware
Though rare, there are certain classes of malware that exist on Linux. Rootkits, cryptominers and other tooling designed to steal resources is a fairly common post exploitation installation.
Signature based detection
Just as other operating system use “virus scanners” to scan content at various key points, Linux can use the open source “ClamAV” or “Yara” to similarly scan large amounts of content on the machine.
In many cases, there are integrations with email clients, browsers or other components for these tools. More generally, I find them useful to double check a weird file.
Honorable Mentions
Two additional classes of tooling that I find very cool, but are probably overkill, are:
OSQuery
OSQuery is designed to both allow ad-hoc queries to your machine from a remote, and track changes to the machine over time. This is useful when attempting to determine what was changed following a hacked machine, or to scan across an organisation for indicators of compromise detected on a hacked machine.
Falco
Made by the company behind “sysdig”, Falco is a tool that uses Linux instrumentation tooling and a knowledge of what software should modify what parts of the machine to set off alerts when that set of rules is failed.
Both of these projects are exceptionally cool, and are being instrumented in the more consequential production environment as an ongoing effort to harden and increase visibility into these systems, but introduce perhaps too much complexity for desktop machines.
In Conclusion
Security for Linux on the desktop is not too dissimilar from security from Linux on the server, which means getting good at one should set you in good stead to solve the other. While it’s not immediately apparent, securing our own hardware can dramatically reduce the risk to our clients, our colleagues and our own personal lives.
Thanks
Tomasz Kaplonski for their early review and addition of helpful links.
Len Lorijn for their addition of the “Watch your Hack” link.