Usuarios, grupos, permisos y sudo

1Por qué importa

Cuando una aplicación web sufre una inyección de comandos, lo que el atacante consigue no es "acceso al servidor": consigue ejecutar como el usuario que corre la aplicación. Si ese usuario es www-data y está bien confinado, el daño se limita a lo que www-data puede tocar. Si es root, el daño es total. La diferencia entre esos dos mundos es enteramente una cuestión de usuarios y permisos, y se decide antes de que exista ningún atacante, al desplegar.

Este es el primer eslabón de la defensa en profundidad aplicada a un sistema real. Una aplicación siempre acabará teniendo un fallo; la pregunta de diseño es qué alcance tiene ese fallo cuando ocurra. Los permisos de archivo, el usuario de ejecución y la configuración de sudo son las tres palancas que fijan ese alcance. Entenderlas mal no da un error visible: da un servidor que funciona perfectamente hasta el día en que un fallo pequeño se convierte en un incidente grande.

2Conceptos

3Explicación profunda

Cada archivo lleva nueve bits de permiso agrupados en tres tríadas: dueño, grupo y otros. ls -l los muestra como -rwxr-x---. El primer carácter es el tipo (- archivo, d directorio, l enlace). Los nueve siguientes se leen de tres en tres: aquí el dueño tiene rwx, el grupo r-x y los demás nada. En octal eso es 750.

La regla que la gente olvida es que el kernel comprueba una sola tríada, la más específica que aplique. Si eres el dueño, se usan tus bits y ya está, aunque el grupo tuviera más permisos. No hay suma: ser dueño de un archivo 400 y estar además en un grupo con rw no te da escritura, porque como dueño solo te miran tus cuatro. Esto sorprende y es fuente de bugs de permisos reales.

Sobre directorios, los bits cambian de sentido y esto importa para la seguridad. r es listar el contenido, w es crear y borrar entradas dentro, y x es atravesarlo para llegar a lo que hay debajo. Un directorio con w para otros es peligroso: aunque un archivo dentro sea de solo lectura, cualquiera puede borrarlo y poner otro en su lugar, porque borrar es un permiso del directorio, no del archivo.

El bit SUID es donde los permisos se cruzan con la identidad. Normalmente un proceso corre con la identidad de quien lo lanza. Un binario con SUID corre con la del dueño del binario. Es un mecanismo legítimo e imprescindible: passwd necesita escribir en /etc/shadow, que es de root, así que passwd es SUID root. El problema no es el SUID: es ponérselo a un binario que hace algo demasiado general. Un binario SUID root que lee archivos arbitrarios lee cualquier archivo del sistema. Uno que ejecuta una orden de tu elección ejecuta esa orden como root. Por eso el inventario de binarios SUID de un sistema es una de las primeras cosas que mira alguien que ya entró: es el mapa de las escaleras hacia arriba.

sudo resuelve el mismo problema —dar un poco de poder sin darlo todo— pero por política en vez de por bit. /etc/sudoers declara qué usuario puede ejecutar qué comando como quién. Bien usado es mínimo privilegio en estado puro: "este operador puede reiniciar solo este servicio". Mal usado —ALL=(ALL) NOPASSWD: ALL, o permitir un comando que a su vez lanza una shell— es una puerta a root con otro nombre.

4Ejemplo sencillo

# Un edificio de oficinas

DUENO    tu despacho: tu llave abre, entras y trabajas          rwx
GRUPO    tu equipo: pueden pasar y leer, no reorganizar          r-x
OTROS    el resto del edificio: ni entran                        ---

# El SUID es una tarjeta de mantenimiento

Un becario NO puede abrir el cuarto de servidores.
Pero hay una "linterna de mantenimiento" (binario SUID de
mantenimiento) que, mientras la usas, te da los permisos de
mantenimiento. Si esa linterna solo alumbra, bien. Si ademas
abre puertas, cualquiera que la coja abre TODAS las puertas.

5Ejemplo técnico

Mira una tríada de archivos reales de un sistema y lo que cada permiso significa para la seguridad:

El comando que convierte esto en una auditoría es find. Buscar todos los binarios SUID de un sistema es una línea, y leerla con criterio es la mitad del trabajo de endurecer una máquina:

# todos los binarios SUID del sistema
find / -perm -4000 -type f 2>/dev/null

# directorios donde cualquiera puede escribir (world-writable)
find / -perm -0002 -type d 2>/dev/null

6Diagrama

flowchart LR
    U[becario · sin privilegios] -->|ejecuta| B[binario SUID · dueño root]
    B -->|adopta| R{{identidad: root}}
    R -->|accede| S[/etc/shadow · 600/]

7Código

Los permisos se vuelven auditables cuando se escriben como una comprobación repetible. Este script lista lo que hay que revisar en cualquier máquina y marca lo sospechoso:

#!/usr/bin/env bash
# auditar-permisos.sh — inventario minimo para endurecer un host
set -euo pipefail

echo "== binarios SUID (revisa que cada uno DEBA serlo) =="
find / -perm -4000 -type f 2>/dev/null

echo "== directorios world-writable (¿alguno en el PATH?) =="
find / -perm -0002 -type d 2>/dev/null | grep -v '/proc'

echo "== reglas sudo con NOPASSWD o ALL (peligrosas) =="
grep -RniE 'nopasswd|\(all\)\s*all' /etc/sudoers /etc/sudoers.d 2>/dev/null || echo "ninguna"

La lista de SUID no se borra entera: se compara con la esperada. Un passwd o un sudo SUID root son normales. Un find, un cp o un binario propio con SUID casi nunca lo son, y son exactamente el tipo de cosa que convierte a un usuario cualquiera en root.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

# debe fallar ahora: si lee el secreto, la defensa no sirvio
/usr/local/bin/leer /srv/datos/secreto.txt 2>/dev/null \
  && echo "FALLA: aun se lee" || echo "OK: sin acceso"

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos