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:
That patch is entirely insane. No way in hell will that ever get merged.
copy_to/from_user() is some of the most performance-critical code, and
runs a *lot*, often for fairly small structures (ie 'fstat()' etc).
Adding random ad-hoc tests to it is entirely inappropriate. Doing so
unconditionally is insane.
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:
Yes, but there's a world of a difference between alleged harm and
actual demonstrated harm.
That is a not so fine distinction that is often missed in security
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
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
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
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
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.
to post comments)