Kernel vulnerabilities: Promoting protection

The biggest problem in this domain is one of egos. Influential kernel developers who don't care about stuff that they don't own, and security hackers who want to see their names in lights.

In the case of kernel hackers there is a tendency to use excuses which boil down to shooting down solutions which don't have a perfect "model" for resolving an exploit or class of exploits. (AppArmor) Also, kernel hackers tend to hate large patches which actually address a bunch of conceptually separate issues to the point where the aggregate gets blown off. (GrSec)

Security hackers on the other hand will legitimately discover bugs, but don't like Linus's attitude that their presumably security compromising exploit bugs are no more worthy of special recognition than any other kernel bug. Furthermore, there is a tendency to provide "fixes" which simply shift the point of exploitable failure from a current failure to a future or even concurrent failure point. This is sometimes combined with with creating solutions to a bunch of small kernel vulnerabilities in combination with larger frameworks which make them harder to apply to the root cause problems and to audit. There is sometimes a lack of consideration of balancing of performance, scalability, and complexity considerations against quick and dirty or overly complex framework solutions. Finally, there is often a desire to re-invent the wheel rather than understanding and working with existing robustness models.

The Solution (tm):
1. Preview solutions with key kernel developers who are interested in security.
2. Request reviews from other key kernel developers who can help with feedback.
3. Treat different conceptual problems with different patch sets. Debugging, tracing, simple patches, class of exploit preventions, etc.
4. Performance matters.
5. Compatibility matter even more. Breaking X.org, FTP, SSH, procfs, udev, or Apache is not OK. :-)
6. We already have SELinux and AppArmor - don't reinvent the wheel - invent the tire instead.
7. Document your work... When has this been a problem? Why should people care now? What is the design of the solution? Why couldn't it be simpler? Are there benchmarks? What issues were identified in review and how were they addressed?

I really wish that security (and performance) were addressed in a more rigorous fashion, but the best we can hope for is learning how to work together and maybe getting a corporate sponsor. :-)