"Which is better, grsecurity or SELinux?"
We often see questions similar to the above that generally imply an "apples to apples" comparison or suggest that the two are incompatible. A quick look at our extensive feature set reveals this is far from the truth. Security is more than just access control, and as has been consistently demonstrated, an easy method of defeating an access control system is through kernel exploitation. Whether you use containers or SELinux, there exists no project to provide the needed kernel self-protection other than grsecurity. Further, grsecurity automatically enforces complex experience-driven protections that can't be matched by any access control policy.
Even if (for whatever reason) you feel SELinux is the pinnacle of mandatory access control, that is still not an argument against using grsecurity or even in fact grsecurity's RBAC system -- unlike the LSMs you're used to, grsecurity and SELinux, or grsecurity and AppArmor, or grsecurity and any other LSM will work together perfectly. In fact, in addition to all the improvements listed below, grsecurity specifically protects several sensitive data structures involved in SELinux and other LSMs that have made them easy targets for kernel exploit writers.
A more recent introduction to upstream Linux's public security perception is the late 2015 creation of the Kernel Self-Protection Project (KSPP). Founded with the worthy goal of improving kernel security, all public evidence of the project shows their efforts have been limited to struggling to understand grsecurity code and upstreaming watered-down versions of a small number of our overall featureset. These reimplemented features generally lack the comprehensive coverage, security guarantees, and performance of the equivalent features in grsecurity. Green checkmarks below for KSPP are associated with features implemented directly as a part of KSPP and match the grsecurity counterpart, while the orange minus symbol is reserved for watered-down features that differ significantly in their implementation and security benefits.
We provide the below feature comparison matrix to illustrate these points. (Last Updated: 07/05/2018)
grsecurity | SELinux | AppArmor | KSPP | |
Mandatory Access Control | ||||
Auditing | ||||
Prevents userland runtime code generation | (dependent on policy) | |||
Prevents auto-loading of vulnerable kernel modules by unprivileged users | (dependent on policy) | |||
Automatically prevents ptrace-based process snooping | (requires heavy-handed global boolean that prevents normal debugging) | |||
Can be used in conjunction with any other LSM | ||||
Reduces the occurrence of kernel information leaks from a variety of sources | ||||
Prevents arbitrary code execution in the kernel | ||||
Prevents direct access to userland memory from the kernel | ||||
Prevents exploitation of kernel reference counter overflows | ||||
Makes a majority of function pointers and many important data structures in the kernel image read-only | ||||
Hardens userland accessors against malicious use | ||||
Prevents many instances of exploitable integer overflows in the kernel | ||||
Adds entropy from a novel source during early boot and runtime | ||||
Reduces the lifetime of sensitive data in memory | ||||
Hardens BPF JIT against spray attacks | ||||
Hardens BPF interpreter against malicious corruption | ||||
Randomizes relative offsets of userland thread stacks | ||||
Hardens userland ASLR against information leaks and entropy reduction | ||||
Deters exploit bruteforcing against both userland and the kernel | ||||
Randomizes the layout of sensitive kernel structures | ||||
Automatically prevents webhosting users from causing Apache to access other users' content through symlinks | ||||
Prevents trivial side-channel attacks against administrator terminals | ||||
Automatically converts uses of chroot to hardened jails | ||||
Automatically enforces that execute-only binaries are unreadable | ||||
Enforces consistent multi-threaded task credentials | ||||
Hardens permissions of overly-permissive IPC objects | ||||
Supports Trusted Path Execution, a simple method of preventing users from executing their created binaries | ||||
Can prevent the processing of malicious USB devices inserted at runtime | ||||
Prevents exploitation of kernel stack overflows on 64-bit kernels | ||||
Prevents code reuse attacks (ROP, JOP, etc) against the kernel | ||||
Supports stable Linux kernel versions |