Recent events have shown that the way security in the Linux kernel is handled is broken, and it needs to be fixed right now.
"Security should be a part of the kernel, not something that gets added in by a select few who probably have the least use for it."
I'm a big proponent of open source software. Although personally I'm a huge follower of BSD-based operating systems, I keep an open and analytical mind when looking at any OS. Unfortunately, I was totally blown away with some of the things that I learned about Linux kernel security during the release of some recent vulnerabilities in the kernel code.
On Friday January 7, 2004, Brad Spengler posted a message to the SecurityFocus Bugtraq mailing list, which detailed several vulnerabilities in both the 2.4 and 2.6 branches of the Linux kernel. Now, first thing's first. I've said it before, but I'll say it again: vulnerabilities happen. I'm not here to berate the quality of the code in question -- that is another discussion entirely that I'll leave for a future article. Instead, I'd like to point out what I consider to be some very concerning issues with the current state of security in the Linux kernel.
What's the problem?
First and foremost, let's take a look at a very vague term that's often referred to in the security industry as "responsible disclosure". Although the definition of responsible disclosure can vary, the vast majority of these definitions include some sort of vendor notification process. What this means is that when a security researcher discovers a vulnerability in a particular piece of software, they will notify the software vendor of the issue so that it can be officially fixed in a subsequent release of the product, or possibly through an interim vendor-supplied patch.
It's suffice to say that vendor notification of security-related issues is a common and important part of software security.
Now, let's pretend that we've found an issue in each of the FreeBSD, NetBSD, OpenBSD, Solaris, and Linux kernels. In order to inform the associated development team, we'll need to forward a bug report to the security contact for each given kernel. For the BSD-based operating systems, the point of contact can be found in a few seconds by searching for the word "security" on the official web site of the associated operating system. Doing so will lead you to the following locations for FreeBSD, NetBSD, OpenBSD, and Solaris. For these four Unix-like OSes, it's simple, straightforward, and there's no guess-work.
As for Linux, however, one could search through several web sites such as linux.org and kernel.org, sites associated with the Linux kernel, and find nothing whatsoever related to a security contact. Even our good friend Google will lead us nowhere fast. We might find a semi-relevant suggestion that bugs in the Linux kernel can be posted to the Linux Kernel Mailing List, but this is hardly an official point of contact for security-related issues -- nor would it seem appropriate to notify the kernel developers of the issue by disclosing it in a public forum such as this.
This is a problem, and it needs to be fixed.
There is some good news here, however. Once we start looking at actual distributions of the Linux kernel as a complete operating system, we find some distributions with official security contacts, as well as security-related pages similar to those provided by the major BSD-based operating systems. Gentoo Linux Security is a good example of that.
While initiatives like Gentoo are good to see, the security contact for any arbitrary distribution of the Linux operating system is not the appropriate place to bring up and fix security-related issues within the base Linux kernel. It does, however, highlight one of the key differences between BSD-based operating systems and Linux -- that being a shared kernel among the Linux distributions.
Security is not a product
It is not cliché to say that security is not a product -- it's a reality. Security is not something that can be added to the Linux kernel by operating system vendors who create Linux distributions. While there are some fantastic projects out there to enhance the security of the Linux kernel, this just isn't the right way to go about it. (If you use Linux and have never explored grsecurity or the PaX Team, you're really missing out.)
Security should be a part of the kernel, not something that gets added in by a select few who probably have the least use for it. Besides the fact that this violates some of the key concepts of secure design, it just doesn't make any sense to me why a product like grsecurity has so many "features" that are obvious candidates for inclusion in the base Linux kernel.
What needs to be done
Two things clearly need to be done.
One, the Linux kernel needs a central point of contact for security-related issues. It appears that, very recently, planning for this has begun.
Two, security is not a product and the Linux kernel developers need to stop treating it as such. This is a discussion unto itself, and one that would require another article to address fully.
It appears that these concerns aren't falling on deaf ears. While looking through some Linux kernel-related mailing lists, it's apparent that these issues are slowly in the process of being addressed. I am, however, still amazed at the fact that these issues have only recently been found to be problematic. Security needs to be proactive, not reactive. These changes seem to be taking place in reaction to some of the comments made by Brad Spengler, as well as the subsequent fallout from the discussion of the associated vulnerabilities.
Some progress is being made, and that's good news. But the Linux kernel needs to start taking security seriously. That not only includes having a central point of contact for security-related issues, but it also requires the developers to take responsibility for the security of the kernel. Security should be a priority when developing the kernel as well as when patching it. Security problems should be fixed by the kernel developers, and not the various Linux distribution vendors.
Ultimately, security will not exist until it has been made a priority.