Reactive vs. pro-active kernel security

Security patches are almost always a question of tradeoffs. Sometimes the protection offered outweighs the negative effects that a security-oriented fix brings—and sometimes it doesn't. In addition, pro-active security fixes often face an uphill battle to get into the kernel, especially if they cause performance or other problems, because many kernel developers are skeptical of "solutions" for theoretical problems. In many cases, these changes come under the heading of "kernel hardening", and don't correspond to a particular known security hole; instead they address a class of potential problems, which can be much harder to sell.

A good example of this can be found in Vasiliy Kulikov's recent RFC patch to implement some checks in the functions that copy data to and from user space. Copying the wrong amount of data to or from user space can lead to security problems, like code execution or disclosing the contents of kernel memory, so checking to ensure that copies are not larger than the expected data structure is certainly beneficial. But the copy_to/from_user() functions are performance-critical. In typical fashion, Linus Torvalds doesn't mince words in his reply to Kulikov:

He does go on to suggest that a cleaned up version which is configurable so that only those distributions or users who want the extra checking will pay the price for it might be acceptable. To Torvalds, the patch is more evidence of the "craziness" of the security community: "It's exactly the kind of 'crazy security people who don't care about anything BUT security' crap that I refuse to see." That, of course, is something of a recurring theme in terms of Torvalds and other kernel hackers' reactions to pro-active security fixes.

Ingo Molnar had a similar concern in the discussion of another of Kulikov's patches: an effort to remove control characters from log file output. Molnar is skeptical of the patch, partly because there are no specific threats that it addresses:

When an actual flaw is found in the kernel, especially if there are exploits for it in the wild, fixes are made quickly—no surprise. But theoretical flaws, or fixes that protect badly written user-space programs often have a tougher path into the kernel. Over the years, we have seen numerous examples of these kinds of patches, often coming from hardened kernel projects like grsecurity/PaX and Openwall. But, to some extent anyway, those projects are more concerned with security than they are with things like performance, and are willing to sacrifice performance to reduce or eliminate entire classes of security threats.

There is clearly a kernel (so to speak) of truth to Torvalds's complaint about "security crap", but there is also room for different kinds of kernels. It is reminiscent of the situation with SELinux in some ways. SELinux offers protections that can sometimes mitigate security problems before they come to light—exactly what pro-active security measures are meant to do—but SELinux is disabled by numerous administrators and by most distributions other than Red Hat's. For some, the extra protection that SELinux provides is not worth the overhead and problems that it can cause. Others may be more concerned about zero-day exploits and enable SELinux or run hardened kernels.

Another example of a fix that didn't make it into the kernel, though it would have eliminated a common security problem, is Kees Cook's attempt to disallow symbolic links in "sticky" directories—to stop /tmp symlink bugs (like this one from July 12). That particular fix was controversial, as some kernel hackers didn't think it appropriate to change core VFS code to fix buggy user-space programs. But moving the fix into a Linux Security Module (LSM)—along with a handful of other unrelated security fixes—didn't pass muster either.

There have also been various efforts to remove sources of information in /proc and elsewhere that can make it easier for exploits to function. Things like hiding kernel addresses from unprivileged processes, restricting page access to read-only and no-execute, protecting /proc/slabinfo, and lots of others have been proposed—sometimes adopted—over the last year or two. These kinds of fixes are often greeted with a level of skepticism (which is not so different from other kinds of patches really), and sometimes find their path into the mainline to be fairly difficult—sometimes impossible. That's not to say that any of those that were rejected should be in the kernel, but in most cases they do add some level of protection that very security-conscious users might be very happy to have.

The risk of keeping many of these pro-active hardening features out of the mainline is probably small, but it certainly isn't non-existent. There is a balance to be found; performance, maintainability, and less intrusiveness of patches are often more important to Torvalds and the kernel community than fixes that could, but might not, catch security exploits that aren't yet known. Essentially, making most users pay a performance penalty over and over again, potentially untold trillions of times, is too high a price. Fixing the problems that are found, when they are found, is the course that the mainline has (largely) chosen.

It is probably somewhat disheartening for Kulikov, Cook, and others to continually have their patches rejected for the mainline, but they do tend to be used elsewhere. Many of Cook's patches have been picked up in Ubuntu, where he is a member of the security team, and Kulikov is a student in the Google Summer of Code for Openwall specifically tasked with hardening both the Openwall kernel and upstream (to the extent he can anyway). Their efforts are certainly not being wasted, and security-conscious administrators may want to choose their distribution or kernel carefully to find the one that best matches their needs.