KS2010: Security

One thing I would note is that no one seems to have made the distinction between reactive security and proactive security (or I have missed it). Allowing "reactive security" to mean "security" is where the "security bugs are just bugs" culture starts from. Proactive security isn't about bugs in the code, it's about design failures. Fixing flawed design is an entirely different kind of thing.

On the reactive security front, upstream does an okay job; small obvious fixes are taken quickly, though sometimes larger fixes take some time to stew, but are ultimately taken. I'll skip talking about how fast reactive security handling by upstream has almost nothing to do with actually protecting end-users from the window of vulnerability, though.

On the proactive front, things are not as good. There has not been much distinction made between protecting userspace and protecting the kernel itself. Nearly all the proactive security work has been to protect userspace from itself, rather than protecting the kernel from userspace.

Small simple changes are done (limiting VFS, and now network, data lengths to below MAX_INT, for example), but larger architectural changes are frequently rejected or forgotten. (For example, why is module NX/RO http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-t... not in Linus's tree after 9 months? What happened to "mode 2 SECCOMP" http://lkml.org/lkml/2009/5/7/479 ?)

It seems that there is a pervasive conservatism when it comes to proactive security improvements (both userspace-defensive and kernel-defensive), and only core maintainers have the ability to change that.