En 02-07 viste una s donde esperabas una x y te prometí que la entenderías a fondo en esta lección. Ha llegado el momento, y viene acompañada de la otra pieza que has usado durante cuatro módulos sin preguntarte nada: sudo. Escribes sudo decenas de veces al día, pero ¿quién ha decidido que puedas? ¿Dónde está escrito? ¿Qué pasaría si Marta te pidiera que luis pudiera reiniciar la aplicación —solo reiniciarla— sin darle la máquina entera? Esta lección responde a las tres preguntas y añade las herramientas que el modelo clásico ugo/rwx no cubre: capabilities, ACL y atributos inmutables. Al final, operador podrá desplegar Tramontana con una regla de sudoers escrita por ti, y Luis leerá los logs sin estar en adm.

1. Por qué no se trabaja como root
2. su, su -, sudo -i y sudo -s comparados
3. sudo a fondo: caché, entorno y el error de la redirección
4. sudoers: sintaxis, visudo y reglas seguras
5. Trazabilidad: dónde queda la huella de sudo
6. Recuperarse de un sudoers roto
7. SUID: UID real frente a UID efectivo
8. SGID en directorios: el bit del trabajo en equipo
9. El sticky bit y /tmp
10. Capabilities: el sustituto moderno de SUID
11. ACL: permisos que ugo no sabe expresar
12. Atributos extendidos e inmutabilidad
13. Caso Tramontana: la regla de sudoers del despliegue

Root no tiene permisos: root no tiene comprobación de permisos. El kernel, ante un proceso con UID efectivo 0, se salta la verificación entera. Eso significa tres cosas:

• Un error es irreversible. rm -rf /opt/tramontana / con un espacio de más, ejecutado como operador, falla con «Permiso denegado» a la segunda ruta. Ejecutado como root, borra el sistema.
• No hay trazabilidad. Si cinco personas comparten la contraseña de root, auth.log dirá «root hizo X» y nadie sabrá quién fue. Con sudo, dirá «operador ejecutó X como root».
• No hay mínimo privilegio. Quien necesita reiniciar un servicio no necesita poder leer /etc/shadow ni reformatear un disco.

Por eso Ubuntu viene de fábrica con root sin contraseña utilizable (! en shadow, como viste en 05-01) y todo el trabajo administrativo pasa por sudo.

El guion de su - (y de -i) es lo que marca la diferencia: sin él te llevas tus variables, tus alias y tu PATH a una sesión con UID 0, y ese es justo el vector por el que un PATH manipulado con un ls falso acaba ejecutándose como root. Si necesitas una sesión de root, usa sudo -i. Y como norma general, ninguna de las dos: un sudo por acción deja mejor rastro que una sesión de root abierta media hora.

Lo que hace sudo al invocarlo: comprueba tu identidad contra /etc/sudoers, te pide tu contraseña (no la de root), registra la orden, construye un entorno nuevo y ejecuta el comando con la identidad de destino.

La caché de credenciales guarda que ya te autenticaste durante 15 minutos por terminal (timestamp_timeout, en minutos; 0 la desactiva y -1 la hace eterna, lo que es mala idea). sudo -k la invalida ahora mismo, sudo -v la renueva sin ejecutar nada, útil al principio de un script largo.

Opciones que se usan a diario:

Por defecto env_reset borra tu entorno y secure_path impone un PATH fijo. Es una protección deliberada: sin ella, exportar LD_PRELOAD o alterar el PATH antes de un sudo sería un ascenso a root inmediato. Esa es también la razón de que sudo no encuentre a veces un binario tuyo de /home/operador/bin: no está en secure_path, y hay que dar la ruta absoluta.

Y el clásico que arrastramos desde el Módulo 3:

No falla echo: falla la redirección, que la hace tu shell —que sigue siendo operador— antes de que sudo llegue a ejecutarse. Las dos soluciones correctas:

El fichero es /etc/sudoers, pero no se edita: se edita con visudo, y las reglas propias se ponen en ficheros aparte dentro de /etc/sudoers.d/, que sudoers incluye con @includedir. visudo bloquea el fichero contra ediciones simultáneas y, sobre todo, valida la sintaxis antes de guardar. Un sudoers con un error de sintaxis deja el sistema sin ningún sudo funcional, y eso es una emergencia.

Los ficheros de /etc/sudoers.d/ deben tener modo 0440, propiedad root:root, y no llevar punto ni acabar en ~ en el nombre, o sudo los ignora en silencio.

• % delante del nombre significa grupo: por eso pertenecer a sudo te da poderes, es esta línea.
• máquina permite distribuir el mismo sudoers a un parque entero; en un servidor suelto se pone ALL.
• (root) es la identidad de destino; (ALL:ALL) permite además elegir grupo con -g.
• NOPASSWD: evita pedir la contraseña. Cómodo para lo que ejecuta un script; peligroso para todo lo demás.

sudoers admite ! para denegar, y es una trampa:

Se salta de mil maneras. Si puedes ejecutar ALL, puedes ejecutar cp /bin/bash /tmp/sh && chmod u+s /tmp/sh, o simplemente:

La regla de oro: una regla de sudo es una lista blanca. Enumera lo que se permite; no intentes enumerar lo que se prohíbe. Y desconfía de cualquier comando que sepa ejecutar otros comandos o editar ficheros arbitrarios (vim, less, find, awk, tar --to-command, systemctl sin subcomando fijo, cualquier intérprete).

Reglas seguras:

La misma información está en el journal (journalctl -t sudo, que veremos en 05-06). Los intentos fallidos se registran igual, y son la señal de alarma más barata que tiene un servidor.

Si necesitas más, sudoers puede grabar la sesión entera con Defaults!SERVICIO log_input, log_output y Defaults iolog_dir=/var/log/sudo-io; se reproduce con sudoreplay -l y sudoreplay ID. Ojo: graba lo que se teclea, incluidas contraseñas escritas por error, así que ese directorio es material sensible y su retención debe estar acordada.

Si guardaste un sudoers inválido sin visudo, cualquier sudo responde algo como >>> /etc/sudoers: syntax error near line 22 <<< y se niega a funcionar. Salidas, por orden de preferencia:

1. Una sesión root aún abierta en otra terminal: arréglalo desde ahí. Por eso conviene tener una abierta mientras se tocan estos ficheros.
2. pkexec, que usa polkit y no depende de sudoers: pkexec visudo (requiere que exista una regla polkit para tu usuario, habitual en instalaciones de escritorio).
3. Modo de recuperación: reiniciar, elegir Advanced options → recovery mode → root shell, remontar con mount -o remount,rw / y ejecutar visudo. El procedimiento completo es materia de 07-01.

La costumbre que evita todo esto: editar siempre con visudo, y antes de cerrar la sesión, comprobar en otra terminal que sudo -l sigue funcionando.

Todo proceso lleva dos identidades: el UID real (quién lo lanzó) y el UID efectivo (con quién se comprueban los permisos). Normalmente coinciden. El bit SUID rompe esa igualdad: al ejecutar un binario con SUID, el kernel pone como UID efectivo el del propietario del fichero, no el de quien lo ejecuta.

El ejemplo canónico es passwd, que tiene que escribir en /etc/shadow (640 root:shadow) siendo invocado por un usuario normal:

Esa s en el lugar de la x del propietario es SUID. Mientras corre, passwd es root, y su código está escrito para hacer exactamente una cosa y nada más.

Un SUID root propio es casi siempre un fallo de seguridad, porque cualquier descuido dentro del programa —una llamada a system(), un PATH heredado, un desbordamiento— se convierte en root para quien lo invoque. Un script de shell con SUID ni siquiera funciona: Linux ignora el bit en los intérpretes, precisamente porque es imposible de asegurar.

Auditoría obligatoria en cualquier servidor:

Guarda esa lista como línea base. Cualquier binario que aparezca después y no venga de un paquete es una alarma. -perm -2000 hace lo mismo con SGID.

En un ejecutable, SGID es el equivalente de SUID para el grupo. Pero su uso importante es otro: en un directorio, SGID hace que todo lo que se cree dentro herede el grupo del directorio en lugar del grupo primario de quien lo crea. Es la pieza que hace viable el trabajo compartido.

Sin SGID, si operador (grupo primario operador) deja una copia en /srv/tramontana/backups, el fichero pertenece al grupo operador y luis no puede leerlo aunque ambos estén en tramontana. Con SGID:

Grupo tramontana sin haberlo pedido: eso es SGID. Aplícalo a todo el árbol compartido y no solo a la raíz:

El bit SGID no arregla los permisos: si tu umask es 027, el fichero sale rw-r----- y el grupo solo lee. Para que el grupo también escriba hace falta umask 007, o mejor, una ACL por defecto (apartado 11).

/tmp es escribible por todo el mundo. Sin protección adicional, cualquiera podría borrar el fichero temporal de otro, porque el permiso de borrado depende del directorio, no del fichero. El sticky bit corrige eso: en un directorio con sticky, solo pueden borrar o renombrar un fichero su propietario, el propietario del directorio y root.

La t final es el sticky bit (octal 1). Es la razón de que el mktemp de tus scripts del Módulo 4 sea seguro frente al vecino, aunque siga necesitando trap para limpiar.

Resumen de los tres bits:

Una S o una T mayúsculas en ls -l significan que el bit especial está puesto pero falta la x correspondiente: casi siempre es un error de escritura.

SUID es todo o nada: das root entero para conseguir una sola facultad. Las capabilities de Linux parten los privilegios de root en unas cuarenta piezas independientes, y se pueden conceder una a una.

El caso de manual: Tramontana quiere escuchar en el puerto 80, y los puertos por debajo de 1024 requieren privilegio. En lugar de correr la aplicación como root:

e es effective y p es permitted. Ahora el binario abre el 80 siendo svc-tramontana y no puede hacer nada más de lo que root podría. Otras habituales: cap_net_raw (para un ping propio), cap_dac_read_search (leer cualquier fichero: casi tan peligroso como root, cuidado), cap_sys_time.

Advertencias reales: las capabilities son un atributo extendido del fichero, así que se pierden al copiar, al reemplazar el binario en un despliegue y en un sistema de ficheros que no las soporte. Si desplegar.sh sustituye el release, hay que volver a aplicarlas — o, mejor, dejar que systemd lo haga con AmbientCapabilities en la unidad, que es lo que montaremos en 05-05.

El modelo clásico tiene tres sujetos: propietario, grupo, otros. Marta pide algo que no cabe ahí: «que Luis pueda leer /var/log/tramontana para diagnosticar, pero sin meterlo en adm, que da acceso a todos los logs del sistema». Con ugo solo podrías cambiar el grupo del directorio o abrirlo a «otros». Con ACL, das exactamente ese permiso a esa persona.

Concedemos lectura y recorrido a luis, y que la herede lo que se cree después:

Ese + al final de los permisos es la marca de que hay una ACL; sin él, ls -l te mentiría por omisión.

La máscara (mask::) es el techo de permisos efectivos de todas las entradas salvo user:: y other::. Si la máscara es r--, una entrada user:luis:rw- queda efectivamente en r--, y getfacl lo indica con un comentario #effective:r--. Y aquí está la trampa: chmod g=... reescribe la máscara, de modo que un chmod -R 750 posterior puede anular en silencio todas tus ACL. Si usas ACL, revísalas después de cualquier chmod sobre esa ruta.

Requisito: el sistema de ficheros debe estar montado con soporte ACL, que en ext4 de Ubuntu 24.04 viene activado de serie. Y no olvides que cp no copia ACL salvo con -p o -a, ni tar salvo con --acls.

Por debajo de los permisos hay una capa más: los atributos del sistema de ficheros. El útil para un administrador es i, inmutable: el fichero no se puede modificar, borrar, renombrar ni enlazar, ni siquiera por root, hasta que se retire el atributo.

Es una red de seguridad contra el error humano y contra scripts demasiado entusiastas, no contra un atacante con root (que puede quitarlo igual que tú). Otro atributo útil es a (append-only), pensado para ficheros de log: se puede añadir, no reescribir ni truncar. Y una advertencia práctica: un fichero inmutable rompe cualquier automatismo que lo toque, incluidos apt y tu propio desplegar.sh. Documéntalo en el HISTORIAL o lo pagarás a las 4:20 de la madrugada.

Marta aprueba los despliegues, pero quien los ejecuta es operador, que hoy tiene sudo completo por estar en el grupo sudo. El objetivo: que pueda hacer su trabajo —gestionar el servicio y desplegar— sin root total, y que luis pueda consultar el estado sin tocar nada.

Detalles que no son decorativos:

• desplegar-seguro es un envoltorio propiedad de root:root y modo 0755 en /home/operador/bin/. Si perteneciera a operador y fuera escribible por él, la regla equivaldría a dar root completo: podría reescribir el script con /bin/bash dentro. Este es el fallo más frecuente al conceder «solo un script».
• Los subcomandos van fijos: systemctl a secas permitiría systemctl edit, y de ahí a un editor como root hay un paso.
• luis tiene solo lectura y con NOPASSWD, porque lo llama desde su panel de diagnóstico. operador sigue en el grupo sudo mientras dure la transición; el objetivo a medio plazo es sacarlo y quedarse solo con estas reglas.

Aviso de cumplimiento. Una regla de sudo es una concesión de privilegio con impacto directo en la seguridad del sistema y en el acceso a datos personales de huéspedes (los logs y las copias los contienen). Toda alta, cambio o retirada de reglas debe quedar documentada, con fecha y autorizante, y debe revisarla el responsable de seguridad o de cumplimiento (RGPD) antes de aplicarse en producción. Revisa sudo -l -U usuario para cada cuenta al menos una vez al trimestre y en cada baja de personal.

Y las piezas del apartado anterior aplicadas al proyecto:

• Editar /etc/sudoers con un editor normal. Un error de sintaxis y te quedas fuera: visudo siempre, y ten una segunda terminal abierta mientras editas.
• Fichero mal nombrado o con permisos incorrectos. sudo ignora en silencio los ficheros de /etc/sudoers.d/ que contengan un punto o no sean 0440. Comprueba con sudo -l -U usuario.
• Conceder un script que el usuario puede editar. Es root completo disfrazado. El objetivo de una regla debe ser root:root y no escribible por su beneficiario.
• Usar comodines o comandos «que ejecutan cosas». systemctl, vim, less, find, tar, cualquier intérprete: todos tienen una vía conocida a shell. Fija subcomando y argumentos, y no confíes en ! para denegar: las listas negras se saltan siempre.
• Aplicar SGID solo a la carpeta raíz de un árbol compartido: los subdirectorios existentes no lo heredan; usa find -type d -exec chmod g+s {} +.
• Perder las capabilities en un despliegue. setcap vive en el fichero; si sustituyes el binario, desaparece. Declárala en la unidad de systemd.
• Un chmod que se lleva por delante las ACL al reescribir la máscara: tras cualquier chmod sobre una ruta con +, verifica con getfacl.
• Consejo: guarda la línea base de find / -perm -4000 y de getcap -r / junto al HISTORIAL. Comparar esa lista es la auditoría más barata y más eficaz que puedes hacer.

1. Una regla mínima y correcta. El becario debe poder reiniciar únicamente tramontana.service y ver su estado, sin contraseña para el estado y con contraseña para el reinicio. Escribe el fichero, instálalo con los permisos correctos, valídalo y demuestra que sudo systemctl restart nginx le queda prohibido.
2. Auditoría de SUID. Encuentra los binarios con SUID del sistema, comprueba a qué paquete pertenece cada uno y explica por qué encontrar /usr/local/bin/util con SUID root sería una alarma.
3. ACL de escritura para un tercero. Marta necesita dejar un fichero de tarifas en /srv/tramontana/backups/envios/ sin pertenecer al grupo tramontana. Concédele escritura solo en ese subdirectorio, con herencia, y verifica la máscara efectiva.

1.

Al intentar lo prohibido, como becario:

Nótese que la lista es blanca: no hemos escrito ninguna prohibición, y todo lo no enumerado queda fuera por construcción.

2.

/usr/local/bin/util no pertenece a ningún paquete: nadie de la distribución responde por él, no se actualiza con apt y nadie ha auditado su código. Con SUID root, cualquier fallo suyo —o cualquier system() que herede el PATH de quien lo invoca— entrega root a cualquier usuario del sistema. Un binario así en un servidor de producción se investiga como un posible compromiso, no se «deja por si acaso».

3.

u:marta:rwx sobre el directorio le permite entrar y crear; la entrada default: hace que los ficheros que deje dentro nazcan con rw- para ella. La máscara es rwx, así que los permisos efectivos son los concedidos: si valiera r-x, getfacl marcaría #effective:r-x y Marta no podría escribir pese a la entrada. Y recuerda: un chmod g=rx posterior sobre ese directorio reescribiría la máscara y anularía el permiso sin tocar la entrada de Marta.

Se acabó la magia de sudo y la de esa s que arrastrabas desde 02-07. Sabes que root no tiene permisos sino ausencia de comprobaciones, y por qué eso obliga a trabajar con mínimo privilegio y trazabilidad; distingues su de su - y sudo -s de sudo -i por el entorno que hereda cada uno; entiendes env_reset, secure_path y por qué la redirección de sudo echo falla; escribes reglas de sudoers con visudo, en /etc/sudoers.d/, con rutas absolutas, argumentos fijos y forma de lista blanca, sabiendo que las listas negras se saltan desde vim, find o awk; sabes dónde queda la traza y cómo salir de un sudoers roto.

Y dominas la capa de permisos que el modelo ugo no cubre: SUID y la diferencia entre UID real y efectivo, con find -perm -4000 como auditoría; SGID en directorios para que un equipo comparta ficheros de verdad, aplicado ya a /opt/tramontana/shared/uploads y a /srv/tramontana/backups; el sticky bit que hace seguro /tmp; las capabilities que sustituyen a un SUID entero por una sola facultad como cap_net_bind_service; las ACL con las que Luis lee /var/log/tramontana sin entrar en adm, con su máscara y su trampa del chmod; y chattr +i para blindar /etc/tramontana/app.conf. En /etc/sudoers.d/tramontana hay una regla real, validada y documentada, que permite operar el servicio sin repartir root.

El siguiente cabo suelto es el software. Has instalado cosas con apt durante cuatro módulos sin preguntarte de dónde venían, quién las firma ni qué pasa si el motor de base de datos salta de versión mayor una noche cualquiera mientras duermes. En Gestión de Paquetes verás las dos capas de Debian, dpkg y apt, la anatomía de un .deb, los repositorios en formato deb822 de Ubuntu 24.04 con sus claves en /etc/apt/keyrings/, cómo fijar versiones para que la base de datos de Tramontana no se mueva sola, y el debate incómodo de si un servidor debe reiniciarse solo tras una actualización de seguridad.