Bad Packages: Getting More Than You Asked For
THERE’S THIS THING about Linux that any fan likes to parrot: “Linux is more secure than other operating systems.” While this is largely true, it should never be misinterpreted as “Linux never gets any malware.” Malware does exist for Linux, just not on th
If there’s one complaint I hear about Windows 10, it’s that the OS forces updates on the user. Despite all the whining, this is generally a good thing, since users can’t be trusted to update their systems regularly. Even with Windows’ forced updates, there’s a flaw: A Windows update can update drives and core components of the OS, but rarely includes updates to any other software, save that sold by Microsoft or distributed on the Windows Store.
A system like the Windows Store has been around for ages in Linux, in the form of package managers and software repositories. The problem is that repositories can’t offer every piece of software. For some distros, such as Mint and Ubuntu, software review results in software being behind what the upstream creators have available. Rolling release distros, such as Arch and OpenSUSE Tumbleweed, throw caution to the wind, and release updated packages as soon as possible, leaving it to the users to know which packages will break their systems.
The Linux way is great until there’s a piece of software that’s not in the repos. Users have to decide who they are going to trust, but that choice can be overridden by a drive to install the software and move on. Users might be less concerned about the maintainer of the PPA or Arch User Repository (AUR) package if it means getting back to what they want to be doing. With popular and regularly maintained packages, this is rarely a problem—until said package is no longer regularly maintained.
In July, it was reported that a PDF reader package in the AUR called Acroread had been co-opted by a user who inserted malware into the PKGBUIL—a file that gives directions to the system to download and install the package. (The package has since been rolled back.) The offending package maintainer had inserted the malicious instructions after the package had been abandoned by its maintainer. A similar rash of bad images were reported in Docker Hub.
So, being safe might mean using older versions of software, and using newer or unsupported software may mean placing your trust in another party. Some solutions have appeared in the form of containerization. Flatpaks, Snaps, and AppImages offer distribution methods to developers who don’t have the time or desire to port their software to all the major distros. However, some of these can introduce other problems. The Flatpak installation of Zotero can’t install its plugin into the Flatpak version of LibreOffice, for example.
To protect yourself, first make sure the software is from who it says it is, and inspect things such as PKGBUILDs, Dockerfiles, or install instructions on the web. (Copy and paste, so you know what each command does.) When possible, prefer packages and containers created by the upstream source. If in doubt, use an installation method preferred by the developer. I prefer Flatpaks, AppImages, Snaps, official repositories, and the AUR, in that order. When using Docker, prefer images from official or wellknown and documented sources. If in doubt, check the upstream Git repository for documentation, and ensure that more than one person is helping maintain the project.
Linux can be the most secure OS, it just requires a little vigilance. Alex Campbell is a Linux geek who enjoys learning about computer security.