Skip to content
Daniel Micay edited this page May 30, 2017 · 36 revisions

Pages:

Note: early stub content moved from the Gentoo wiki, and does not yet reflect the project's goals or consensus. It's just brainstorming and isn't official documentation yet. Even the first sentence below is from before multiple people were involved and a repository existed. The code already contradicts it since it isn't just PaX / grsecurity features and will be doing a lot more of that. The default branch and tags are distinct from any upstreaming effort. That will be in topic branches, like the current fortify branch and the dozen tiny things that landed in upstream trees already. See https://github.com/thestinger/linux-hardened for something official, not this yet.


Hardened Kernel Community Project


Project Facilitators

This community project does not have leaders per se. We are here to facilitate communication between different parties working on security features for the upstream Linux kernel.

Contributor Nickname Role Contact
Matt Brown nmatt Project Lead matt at nmatt.com
r3g3x r3g3x Developer
Kees Cook kees KSPP/Upstream Liaison, Developer keescook at chromium.org
Daniel Micay strcat / thestinger CopperheadOS project lead, Arch Linux linux-hardened package maintainer (previously linux-grsec/linux-grsec-lts/gradm/paxd) [email protected]

Why?

Project Goals

Our goals are:

  • Encourage and facilitate open source development of security features for the Linux kernel.
  • Track progress of development work.
  • Maintain a set of patches for security features that have not yet been merged into mainline.
  • Remain distribution agnostic. We want to focus on patches that affect Linux directly.
  • Work with the KSPP.

Philosophy

All are welcome!

  • We need all the help we can get. Think you're lacking the skills? Feel like there's nothing you could do with your current skillset? Let us prove you wrong!

Resources

Get Involved

Want to contribute to the project? Here is how to get started.

Communication

We do not have our own irc channel or mailing list. However we hangout/communicate in the following ways

  • Main IRC channel: ##linux-hardened (note the double #) on irc.freenode.net

  • Relevant IRC channels:

    • #pax on irc.oftc.net

    • #gentoo-hardened on irc.freenode.net

    • #droidsec on irc.freenode.net

  • kernel hardening mailing list

Code Repos and Patches


Description Link HKP Repo
Basic set of hardening patches for mainline https://github.com/thestinger/linux-hardened Yes
Hardened Kernel Project Patches https://github.com/thestinger/linux-hardened/releases Yes
Unofficial forward ports of the last publicly available grsecurity patch https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec No

Upstream Progress Tracking


Enforce non-executable kernel pages

Sanitize all freed memory

  • grsecurity config: CONFIG_PAX_MEMORY_SANITIZE
  • mainline config: CONFIG_CMDLINE="slub_debug=P" (bad idea! see rest), CONFIG_PAGE_POISONING, CONFIG_PAGE_POISONING_NO_SANITY (unless more security but less performance is wanted), CONFIG_PAGE_POISONING_ZERO
  • upstream: CONFIG_PAGE_POISONING forces debug infrastructure bloat, slab poisoning via slub_debug=P disables the slub fast path which is unnecessarily, ridiculously slow + always enables verification which can be a nice security feature but hurts performance more. It also forces the freelist pointer after the allocation, which is a security improvement in terms of mitigating use-after-free but wastes memory (PaX leaves it inline now unlike in the past and just sanitizes the rest). It also uses a poison value resulting in pointers pointing to userspace - quite dangerous without UDEREF, and still a bad idea with it present.

Prevent invalid userland pointer dereference

  • grsecurity config: CONFIG_PAX_MEMORY_UDEREF
  • mainline config: CONFIG_CPU_SW_DOMAIN_PAN (ARMv7), CONFIG_ARM64_SW_TTBR0_PAN (ARMv8.0), CONFIG_ARM64_PAN (ARMv8.1+)
  • upstream: Hardware (x86_64 Broadwell+ SMAP, ARMv8.1+ PAN), Software (ARMv7, ARMv8.0)

Restrict mprotect()

  • grsecurity config: CONFIG_PAX_MPROTECT
  • mainline config:
  • upstream: SELinux prevents injecting or modifying code at runtime without execmod (associated with a file label), execmem, execheap or execstack but this is not available without an LSM. MPROTECT also covers a bit more ground, like preventing relro sections from becoming writable again after they're made read-only.

Paging based non-executable pages

  • grsecurity config: CONFIG_PAX_PAGEEXEC
  • mainline config:
  • upstream: NX is available for most architectures in hardware, but not non-PAE i386 and PAGEEXEC also kills processes violating NX rather than letting them handle SIGSEGV signals unless an exception is marked

Randomize kernel stack base

Prevent various kernel object reference counter overflows

  • grsecurity config: CONFIG_PAX_REFCOUNT
  • mainline config: n/a
  • upstream: In Progress
  • notes: Current upstream refcount_t work is not protecting atomic_t, so won't be as comprehensive in the near-term.

Harden heap object copies between kernel and userland

  • grsecurity config: CONFIG_PAX_USERCOPY
  • mainline config: CONFIG_HARDENED_USERCOPY
  • upstream: In Progress
  • notes: Missing: slab whitelisting via slab cache useroffsize / usersize ranges, and GFP_USERCOPY kmalloc segregation.

Deter exploit bruteforcing

Dmesg(8) restriction

  • grsecurity config: CONFIG_GRKERNSEC_DMESG
  • mainline config: CONFIG_SECURITY_DMESG_RESTRICT
  • upstream: Complete

Deter ptrace-based process snooping

  • grsecurity config: CONFIG_GRKERNSEC_HARDEN_PTRACE
  • mainline config: CONFIG_SECURITY_YAMA (stackable with other LSMs)
  • upstream: Complete
  • notes: sysctl: kernel.yama.ptrace_scope, set to 1 (scope) by default, and can also disable unprivileged (2) or all usage (3)

Hardened TTY

Hide kernel symbols

  • grsecurity config: CONFIG_GRKERNSEC_HIDESYM
  • mainline config: None
  • upstream: Limited functionality via kptr_restrict sysctl
  • notes: Needs integration with CONFIG_HARDENED_USERCOPY and stronger %p restrictions

Prevent kernel stack overflows

Linking restrictions

  • grsecurity config: CONFIG_GRKERNSEC_LINK
  • mainline config: N/A
  • upstream: Complete
  • notes: sysctl: fs.protected_hardlinks, fs.protected_symlinks

Harden module auto-loading

Proc restrictions

Additional proc restrictions

  • grsecurity config: CONFIG_GRKERNSEC_PROC_ADD
  • mainline config: None
  • upstream: Partial
  • notes: SELinux and other MAC implementations can do this on a fine-grained level, but there's no toggle not tied to MAC

Slub freelist random XOR

  • grsecurity config: no config
  • mainline config: None
  • upstream: Not Implemented
  • notes: grsecurity slub freelist random XOR mangling (no configuration option)

List manipulation checking

  • grsecurity config: no config
  • mainline config: CONFIG_DEBUG_LIST, CONFIG_BUG_ON_DATA_CORRUPTION
  • upstream: Complete

GCC plugin support

  • grsecurity config: CONFIG_GCC_PLUGINS
  • mainline config: CONFIG_GCC_PLUGINS
  • upstream: Complete
  • notes: GCC plugin support is a prerequisite for CONFIG_PAX_LATENT_ENTROPY, CONFIG_PAX_STRUCTLEAK, CONFIG_GRKERNSEC_RANDSTRUCT, CONFIG_PAX_MEMORY_STACKLEAK, CONFIG_PAX_KERNEXEC, and CONFIG_PAX_RAP.

Automatically constify eligible structures

Generate some entropy during boot and runtime

Sanitize kernel stack

Prevent code reuse attacks

  • grsecurity config: CONFIG_PAX_RAP (x86_64 only)
  • mainline config: None
  • upstream: Not Implemented
  • notes: Requires extensive fixes to kernel function prototypes.

Forcibly initialize local variables copied to userland

  • grsecurity config: CONFIG_PAX_STRUCTLEAK
  • mainline config: CONFIG_GCC_PLUGIN_STRUCTLEAK
  • upstream: Complete

Randomize layout of sensitive kernel structures

Clone this wiki locally