Prevents ptrace-based process snooping
This feature was introduced to deal with ptrace-based userland rootkits and other malicious process hijacking. Importantly, it preserves the a bility of a user to debug his/her own programs through a novel implementation that enforces a process can only attach to its children.
Prevents attackers from auto-loading vulnerable kernel modules
Your webhosting server has no need for a protocol used only in cars, or one for HAM radios, but your distro's kernel configuration likely caus es modules for these to be built -- useful only for exploiting your system. While Linux distros continue to take a reactive approach (via blacklisting) to vulnerable, rarely-legitimately used modules like these, grsecurity us es a proactive approach that prevents unprivileged users from auto-loading kernel modules. The below list of example exploits for vulnerable and rarely used kernel modules is far from exhaustive, but is provided to serve as d emonstration.
Prevents dumping unreadable binaries
On a normal distro kernel, it's not possible to allow a user to execute a program without also giving away the full contents of the program's binary image. While direct reads are denied, a user can ptrace themselves and then execute the binary, using ptrace to extract out the entire mapped contents of the binary image -- even if that binary is setuid root. This inf ormation leak can be useful in creating reliable exploits against custom-compiled binaries. This weakness was abused by Jason Donenfeld, for example, in his exploit for the /proc/pid/mem kernel vulnerability.
Enforces consistent multithreaded privileges
Though glibc wraps calls to setuid() and setgid() with magic signals that cause other threads in a process to change their credentials as well , other libcs and multithreaded applications in other languages do not do this, leading to unexpected vulnerable results of a thread running as root that the developers believe is running unprivileged. Since it's also concept ually wrong for threads sharing the same address space to be running with radically different privilege, grsecurity enforces glibc's behavior at the kernel level despite what language or libc is involved in userland.
Denies access to overly-permissive IPC objects
This feature was developed in response to research done by Portcullis Labs who surveyed use of shared memory in Linux software with surprising results -- many were unnecessarily granting all users on the system the ability to read and or write their created shared memory. Since in many cases this can result in security vulnerabilities, grsecurity locks down access to overly-permissive shared memory and other IPC objects in such a way that does not impact normal operations.