Difference between revisions of "Kernel Self Protection Project"

From Linux Kernel Security Subsystem
Jump to: navigation, search
(Kernel Self Protection Project)
m (Documentation)
 
(67 intermediate revisions by 3 users not shown)
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 the [https://pax.grsecurity.net/ PaX] and [https://grsecurity.net/features.php grsecurity] [https://github.com/linux-scraping/linux-grsecurity patches], and in 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 classes of bugs and eliminate methods of exploitation.
 +
 
 +
= Principles =
 +
A short list of things to keep in mind when designing self-protection features:
 +
 
 +
* Patience and an open mind will be needed. We're all trying to make Linux better, so let's stay focused on the results.
 +
* Upstream development is evolutionary, not revolutionary, which means it can sometimes take time for features to become fully realized.
 +
* Features will be more than finding bugs, and should be active at run-time to catch previously unknown flaws.
 +
* Features will not be developer-"opt-in". When a feature is enabled at build time, it should work for all code built into the kernel (which has the side-effect of also covering out-of-tree code, like in vendor forks).
 +
 
 +
= Details =
  
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.
+
Specific details on the project:
  
== [[/Bug Class|Bug Classes]] ==
+
==== [[Kernel Self Protection Project/Get Involved|Get Involved]] ====
 +
==== [[Kernel Self Protection Project/Work|Areas of Work Needed]] ====
 +
==== [[Kernel Self Protection Project/Recommended_Settings|Recommended Kernel Settings]] ====
  
* [[/Bug Class/Stack overflow|Stack overflow]]
+
= Documentation =
* [[/Bug Class/Integer overflow|Integer overflow]]
 
* [[/Bug Class/Heap overflow|Heap overflow]]
 
* [[/Bug Class/Format string injection|Format string injection]]
 
* [[/Bug Class/Kernel pointer leak|Kernel pointer leak]]
 
* [[/Bug Class/Uninitialized variables|Uninitialized variables]]
 
  
== [[/Exploit Method|Exploitation Methods]] ==
+
For kernel protections already in upstream (or under active development) that have specific documentation:
  
* [[/Exploit Method/Kernel location|Kernel location]]
+
==== [https://www.kernel.org/doc/html/latest/security/self-protection.html Self-Protection Guidelines] ====
* [[/Exploit Method/Text overwrite|Text overwrite]]
+
==== [[Kernel_Protections/refcount_t|refcount_t]] ====
* [[/Exploit Method/Function pointer overwrite|Function pointer overwrite]]
+
: Kernel reference counter overflow protection
* [[/Exploit Method/Userspace execution|Userspace execution]]
 
* [[/Exploit Method/Userspace data usage|Userspace data usage]]
 
* [[/Exploit Method/Reused code chunks|Reused code chunks]]
 

Latest revision as of 05:20, 4 August 2017

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 the PaX and grsecurity patches, and in 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 classes of bugs and eliminate methods of exploitation.

Principles

A short list of things to keep in mind when designing self-protection features:

  • Patience and an open mind will be needed. We're all trying to make Linux better, so let's stay focused on the results.
  • Upstream development is evolutionary, not revolutionary, which means it can sometimes take time for features to become fully realized.
  • Features will be more than finding bugs, and should be active at run-time to catch previously unknown flaws.
  • Features will not be developer-"opt-in". When a feature is enabled at build time, it should work for all code built into the kernel (which has the side-effect of also covering out-of-tree code, like in vendor forks).

Details

Specific details on the project:

Get Involved

Areas of Work Needed

Recommended Kernel Settings

Documentation

For kernel protections already in upstream (or under active development) that have specific documentation:

Self-Protection Guidelines

refcount_t

Kernel reference counter overflow protection