En Linux, ¿la cuenta «root» es poderosa por su nombre?

Muchos responden por inercia: «root es la cuenta de administrador». La entrevista busca saber qué usa realmente el kernel para decidir quién es privilegiado.

El kernel comprueba el UID, no el nombre

La página de manual de capabilities describe el modelo UNIX tradicional: los procesos privilegiados son aquellos cuyo ID de usuario efectivo es 0 (el superusuario, o root), y los procesos no privilegiados tienen un UID efectivo distinto de cero. El nombre root es solo una etiqueta en /etc/passwd asociada a ese número. Si añades una segunda entrada con UID 0 —por ejemplo toor o backup—, esa cuenta también es un superusuario completo.

Por qué importa a los defensores

Un atacante que edita /etc/passwd para añadir una cuenta con UID 0 obtiene root sin tocar la contraseña de root ni la configuración de sudo. Buscar cualquier entrada con UID 0 distinta de root es una comprobación básica de persistencia, presente en listas de endurecimiento y de hunting.

Root ya no es todo o nada

Desde Linux 2.2, los privilegios tradicionalmente asociados al superusuario se dividen en unidades distintas llamadas capabilities, que pueden activarse y desactivarse de forma independiente. Por ejemplo, CAP_DAC_OVERRIDE omite las comprobaciones de permisos de lectura, escritura y ejecución de archivos. Un servicio puede recibir solo la capability que necesita en lugar de ejecutarse como root completo.

Por qué fallan los distractores

• «Por el nombre» y «por /root» son explicaciones populares: el kernel nunca las consulta.
• «Por el shell» confunde el programa de login con el modelo de permisos; el shell no influye en el privilegio.

Qué quieren los entrevistadores

«El privilegio depende del UID efectivo 0, no del nombre», y después: auditar UID 0 adicionales y preferir capabilities a root completo.