What do distributions like Qube OS, Subgraph, Tails, and Whonix have in common? Besides an emphasis on security and privacy, all of them are Debian derivatives — and, probably, this common origin is not accidental.
At first, this trend seems curious. After all, other distributions ranging from Slackware and Gentoo to Arch Linux all emphasize security and privacy in their selection of tools. In particular, Fedora’s SE Linux can be so restrictive that some users would rather disable it than learn how to configure it. By contrast, while Debian carries many standard security and privacy tools, it has seldom emphasized them.
Similarly, Debian’s main branch consists of only free and open source software, its contrib and non-free branches not being official parts of the distribution. With many security experts favoring the announcement of vulnerabilities and exploit code rather than relying on security through obscurity, the way that many pieces of proprietary software do, this transparency has obvious appeal.
Yet although the advantage of free software to security and privacy is that the code can be examined for backdoors and malware, this advantage is hardly unique to Debian. To one or degree another, it is shared by all Linux distributions.
Another answer might be that security distributions build on Debian because everyone else does. Of the several hundred active distributions listed on Distrowatch, about two-thirds are based on Debian or Ubuntu. Under these circumstances, the dependency on Debian could be no more than random chance.
However, looking at how Debian both assembles a release and operates on a daily basis, an even simpler answer suggests itself. Debian may not talk a lot about security, but then fish rarely talk about water, either.
In other words, security and privacy are built into Debian policy and procedure. From a strict perspective, Debian can be improved, since, like any distribution, it sometimes compromises for the sake of user convenience, but it remains one of the best foundations for improvement — and, very plausibly, the best.
This statement is undoubtedly controversial. However, to evaluate it properly, you have to understand that most discussion about security and privacy is based on reactive solutions such as virus protectors or SE Linux — that is, tools that detect a possible security or privacy breach, and then act to contain or eliminate it.
But to most security and privacy experts, reactive tools are secondary lines of defense. Much of their time is spent on what is sometimes called architectural security. Instead of designing reactions to intrusions, they try to design software so that intrusions do not occur in the first place.
To give a simple example, instead of running a virus scan, architectural security relies on design elements such as user accounts and permissions to ensure that viruses never get a chance to run in the first place.
In the same way, Debian relies on a detailed procedure to eliminate vulnerabilities. It does not ignore updates, bug-fixes, or backports, but, to a far greater degree than other distributions, Debian does its best to prevent them being necessary in the first place.
None of Debian’s procedure or policy is new, yet, despite Debian’s popularity, few users seem aware of how tightly controlled the distribution’s construction really is. However, you can catch a glimpse of Debian’s procedures in the Debian Policy Manual.
Debian is not the only distribution to have a policy manual about how to build packages and how they are processed through the project. None of the others, however, are nearly as complete. Debian policy details virtually every aspect of building a package, from where libraries, log files, and help should be placed in the file hierarchy, to the types of scripts that can be included in a package and how to add a package to desktop menus. These details are reviewed first by package maintainers, then by the Debian security team. As a result, by the time a package enters the Stable branch for a general release, it is almost guaranteed to be high-quality.
Mistakes do happen, of course, even with such rigorous planning. But when they do, Debian is ready with an equally thorough explanation of what is expected of maintainers when a bug is reported in the Debian Maintainer Reference. The Maintainer Reference covers such topics as how to test a package and report a bug, when confidentiality about problems should be considered, and the procedure when a bug is security-related and needs to be added to the Debian Tracker, the database of reported bugs.
Sometimes, fixing a bug may require working with non-Debian projects, but, overall, this structure allows Debian to respond both quickly and thoroughly to problems.
From an architectural perspective, Debian offers a consistent structure that minimizes bugs (so far as that is possible) and responds quickly when they do occur. Although Debian cannot guard completely against human error or the interactions of one piece of software with another, it provides what is almost certainly the most solid foundation for improving security and privacy that is likely to be available.
Linux Security vs. Newness
Debian’s suitability for security and privacy improvements does come at a price. Notoriously, Debian Stable, the branch for the current release, is often several versions behind other distributions. For example, while Ubuntu 16.10 uses a 4.8 kernel, Debian stable is still using a 3.16 kernel.
For users who want the newest possible software, this lag is often unacceptable. In fact, many users and derivative distributions, including Ubuntu, borrow from the less thoroughly vetted Debian Testing and Unstable in order to offer more recent software that developers are likely to get.
However, for the purposes of security and privacy, newness is not a priority. If anything, newer packages are more apt to have vulnerabilities than older, frequently patched ones. From this perspective, Debian’s stability remains as ideal a starting point for improvements.