Evolución de sudo: de su en Unix a privilegios modernos

Aquí tienes un dato que sorprende a la mayoría: cuando escribes tu contraseña en sudo, no aparece ningún tipo de respuesta. Ni asteriscos, ni puntos, nada. El cursor simplemente se queda ahí. Esta decisión de diseño se tomó en los años 80 y lleva más de cuatro décadas confundiendo a los usuarios. Mucha gente cree que la terminal se ha congelado, escribe la contraseña varias veces o asume que algo no funciona. Ubuntu por fin decidió mostrar asteriscos por defecto, poniendo fin a una tradición de 46 años de entrada silenciosa de contraseñas.

Ese pequeño cambio revela algo más grande: la forma en que Linux gestiona la escalada de privilegios es un mosaico de decisiones tomadas a lo largo de décadas, algunas brillantes, otras bastante cuestionables, todas cargando con el peso de la compatibilidad hacia atrás. Entender cómo llegamos hasta aquí te ayuda a tomar mejores decisiones de seguridad hoy.

Antes de sudo: el mundo de su

La herramienta original de escalada de privilegios en Unix era su, de «substitute user». Hacía exactamente una cosa: cambiar toda tu sesión de shell a otro usuario, normalmente root. Escribías su, introducías la contraseña de root, hacías tu trabajo de administración y luego salías de vuelta a tu cuenta normal.

$ su
Password: [type root's password]
# whoami
root
# apt install nginx
# exit
$ whoami
normaluser

Los problemas de su se hicieron evidentes cuando los sistemas Unix crecieron más allá de un puñado de operadores de confianza. Todo el que necesitaba acceso de administrador tenía que conocer la contraseña de root. Cuando alguien dejaba el equipo, había que cambiar la contraseña de root y comunicar la nueva a todos los demás. No existía registro de auditoría: una vez que alguien se convertía en root, todas sus acciones quedaban registradas como «root», sin rastro de quién había ejecutado qué. Y su te daba una shell de root completa, lo que significaba que un solo error de tecleo podía destruir el sistema.

La historia de terror clásica: un administrador quería escribir rm -rf /tmp/old_files pero le dio a enter después de rm -rf / por accidente. Con una shell de root completa, nada impide que ese comando se ejecute. su no hacía ninguna distinción entre «esta persona necesita reiniciar nginx» y «esta persona necesita acceso sin restricciones a todo el sistema».

Cómo sudo resolvió el problema de la contraseña de root

sudo («superuser do») se creó en 1980 en SUNY Buffalo por Bob Coggeshall y Cliff Spencer. La idea central era sencilla pero transformadora: en lugar de compartir la contraseña de root, permitir que cada usuario ejecute comandos concretos como root usando su propia contraseña. El administrador del sistema controla quién puede ejecutar qué mediante un archivo de configuración.

Esto resolvió varios problemas a la vez:

• Sin contraseña de root compartida. Cada usuario se autentica con sus propias credenciales. Cuando alguien se va, le quitas el acceso a sudo. No hace falta rotar contraseñas.
• Permisos granulares. Puedes permitir a un desarrollador reiniciar un servicio concreto sin darle acceso total de root.
• Registro de auditoría. Cada comando de sudo queda registrado con el nombre de usuario que lo ejecutó, qué ejecutó y cuándo.
• Escalada temporal. En lugar de una shell de root sin límite, sudo ejecuta un único comando con privilegios elevados y luego vuelve a la normalidad.

# Run a single command as root
$ sudo apt install nginx
[sudo] password for priya:
# That's YOUR password, not root's
# The audit trail in /var/log/auth.log:
# Mar 20 14:23:01 web-03 sudo: priya : TTY=pts/0 ;
#   PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/apt install nginx

El archivo sudoers: potente y peligroso

La configuración de sudo vive en /etc/sudoers, y su sintaxis es realmente una de las cosas más confusas de la administración de Linux. Un solo error de sintaxis puede dejarte sin acceso a sudo, por eso existe el comando visudo: valida el archivo antes de guardarlo.

# /etc/sudoers syntax:
# WHO  WHERE = (AS_WHOM) WHAT
# Let priya run anything as root on any host
priya ALL=(ALL:ALL) ALL
# Let the 'webdev' group restart nginx only
%webdev ALL=(root) /usr/bin/systemctl restart nginx,\
/usr/bin/systemctl reload nginx
# Let deploy user run deploys without a password
deploy ALL=(root) NOPASSWD: /opt/deploy/run.sh
# DANGEROUS: This looks restrictive but isn't
bob ALL=(root) /usr/bin/vim
# Bob can now run: sudo vim, then :!bash to get a root shell

Ese último ejemplo, dar a alguien acceso a sudo para vim, es un error de seguridad en el que la gente cae constantemente. Vim (y muchos otros programas) puede lanzar comandos de shell. Si un usuario puede hacer sudo vim, en la práctica tiene acceso de root sin restricciones. Lo mismo aplica a less, man, awk, find, python y decenas de comandos más. El proyecto GTFOBins mantiene una lista completa de binarios que pueden usarse para escapar de shells restringidas.

Comportamientos extraños y trampas de seguridad de sudo

sudo ha acumulado comportamientos realmente raros a lo largo de más de 40 años de historia. Entenderlos es importante para la seguridad:

• Caché de credenciales. Tras introducir tu contraseña, sudo la guarda en caché durante 15 minutos por defecto. Durante ese intervalo, cualquier comando de sudo se ejecuta sin autenticación. Si dejas una terminal desbloqueada, cualquiera puede ejecutar comandos de sudo durante hasta 15 minutos. Ejecuta sudo -k para borrar la caché al instante.
• El ajuste tty_tickets. Por defecto, la caché de credenciales de sudo es por terminal. Pero en algunos sistemas, autenticarse en una sesión de terminal desbloquea sudo en todas. Revisa tus ajustes Defaults.
• Variables de entorno. sudo sanea la mayoría de las variables de entorno, pero no todas. LD_PRELOAD y LD_LIBRARY_PATH se eliminan, pero si env_keep está mal configurado, un atacante puede inyectar rutas de librerías maliciosas. Esto ha sido la base de varios exploits reales de escalada de privilegios.
• La trampa de NOPASSWD. NOPASSWD es cómodo para la automatización, pero peligroso si se aplica demasiado ampliamente. Una aplicación comprometida que se ejecute como un usuario con acceso sudo NOPASSWD tiene, en la práctica, root: no hay contraseña que crackear.

# Security hardening for sudoers:
# Require password every time (disable caching)
Defaults timestamp_timeout=0
# Or reduce cache to 1 minute
Defaults timestamp_timeout=1
# Ensure credential cache is per-terminal
Defaults tty_tickets
# Log all sudo I/O (records full terminal sessions)
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io
# Require root password instead of user password
# (prevents compromised user accounts from sudo-ing)
Defaults rootpw
# Show asterisks when typing password
Defaults pwfeedback

Alternativas modernas: doas, polkit y run0

La complejidad de sudo ha dado lugar a varias alternativas, cada una con una filosofía distinta.

doas: sudo sin la complejidad

El doas de OpenBSD («dedicated OpenBSD application subexecutor») lo creó Ted Unangst en 2015, precisamente porque sudo se había vuelto demasiado complejo para auditarlo. La configuración completa suele ocupar 2 o 3 líneas:

# /etc/doas.conf — the entire configuration
permit persist priya
permit nopass deploy as root cmd /opt/deploy/run.sh
# That's it. Compare this to a typical sudoers file.
# 'persist' is like sudo's credential caching
# 'nopass' is like NOPASSWD

El código fuente de doas tiene unas 2.500 líneas de C. El de sudo supera las 150.000. En sistemas que no necesitan las funciones avanzadas de sudo (como el emparejamiento de argumentos por comando o la integración con LDAP), doas es muchísimo más simple de configurar, auditar y asegurar. Llevo años usándolo en mis servidores personales y no he echado de menos sudo ni una vez.

polkit: privilegios de escritorio de grano fino

PolicyKit (polkit) sigue un enfoque completamente distinto. En lugar de envolver comandos individuales, define acciones que las aplicaciones pueden solicitar. Cuando una app de escritorio necesita modificar la configuración de red, pide permiso a polkit, y polkit decide según sus reglas si concederlo, denegarlo o pedir confirmación al usuario.

Así es como tu escritorio Linux te deja montar una memoria USB sin contraseña, pero exige autenticación para instalar software. La granularidad está a nivel de acción, no de comando, lo que encaja mejor con la forma en que los usuarios de escritorio piensan sobre los permisos.

run0: el replanteamiento radical de systemd

run0 de systemd es la incorporación más reciente, y funciona de forma fundamentalmente distinta a sudo. En lugar de ejecutar un comando como root desde tu sesión existente (lo que requiere bits setuid y genera dolores de cabeza de seguridad), run0 pide al gestor de servicios que lance un nuevo servicio que se ejecuta como root. Tu sesión de usuario nunca gana privilegios elevados: el proceso privilegiado es completamente independiente.

Esto evita categorías enteras de vulnerabilidades de sudo. No hay binario setuid, ni caché de credenciales, ni superficie de inyección de variables de entorno. La contrapartida es que requiere systemd, lo que lo descarta para sistemas BSD y configuraciones Linux mínimas. Pero en servidores con systemd, es posiblemente la opción más segura disponible.

Recomendaciones prácticas

Tras años gestionando servidores Linux e investigando incidentes de escalada de privilegios, esto es lo que realmente recomiendo:

1. Desactiva por completo el login de root. Usa sudo o doas para todo. No debería existir ninguna contraseña de root compartida.
2. Usa grupos, no usuarios individuales, en sudoers. Gestiona el acceso mediante la pertenencia a grupos. Cuando alguien se vaya, sácalo del grupo.
3. Nunca des acceso sudo a intérpretes ni editores. Nada de sudo vim, sudo python ni sudo less. Si necesitas editar un archivo propiedad de root, usa sudoedit.
4. Minimiza las reglas NOPASSWD. Úsalas solo para procesos automatizados y únicamente para comandos concretos con rutas completas.
5. Activa el registro de sudo. Como mínimo, registra todos los comandos de sudo. En sistemas sensibles, activa el registro completo de E/S.
6. Considera doas para sistemas más sencillos. Si no necesitas integración con LDAP ni reglas de coincidencia complejas, doas es más fácil de configurar correctamente.
7. Renueva las cachés de credenciales con agresividad. Reduce timestamp_timeout a entre 1 y 5 minutos, o desactiva la caché por completo en servidores de producción.

El mejor mecanismo de escalada de privilegios es el que concede el mínimo acceso necesario, durante el mínimo tiempo necesario, con un registro de auditoría completo. Todo lo demás es un compromiso.

sudo no va a desaparecer. Está demasiado integrado en scripts, automatizaciones, documentación y memoria muscular como para desaparecer. Pero el panorama de alternativas es más sano que nunca. Ya sea que te quedes con sudo (bien endurecido), cambies a doas (por simplicidad) o adoptes run0 (para sistemas críticos de seguridad), lo importante es entender qué hace realmente tu herramienta de escalada de privilegios, porque la brecha entre lo que la gente cree que hace sudo y lo que realmente hace es donde viven la mayoría de los incidentes de seguridad.