¿Por qué proteger el kernel de Linux del usuario root?

  

Si un atacante obtiene root, ¿no es cierto que posee la máquina, incluso sin acceso al kernel, haciendo cosas como modificar binarios?

Tal vez, tal vez no. Con SELinux, puede restringir el acceso a los dispositivos de bloqueo, incluso para el usuario root. Entonces, si su partición raíz es de solo lectura (y el sistema se está ejecutando con OverlayFS para proporcionar modificaciones no persistentes), entonces proteger el kernel de la raíz puede garantizar un estado constante en el reinicio, incluso si la máquina se ha comprometido en el nivel raíz.

Mientras que si el kernel no está protegido del usuario root, no puedes tener tales garantías.

Sin un arranque verificado, junto con los módulos verificados y kexec , le dará al kernel una mejor oportunidad de defenderse contra ataques ante una escalada de privilegios. Por defecto, las dos funciones están deshabilitadas:

  

kexec_load_disabled :

     

Un conmutador que indica si kexec_load syscall se ha deshabilitado. Esta   el valor predeterminado es 0 (falso: kexec_load habilitado), pero se puede establecer en 1   (verdadero: kexec_load deshabilitado). Una vez que es verdadero, kexec ya no se puede usar, y   el conmutador no se puede volver a establecer en falso. Esto permite que una imagen kexec sea   cargado antes de deshabilitar el syscall, permitiendo que un sistema configure (y   uso posterior) una imagen sin que sea alterada. Generalmente se usan juntos   con el sysctl "modules_disabled".

     

modules_disabled:

     

Un valor de alternancia que indica si los módulos pueden cargarse   en un núcleo por lo demás modular. Esta opción predeterminada está desactivada   (0), pero se puede establecer verdadero (1). Una vez cierto, los módulos pueden ser   ni cargado ni descargado, y el conmutador no se puede restablecer   a falso Generalmente se usa con la opción "kexec_load_disabled".

Esto no es solo para medidas contra la piratería, sino también una protección de consistencia , creo.

Imagínese si un usuario (incluso la raíz) modificó algo que no debería tener en el kernel. Puede destruir fácilmente el sistema. Por lo tanto, no es solo para la protección contra malware (aunque las vulnerabilidades del kernel son cruciales) , sino también para la consistencia del sistema.

Sin embargo, la raíz puede cargar módulos del kernel.

Estos módulos tienen capacidades de kernel completo, aunque por lo general ellos mismos llaman a funciones arbitrarias. Para obtener más información sobre este aquí ...

Y sí, rootear una máquina es equivalente a poseerla, no es necesario hackear / acceder al kernel. (Dato curioso: pwn proviene de la palabra own )

Uno de estos puntos es virtualización . No siempre es que el hardware ejecuta un solo sistema operativo. Al ejecutar máquinas virtuales, el núcleo de la máquina virtual todavía tiene acceso al hardware en cierta medida o comparte parte de su memoria con el host.

El ejemplo destacado que recuerdo es la vulnerabilidad VENOM . Usó el controlador de disquete para salir de la máquina invitada. Ahora, un núcleo vulnerable podría establecer kernel.modules_disabled=1 y no cargar el controlador de disquete. Además, con el acceso a la memoria del núcleo, alguien podría inyectar el controlador sin pasar por modprobe (eso sería extremadamente difícil pero no imposible).

Para responder a la pregunta, tal vez algunas de estas cosas realmente están ahí para hacer que los rootkits del núcleo sean MÁS difíciles de detectar y eliminar. Si cree que tiene un kernel o incluso un rootkit de espacio de usuario, lo primero que debe hacer es volcar la memoria del sistema para poder buscar cualquier código inusual. Bueno, con el kernel bloqueado ahora no puedes.

Este método de seguridad es similar a lo que Microsoft ha hecho durante años. Eso hace que los ataques sean difíciles y cambiar las cosas para que los ataques específicos no funcionen, pero al mismo tiempo deja el sistema muy vulnerable a alguien que sabe lo que está haciendo. Por ejemplo, MS eliminó el soporte de socket sin formato en XP SP2 para que una variedad de herramientas de explotación no funcionen (por el momento).