Desde el punto de vista teórico, el parche de kernel grsecurity parece una gran herramienta de endurecimiento. Lo más importante es que PaX parece una buena idea.
¿Estas ventajas teóricas tienen un efecto práctico en la prevención de ataques / explotaciones / rootkits de malware?
Recientemente hubo varios problemas críticos de seguridad (Shellshock, Heartbleed, Turla, ... por nombrar solo algunos)
¿Alguien puede indicar una vulnerabilidad concreta que grsecurity hubiera evitado?
Soy [email protected], y grsec es la razón por la que puedo dormir por la noche.
Como ejemplo de un exploit bloqueado por grsec, puede observar casi cualquiera de las vulnerabilidades recientes del kernel. Las vulnerabilidades de stock simplemente no funcionan contra un kernel grsec.
Como ejemplo de una vulnerabilidad bloqueada por grsec y, en particular, por UDEREF, tiene la raíz local reciente x86_32.
Grsec (menos rbac) no hará nada contra los problemas "lógicos" (shell shock, hearthble, los problemas LD_ *) pero, junto con una cadena de herramientas endurecida, hace que algunas clases de errores sean mucho más difíciles de explotar.
Lo que hace ayuda contra los errores del kernel.
Entonces tienes RBAC. Rbac es un sistema MAC (control de acceso obligatorio), como SELinux o AppArmor, que ofrece una mayor protección, incluso desde la raíz.
Además, grsec le permitirá habilitar algunas restricciones ingeniosas que son realmente útiles si las puede soportar. Los principales son:
El punto es: grsec hará que su sistema sea más seguro, pero los errores se encontrarán incluso en el sistema más seguro.
La mayoría de las vulnerabilidades de escalada de privilegios no funcionarán en un kernel grsec. Grsecurity elimina los vectores de explotación al restringir los procesos mucho más que el sistema operativo.
Esto no significa que nadie pueda llegar al servidor endurecido. Si alguien piratea el servidor, no podrá hacer nada debido a las restricciones impuestas por grsec.
Lea otras preguntas en las etiquetas malware exploit kernel rootkits grsecurity