Difference between revisions of "Kernel Self Protection Project"

From Linux Kernel Security Subsystem
Jump to: navigation, search
(sysctls)
m (Documentation)
 
(41 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
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 classes of bugs and eliminate 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 =
 
= Principles =
Line 9: Line 9:
  
 
* Patience and an open mind will be needed. We're all trying to make Linux better, so let's stay focused on the results.
 
* Patience and an open mind will be needed. We're all trying to make Linux better, so let's stay focused on the results.
* Features will be more than finding bugs. Should be active at run-time to catch previously unknown flaws.
+
* 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).
 
* 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).
  
= Get Involved =
+
= 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. We need kernel developers, compiler developers, testers, backporters, a documentation writers.
+
Specific details on the project:
  
= Work Areas =
+
==== [[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]] ====
  
While there are already a number of upstream [[Feature List|kernel security features]], we are still missing many. While the following is far from a comprehensive list, it's at least a starting point we can add to:
+
= Documentation =
  
== [[Bug Classes]] ==
+
For kernel protections already in upstream (or under active development) that have specific documentation:
  
* [[Bug Classes/Stack overflow|Stack overflow]]
+
==== [https://www.kernel.org/doc/html/latest/security/self-protection.html Self-Protection Guidelines] ====
* [[Bug Classes/Integer overflow|Integer overflow]]
+
==== [[Kernel_Protections/refcount_t|refcount_t]] ====
* [[Bug Classes/Heap overflow|Heap overflow]]
+
: Kernel reference counter overflow protection
* [[Bug Classes/Format string injection|Format string injection]]
 
* [[Bug Classes/Kernel pointer leak|Kernel pointer leak]]
 
* [[Bug Classes/Uninitialized variables|Uninitialized variables]]
 
* [[Bug Classes/Use after free|Use-after-free]]
 
 
 
== [[Exploit Methods|Exploitation Methods]] ==
 
 
 
* [[Exploit Methods/Kernel location|Kernel location]]
 
* [[Exploit Methods/Text overwrite|Text overwrite]]
 
* [[Exploit Methods/Function pointer overwrite|Function pointer overwrite]]
 
* [[Exploit Methods/Userspace execution|Userspace execution]]
 
* [[Exploit Methods/Userspace data usage|Userspace data usage]]
 
* [[Exploit Methods/Reused code chunks|Reused code chunks]]
 
 
 
= Specific TODO Items =
 
 
 
Besides the general work outlined above, there are number of specific tasks that have either been asked about frequently or are otherwise in need some time and attention:
 
 
 
* Split thread_info off of kernel stack (under development on x86 already)
 
* Move kernel stack to vmap area (under development on x86 already)
 
* Implement kernel relocation and KASLR for ARM
 
* Implement PAN emulation on arm64 for ARMv8.0 hardware (under development)
 
* Write a plugin to clear struct padding
 
* Write a plugin to do format string warnings correctly (gcc's -Wformat-security is bad about const strings)
 
* Reorganize and rename CONFIG_DEBUG_RODATA (and related options) to something without "DEBUG" in the name
 
* arm64: Make CONFIG_DEBUG_RODATA mandatory (queued for v4.9)
 
* Convert remaining BPF JITs to eBPF JIT (with blinding)
 
* Write lib/test_bpf.c tests for eBPF constant blinding
 
* Further restriction of perf_event_open (perf_event_paranoid=3)
 
 
 
= Recommended settings =
 
 
 
People ask from time to time what a good security set of build CONFIGs and runtime sysctl are. This is a brain-dump of the various options for a particularly paranoid system.
 
 
 
== CONFIGs ==
 
 
 
# Report BUG() conditions and kill the offending process.
 
CONFIG_BUG=y
 
 
# Make sure kernel page tables have safe permissions.
 
CONFIG_DEBUG_KERNEL=y
 
CONFIG_DEBUG_RODATA=y
 
 
# Use -fstack-protector-strong (gcc 4.9+) for best stack canary coverage.
 
CONFIG_CC_STACKPROTECTOR=y
 
CONFIG_CC_STACKPROTECTOR_STRONG=y
 
 
# Blocks direct physical memory access.
 
CONFIG_STRICT_DEVMEM=y
 
 
# Provides some protections against SYN flooding.
 
CONFIG_SYN_COOKIES=y
 
 
# Perform additional validation of various commonly targetted structures.
 
CONFIG_DEBUG_CREDENTIALS=y
 
CONFIG_DEBUG_NOTIFIERS=y
 
CONFIG_DEBUG_LIST=y
 
 
# Provide userspace with seccomp BPF API for syscall attack surface reduction.
 
CONFIG_SECCOMP=y
 
CONFIG_SECCOMP_FILTER=y
 
 
# Provide userspace with ptrace ancestry protections.
 
CONFIG_SECURITY=y
 
CONFIG_SECURITY_YAMA=y
 
 
# Perform usercopy bounds checking.
 
CONFIG_HARDENED_USERCOPY=y
 
 
# Randomize allocator freelists.
 
CONFIG_SLAB_FREELIST_RANDOM=y
 
 
# Allow allocator validation checking to be enabled.
 
CONFIG_SLUB_DEBUG=y
 
 
# Dangerous; allows direct physical memory writing.
 
# CONFIG_ACPI_CUSTOM_METHOD is not set
 
 
# Dangerous; disables brk ASLR.
 
# CONFIG_COMPAT_BRK is not set
 
 
# Dangerous; disables VDSO ASLR.
 
# CONFIG_COMPAT_VDSO is not set
 
 
# Dangerous; allows direct kernel memory writing.
 
# CONFIG_DEVKMEM is not set
 
 
# Dangerous; allows replacement of running kernel.
 
# CONFIG_KEXEC is not set
 
 
# Dangerous; allows replacement of running kernel.
 
# CONFIG_HIBERNATION is not set
 
 
# Prior to v4.1, assists heap memory attacks; best to keep interface disabled.
 
# CONFIG_INET_DIAG is not set
 
 
# Easily confused by misconfigured userspace, keep off.
 
# CONFIG_BINFMT_MISC is not set
 
 
# Use the modern PTY interface (devpts) only.
 
# CONFIG_LEGACY_PTYS is not set
 
 
# Reboot devices immediately if kernel experiences an Oops.
 
CONFIG_PANIC_ON_OOPS=y
 
CONFIG_PANIC_TIMEOUT=-1
 
 
# Keep root from altering kernel memory via loadable modules.
 
# CONFIG_MODULES is not set
 
 
# But if CONFIG_MODULE=y is needed, at least they must be signed with a per-build key.
 
CONFIG_DEBUG_SET_MODULE_RONX=y
 
CONFIG_MODULE_SIG=y
 
CONFIG_MODULE_SIG_FORCE=y
 
CONFIG_MODULE_SIG_ALL=y
 
CONFIG_MODULE_SIG_SHA512=y
 
CONFIG_MODULE_SIG_HASH="sha512"
 
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
 
 
 
=== x86_32 ===
 
 
 
# On 32-bit kernels, require PAE for NX bit support.
 
# CONFIG_M486 is not set
 
# CONFIG_HIGHMEM4G is not set
 
CONFIG_HIGHMEM64G=y
 
CONFIG_X86_PAE=y
 
 
# Disallow allocating the first 64k of memory.
 
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
 
 
# Randomize position of kernel.
 
CONFIG_RANDOMIZE_BASE=y
 
 
 
=== x86_64 ===
 
 
 
# Full 64-bit means PAE and NX bit.
 
CONFIG_X86_64=y
 
 
# Disallow allocating the first 64k of memory.
 
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
 
 
# Randomize position of kernel and memory.
 
CONFIG_RANDOMIZE_BASE=y
 
CONFIG_RANDOMIZE_MEMORY=y
 
 
# Modern libc no longer needs a fixed-position mapping in userspace, remove it as a possible target.
 
CONFIG_LEGACY_VSYSCALL_NONE=y
 
 
# Remove additional attack surface, unless you really need them.
 
# CONFIG_IA32_EMULATION is not set
 
# CONFIG_X86_X32 is not set
 
# CONFIG_MODIFY_LDT_SYSCALL is not set
 
 
 
=== arm ===
 
 
 
# Disallow allocating the first 32k of memory (cannot be 64k due to ARM loader).
 
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
 
 
# For maximal userspace memory area (and maximum ASLR).
 
CONFIG_VMSPLIT_3G=y
 
 
# If building an out-of-tree Qualcomm kernel, this is similar to CONFIG_DEBUG_RODATA.
 
CONFIG_STRICT_MEMORY_RWX=y
 
 
# Make sure PXN/PAN emulation is enabled.
 
CONFIG_CPU_SW_DOMAIN_PAN=y
 
 
# Dangerous; old interfaces and needless additional attack surface.
 
# CONFIG_OABI_COMPAT is unset
 
 
 
=== arm64 ===
 
 
 
# Disallow allocating the first 32k of memory (cannot be 64k due to ARM loader).
 
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
 
 
# Randomize position of kernel (requires UEFI RNG or bootloader support for /chosen/kaslr-seed DT property).
 
CONFIG_RANDOMIZE_BASE=y
 
 
 
== kernel command line options ==
 
 
 
# Enable allocator free poisoning (requires CONFIG_SLUB_DEBUG=y).
 
slub_debug=P
 
 
 
=== x86_64 ===
 
 
 
# Remove vsyscall entirely to avoid it being a fixed-position ROP target of any kind.
 
# (Same as CONFIG_LEGACY_VSYSCALL_NONE=y above.)
 
vsyscall=none
 
 
 
== sysctls ==
 
 
 
# Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc).
 
kernel.kptr_restrict = 1
 
 
# Avoid kernel memory address exposures via dmesg.
 
kernel.dmesg_restrict = 1
 
 
# Block non-uid-0 profiling (needs [https://patchwork.kernel.org/patch/9249919/ distro patch], otherwise this is the same as "= 2")
 
kernel.perf_event_paranoid = 3
 
 
# Turn off kexec, even if it's built in.
 
kernel.kexec_load_disabled = 1
 
 
# Avoid non-ancestor ptrace access to running processes and their credentials.
 
kernel.yama.ptrace_scope = 1
 

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