Difference between revisions of "Kernel Self Protection Project"

From Linux Kernel Security Subsystem
Jump to navigation Jump to search
(carve out sections)
Line 1: Line 1:
= Mission Statement =
This project starts with the premise that [https://lwn.net/Articles/410606/ kernel bugs have a very long lifetime], and that the kernel must be designed in ways to protect against these flaws. We must think of [http://lwn.net/Articles/662219/ security beyond fixing bugs]. As a community, we already find and fix individual bugs via static checkers (compiler flags, [http://smatch.sourceforge.net/ smatch], [http://coccinelle.lip6.fr/ coccinelle], [https://scan.coverity.com/projects/linux?tab=overview coverity]) and dynamic checkers (kernel configs, [http://codemonkey.org.uk/projects/trinity/ trinity], [https://www.kernel.org/doc/Documentation/kasan.txt KASan]). Those efforts are important and on-going, but if we want to protect our [http://www.techspot.com/news/57228-google-shows-off-new-version-of-android-announces-1-billion-active-monthly-users.html billion Android phones], our [http://www.zdnet.com/article/2014-the-year-of-the-linux-car/ cars], the [https://training.linuxfoundation.org/why-our-linux-training/training-reviews/linux-foundation-training-prepares-the-international-space-station-for-linux-migration International Space Station], and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to [http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf fail safely, instead of just running safely].
This project starts with the premise that [https://lwn.net/Articles/410606/ kernel bugs have a very long lifetime], and that the kernel must be designed in ways to protect against these flaws. We must think of [http://lwn.net/Articles/662219/ security beyond fixing bugs]. As a community, we already find and fix individual bugs via static checkers (compiler flags, [http://smatch.sourceforge.net/ smatch], [http://coccinelle.lip6.fr/ coccinelle], [https://scan.coverity.com/projects/linux?tab=overview coverity]) and dynamic checkers (kernel configs, [http://codemonkey.org.uk/projects/trinity/ trinity], [https://www.kernel.org/doc/Documentation/kasan.txt KASan]). Those efforts are important and on-going, but if we want to protect our [http://www.techspot.com/news/57228-google-shows-off-new-version-of-android-announces-1-billion-active-monthly-users.html billion Android phones], our [http://www.zdnet.com/article/2014-the-year-of-the-linux-car/ cars], the [https://training.linuxfoundation.org/why-our-linux-training/training-reviews/linux-foundation-training-prepares-the-international-space-station-for-linux-migration International Space Station], and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to [http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf fail safely, instead of just running safely].


These kinds of protections have existed for years in [https://pax.grsecurity.net/ PaX], [https://grsecurity.net/features.php grsecurity], and piles of academic papers. For various social, cultural, and technical reasons, they have not made their way into the upstream kernel, and this project seeks to change that. Our focus is on kernel self-protection, rather than kernel-supported userspace protections. The goal is to eliminate both classes of bugs and methods of exploitation.
These kinds of protections have existed for years in [https://pax.grsecurity.net/ PaX], [https://grsecurity.net/features.php grsecurity], and piles of academic papers. For various social, cultural, and technical reasons, they have not made their way into the upstream kernel, and this project seeks to change that. Our focus is on kernel self-protection, rather than kernel-supported userspace protections. The goal is to eliminate both classes of bugs and methods of exploitation.


Want to get involved? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list] and introduce yourself. Then pick an area of work from below (or add a new one), coordinate on the mailing list, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the [http://www.linuxfoundation.org/ Linux Foundation]'s [https://www.coreinfrastructure.org/faq Core Infrastructure Initiative] is in a great position to fund specific work proposals.
= Get Involved =
 
Want to get involved? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list] and introduce yourself. Then pick an area of work from below (or add a new one), coordinate on the mailing list, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the [http://www.linuxfoundation.org/ Linux Foundation]'s [https://www.coreinfrastructure.org/faq Core Infrastructure Initiative] is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers.
 
= Work Areas =
 
This is far from a comprehensive list, but it's a starting point we can add to:


== [[/Bug Class|Bug Classes]] ==
== [[/Bug Class|Bug Classes]] ==

Revision as of 17:59, 4 November 2015

Mission Statement

This project starts with the premise that kernel bugs have a very long lifetime, and that the kernel must be designed in ways to protect against these flaws. We must think of security beyond fixing bugs. As a community, we already find and fix individual bugs via static checkers (compiler flags, smatch, coccinelle, coverity) and dynamic checkers (kernel configs, trinity, KASan). Those efforts are important and on-going, but if we want to protect our billion Android phones, our cars, the International Space Station, and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to fail safely, instead of just running safely.

These kinds of protections have existed for years in PaX, grsecurity, and piles of academic papers. For various social, cultural, and technical reasons, they have not made their way into the upstream kernel, and this project seeks to change that. Our focus is on kernel self-protection, rather than kernel-supported userspace protections. The goal is to eliminate both classes of bugs and methods of exploitation.

Get Involved

Want to get involved? Join the kernel hardening mailing list and introduce yourself. Then pick an area of work from below (or add a new one), coordinate on the mailing list, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the Linux Foundation's Core Infrastructure Initiative is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers.

Work Areas

This is far from a comprehensive list, but it's a starting point we can add to:

Bug Classes

Exploitation Methods