Paranoid Penguin - The Future of Linux Security

Did you know that I've been writing this column for the better part of five years? And what an action-packed five years they've been! In that time, we've seen some of Linux's biggest former competitors embrace it, and Linux has made significant inroads as a desktop platform.

In the realm of Linux security, there also have been remarkable advances. Linux's firewall functionality now is so mature that it's the basis for a number of embedded firewall appliances, not to mention countless non-security-related devices as well. Linux supports a staggering variety of security tools, making it a favorite among security auditors and consultants. In addition, Linux has formed the basis for several ultra-secure role-based access control (RBAC)-based operating systems, most notably the NSA's SELinux.

But what about the future of Linux security? I've written a lot about present and past Linux security issues but never about the future, aside from my interview with the forward-looking Richard Thieme. This month, I'd like to indulge in a little speculating and editorializing and talk about where I think Linux security will go and where I think it ought to go.

The revelation a lot of people have been having about Linux security lately is typical Linux systems are not that much more secure than are typical Microsoft Windows systems. Before the e-mail flames begin, let me explain this statement. First, personally, I do happen to think that Linux is more securable than Windows, and I've said so repeatedly in this very column over the years. Users simply have more control over their Linux systems' behaviors than they do with an equivalent Windows system.

The problem is Linux users, like Windows users, tend to focus most of their energy on getting their systems to do what they need them to do, and they place too much trust in their system's built-in or default security settings. Then, when the inevitable software bugs surface, those bugs' effects tend to be more extensive than they would have been had greater precautions been taken.

For example, if I run BIND v9 for name services, it takes some work and some research to get things working. It takes still more work to get BIND running in a chroot jail, so that the named process can see and use only a subset of the server's filesystem. Therefore, many if not most BIND users tend not to run BIND in a chroot jail. When a BIND vulnerability surfaces in the wild, the majority of BIND users probably experience more pain than if they'd done the chroot thing. It's probably the same amount of pain they would experience if they had run a Microsoft name server with fewer security features than BIND has.

All of this is simply to say that many of Linux's security features and capabilities are not taken advantage of by its users. The end result is, at least according to friends of mine who regularly do professional penetration testing, your average Red Hat Enterprise system isn't significantly harder to break in to than your average Windows 2003 Server system.

This is unfortunate and perhaps surprising. Given the complete transparency of its code base, Linux still seems to be prone to the same kinds of software bugs, in roughly the same quantity and frequency, as Windows. But if you think about it, why wouldn't this be so? As with Windows, Linux represents an amazingly complex mass of code produced by hundreds of different people. The more code there is, the more bugs there may be, right?

I recently was interviewed by SearchSecurity.com for an article about a Microsoft-funded study conducted by Security Innovation, Inc. The study concluded that Windows is more secure than Linux, a conclusion based mainly on frequency of security bugs and mean time to issue patches. I believe I correctly criticized the study for looking only at these easily quantifiable aspects of security and not taking into consideration Linux's other security advantages, such as customizability and greater choice of software packages. In other words, I felt the study had the most relevance when comparing default installation scenarios, irrespective of each OS' potential for being secured by its users.

But the more I think about it, the more I worry that perhaps a platform's security potential doesn't count unless most systems running that platform actually reach that potential. This isn't strictly a function of end-user behavior; I'm not trying to impugn system administrators. As I elaborate later, I think Linux's developers and distributors must continue to figure out ways to make security features more ubiquitous, transparent and easy to configure and use. By the way, because I'm comparing Linux with Windows, in fairness I should point out that Windows too has many security features that its users often do not take advantage of.

Okay, Linux and Windows both are much less secure by default than they could be, and both are subject to an unwinnable race between software bugs and security patches. What else are we up against?

Alas, both operating systems use a rather primitive discretionary access control model in which entire categories of security settings and behaviors are optional. In this model, one superuser account—root in Linux, Administrator in Windows—has god-like power over the entire system, including other users' files. In both OSes, group memberships can be used to create different levels of access, say, to delegate various root powers. In practice, however, on most systems you have to be logged on as the superuser or temporarily become that user in order to do anything important.

As a result, gaining complete control over any Linux or Windows system is a matter of compromising any process running with superuser privileges. But wait, you say, I've configured my important dæmons to run as unprivileged users; bugs in those dæmons can't lead to total compromise, can they? No, not directly, but bugs in other software may make it possible for a non-root process to escalate its privileges. For example, suppose you've got a Web server running Apache, and one day an attacker manages to exploit an unpatched Apache buffer overflow vulnerability that results in the attacker getting a shell session on your server. At this point, the attacker is running as www, because that's the user Apache is running as. But suppose further that this system also has an unpatched kernel vulnerability that involves local privilege escalation.

You, the system administrator, may even know about this vulnerability but have opted not to patch it, because after all, it's strictly a local vulnerability, and nobody besides you has a shell account on this system, and who wants to have to reboot after patching the kernel? But now a remote attacker does have local shell access, and if she successfully exploits this kernel vulnerability, she's root! This all-too-common scenario illustrates that bugs are bad enough, but they're even worse when combined with a root-takes-all security model.

This, in a verbose nutshell, is the present state of Linux security. Securing Linux requires us to expend considerable effort to take full advantage of sometimes-complicated security features that usually are not enabled by default, to keep absolutely current on all security patches, and to do all of this within the limitations of Linux's simple security model. But we're in good company: most commonly used contemporary operating systems have exactly the same limitations and challenges.