From theoretical point of view, grsecurity kernel patch looks like a great hardening tool. Most importantly, PaX seems like a good idea.
Do these theoretical advantages have indeed practical effect in preventing malware attack/exploits/rootkits ?
There were several critical security problems recently (Shellshock, Heartbleed, Turla, ... to name just a few)
Can somebody please point to a concrete exploit which grsecurity would have prevented ?
I'm root@anapnea.net, and grsec is the reason I can sleep at night.
As an example of an exploit blocked by grsec, you can look at almost any of the recent kernel vulnerabilities. Stock exploits simply don't work against a grsec kernel.
As an example of a vulnerability blocked by grsec, and in particular UDEREF, you have the recent x86_32 local root.
Grsec (minus rbac) won't do anything against "logic" problems (shellshock, hearthbleed, the LD_* problems) but, together with an hardened toolchain, it makes some classes of bugs much more difficult to exploit.
What it does help against are kernel bugs.
Then you have RBAC. Rbac is a MAC (mandatory access control) system, like SELinux or AppArmor, which offers further protection, even from root.
Plus, grsec will allow you to enable some nifty restrictions which are really useful if you can bear them. The main ones are:
The point is: grsec will make your system safer, but bugs will be found even on the safest system.
Most of the privilege escalation vulnerabilities won't work on a grsec kernel. Grsecurity eliminates exploit vectors by restricting the processes way more than the os.
This doesn't mean nobody can get to the hardened server. If somebody hacks into the server, he won't be able to do anything because of the restrictions grsec imposes.
