More Thoughts on Linux Security

One of the reasons I took strong exception to Linus Torvalds’ recent comments about security is because there’s no longer a separate kernel line for development, as there were in earlier versions with an odd numbered line (e.g., 2.3 and 2.5) for development and even for stable. For all intents and purposes, the 2.6 mainline is serving dual function for development and stable (though “stable” here is very much open to debate).

While this may be practical for many things, security isn’t one of them.

I added an image in the right side panel on this blog to keep track of security issues arising in the 2.6 kernel. These aren’t the “less important” issues like wonky drivers crashing, these are issues that lead to system compromise via local and/or remote vulnerability.

Don’t get me wrong — I do agree with Linus that all bugs are serious and merit consideration. Where he’s wrong is in his suggestion that OpenBSD’s coding paradigms ignore “less important” issues in the interest of security, as though those are separate issues. In OpenBSD, the primary focus is on doing things clearly and cleanly. If you do it right, you’re a lot less likely to need to revisit it because it opens holes to remote or local exploit or because it crashes (if it even works again).

This was evident recently with the effort by Reyk Floeter when (re)writing drivers to include newer hardware and assuring they don’t break backwards compatibility. The call went out to test his diffs on older hardware before sticking it into a release. That’s not primarily security-oriented, but it does demonstrate the differences between Linux’ and OpenBSD’s focuses. In Linux, such a driver would be thrown into a minor version and repeatedly patched for fuck-ups in subsequent versions; in OpenBSD, there’s a concerted effort to get it right the first time. Maybe Torvalds and the Linux 2.6 developers could learn a thing or two about not breaking stuff when adding new features or new drivers, masturbating monkeys or not.

While BSD development does have its ups and downs, those things are generally done distinctly from -release/-stable trees. The idea is for stability and security — not separately because each is in some measure a function of the other. So you don’t often see new drivers thrown in capriciously the way you see done in Linux. And that’s become even more startling with the move to simultaneous development/release in one kernel line.

For example, it’s increasingly common to get security advisories affecting kernel versions going back 8-10 releases like this one I got in my NVD feed:

CVE-2008-3276 (Kernel)
Integer overflow in the dccp_setsockopt_change function in net/dccp/proto.c in the Datagram Congestion Control Protocol (DCCP) subsystem in the Linux kernel 2.6.17-rc1 through allows remote attackers to cause a denial of service (panic) via a crafted integer value, related to Change L and Change R options without at least one byte in the dccpsf_val field.

So that affects (some) Linux users way back to 2006 to current. Linus deems it as trivial as any other bug. Maybe that’s why it’s a couple years old and present in so many kernel versions.

I think Linus can’t have it both ways. You can’t merge or run -development and -release in the same tree and expect it to be secure. When you add the mix of bits and pieces without much consistency between the myriad distros — except the crazy race to release versions of everything with the highest release number — you have a general climate of insecurity. The pace of Linux development and the tendency to use latest release versions is such that this is probably the tip of the iceberg with Linux insecurity.

I wrote on another blog the other day in a thread about Red Hat and their primary markets that a distro like Ubuntu doesn’t stand a chance in enterprise use because it’s too bleeding edge and too unstable for most businesses to take it seriously. I don’t think Ubuntu is alone in this regard (more about the consequences in a moment). One of the reasons Ubuntu and its offspring have stormed ahead of Debian is because a certain class of user, having a very different set of demands than enterprise users do, have further driven the momentum towards unstable app, insecure kernel, and buggy toolchain releases. This fills a niche that Debian-stable has left unfufilled (and rightly so!) and spawned parallels among other Linux distros (i.e., bleeding edge sub-distros) but it’s also ensuring that most Linux distros are unviable options for enterprise desktop use.

I think it’s a vicious cycle. Kernel development no longer has a -development tree but is all-in-one. The most popular distros increasingly are those with the latest releases — which is sometimes a good thing when an older version has security issues but not good if the latest (and untested) version has even more. There’s less and less sanity between releases as developers race to add features, which correlates (sometimes it seems exponentially) to new vulnerabilities. So my security feeds have mushroomed so that each day I have a mix of updates for various things.

Guess which distros have the most reports and updates. The ones that tend to focus on the bleeding edge. Including the Linux kernel. Yet these are the ones touted as “Windows killers” or somehow being appropriate for desktop adoption in enterprise. They clearly aren’t.

I’ve written several times why I still prefer to use the 2.4 kernel over 2.6. Not only is it smaller and lighter on resources (simplicity is a beautiful thing!), it’s been much more stable and secure. That’s in some degree because it benefited from having separate -dev trees (2.3, 2.5) and backports from 2.6. Yet there’s little active development in 2.4 anymore and most distros have totally abandoned it.

As long as Linus insists on running -development and -stable in the same tree, he should expect — and receive! (which is where the whole discussion about masturbating monkeys originated) — flack about security. As long as advisories are released on as frequent a basis as they are, and often without much disclosure when patches are released to signify their gravity, he should expect and receive complaints.

And as long as Linux (in the broader sense of distributions) is peddled with bleeding edge applications and utilities — and yes, also kernel versions — users shouldn’t wonder why companies are loath to run it on their desktops. You may not care if you’re pwned at home or if your kernel breaks support for some device that worked before you updated your kernel, but others who rely on computers to run their businesses do.

Security and other issues do matter, and they go hand in hand. Rather than suggesting others don’t get that, maybe Linus should practice what he preaches. Then he might applaud and even try to emulate OpenBSD development rather than attack it.

2 Responses to “More Thoughts on Linux Security”

  1. debiantoday Says:

    I really like what you have to say here. Though I love Linux and can honestly only see using BSD as a server of sorts I can definitely see some places where the Linux development community as a whole can take some lessons from the BSD side.

    Also, I added this to stumbleupon. Keep up the good work!

  2. lucky Says:

    Thanks for the encouraging feedback. I now use OpenBSD on my primary desktop and intend to install it on my laptop when I can get enough time to back up my files. I don’t think BSD is suitable only for servers. Apparently neither did Steve Jobs when he was looking for bits and pieces upon which to build a replacement OS for the Mac (even though I think they totally messed it up in the rush to make it so aesthetically… overbearing — IMO anyway).

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: