Home > Comparison Matrix

"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.

We provide the below feature comparison matrix to illustrate these points.

grsecurity
SELinux
AppArmor
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