Ejecución con mínimos privilegios y disciplina con sudo

La mayoría de las brechas de seguridad en la automatización no se producen por exploits exóticos, sino porque los scripts se ejecutan con más privilegios de los necesarios. Un trabajo de cron que se ejecuta como root y solo necesita rotar un archivo de registro es un accidente esperando a ocurrir.

El principio de mínimo privilegio establece que cada proceso debe operar usando únicamente los permisos necesarios para realizar su tarea, y ninguno más. En los scripts de Bash, esto significa:

• Ejecutarse como un usuario sin privilegios siempre que sea posible
• Elevarse a root solo para los comandos específicos que lo requieran
• Abandonar los privilegios en cuanto termine el trabajo elevado
• No almacenar ni heredar credenciales fuera de su ámbito

En esta lección se explican técnicas concretas: delimitación de sudo, abandono de privilegios con su, protecciones de validación de UID y refuerzo de sudoers, para crear un modelo disciplinado de privilegios en scripts de producción.

Antes de cualquier bloque de código que realmente requiera root, el script debe verificar que se ejecuta con el UID efectivo esperado. Nunca lo dé por supuesto; compruébelo siempre.

$EUID es una variable especial de Bash que contiene el ID de usuario efectivo del proceso actual. Root siempre tiene un EUID igual a 0. Comprobarlo al principio del script, o alrededor de un bloque privilegiado, evita la ejecución accidental con una identidad incorrecta.

Use este patrón de protección:

Algunos scripts necesitan root legítimamente. En ese caso, la protección se invierte: falle pronto si no se está ejecutando como root, en lugar de permitir que el script llegue a una llamada al sistema privilegiada y produzca un error de permisos confuso a mitad de la ejecución.

Combinar la salida temprana con un mensaje de uso útil hace que los scripts se documenten por sí mismos:

El error más común consiste en colocar sudo al principio de un script y ejecutar después todo como root. En su lugar, aplique sudo únicamente al comando exacto que lo necesita; todo lo demás se ejecuta como su usuario habitual.

Esto limita el alcance del daño: si un atacante inyecta código en su script, solo podrá ejecutar con permisos de root las partes que no tengan sudo delante.

Compare los dos patrones siguientes. El segundo es mucho más seguro:

Invocar sudo somecommand en un script solo es seguro si el archivo sudoers está configurado para permitir exactamente ese comando, y nada más. Evite reglas como ALL=(ALL) NOPASSWD: ALL para las cuentas de servicio.

En su lugar, restrinja las reglas a comandos específicos con argumentos específicos usando la sintaxis segura para visudo. Campos clave de una regla de sudoers:

• Usuario: quién puede invocar sudo
• Host: en qué máquina (use ALL para facilitar la portabilidad)
• RunAs: qué identidad se debe asumir (casi siempre root)
• Comando: ruta absoluta completa, opcionalmente con argumentos literales

Ejemplos de reglas estrictas para una cuenta de servicio de implementación (deployer):

Cuando un script se inicia como root (por ejemplo, mediante un sistema de inicio o un cron que se ejecuta como root), pero la mayor parte del trabajo debería realizarse como un usuario sin privilegios, abandone los privilegios explícitamente en lugar de ejecutar todo el script como root.

Dos herramientas para ello:

• su -s /bin/bash -c 'command' username: inicia un shell como username y ejecuta el comando
• runuser -u username -- command args: opción preferida en Linux para cambiar de usuario dentro de scripts propiedad de root; es más limpia que su

El siguiente patrón muestra un envoltorio de implementación propiedad de root que cambia al usuario app para ejecutar la lógica real de la aplicación:

No siempre necesita cambiar a una sesión completa de shell. sudo -u username command ejecuta un único comando como el usuario especificado y después vuelve a la identidad del usuario que lo invocó. Esto resulta útil para modificar archivos propiedad de una cuenta de servicio sin conceder a esa cuenta acceso interactivo.

Combine esto con una regla de sudoers que permita exactamente esa combinación de usuario y comando:

Existe una superficie de ataque sutil: las variables de entorno heredadas por una sesión de sudo. De forma predeterminada, sudo restablece el entorno, pero las configuraciones incorrectas de env_keep o las anulaciones de env_reset pueden pasar variables controladas por un atacante, como LD_PRELOAD, PATH o PYTHONPATH, a comandos privilegiados.

Buenas prácticas:

• Use siempre rutas absolutas en scripts que se ejecuten mediante sudo; nunca dependa de $PATH
• Pase únicamente las variables que necesite explícitamente: sudo env VAR=value /path/to/cmd
• En sudoers, evite env_keep += PATH o env_keep += LD_*
• Use sudo -E solo cuando controle completamente y confíe en el entorno desde el que se realiza la llamada

Incluso cuando una regla de sudoers permite un script específico, se le pueden pasar argumentos arbitrarios, a menos que la regla también los restrinja. Un error habitual:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

Esto permite sudo /opt/scripts/manage.sh restart, pero también sudo /opt/scripts/manage.sh --arbitrary-flag. Si manage.sh pasa los argumentos sin comprobarlos a subcomandos privilegiados, tendrá un problema.

Aplique una defensa en profundidad: valide los argumentos dentro del script privilegiado y también en sudoers:

Cuando un script debe mantener brevemente un archivo, una credencial o un recurso privilegiado, use trap de Bash para garantizar que la limpieza se realice incluso en caso de error o de una señal. Esto evita la filtración de privilegios; por ejemplo, que quede atrás un binario setuid temporal o un socket propiedad de root si el script se bloquea.

El patrón siguiente crea un archivo temporal como root, lo utiliza y después lo elimina; un trap en EXIT lo garantiza:

El principio de mínimo privilegio es más fácil de aplicar cuando cada evento de elevación se registra con contexto: quién ejecutó qué, cuándo y por qué. Combine dos capas:

1. El propio sudo: /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL) captura automáticamente cada invocación de sudo
2. Registro de auditoría a nivel de script: escriba una entrada estructurada al inicio de cada función privilegiada para que la intención quede registrada junto al registro del sistema

El uso de una función sencilla para registros estructurados mantiene los historiales de auditoría coherentes y facilita su búsqueda con grep:

Compruebe su comprensión de la ejecución con mínimo privilegio en scripts de Bash.

En esta lección ha aprendido las técnicas para ejecutar scripts de Bash con el mínimo privilegio necesario en cada paso. Este es un resumen conciso de los principios clave:

• Verifique con $EUID: finalice rápidamente si el script se ejecuta con una identidad incorrecta, tanto si debe rechazar root como si debe exigirlo
• Limite sudo a comandos individuales: nunca eleve un script completo; aplique sudo únicamente a las líneas que realmente lo necesiten
• Escriba reglas de sudoers estrictas: especifique rutas absolutas completas y argumentos literales; evite los comodines y ALL
• Quite privilegios con runuser o sudo -u: cuando un script iniciado como root deba delegar la ejecución a un usuario sin privilegios, use la herramienta adecuada en lugar de ejecutarlo todo como root
• Use rutas absolutas: nunca dependa de $PATH dentro de código privilegiado; escriba explícitamente las rutas de los binarios para evitar su secuestro
• Valide los argumentos dentro de los scripts privilegiados: las reglas de sudoers son la primera línea de defensa, no la única; use listas de permitidos
• Use trampas y realice la limpieza: use trap cleanup EXIT para garantizar que los recursos privilegiados temporales se destruyan incluso en caso de error
• Registre cada elevación: las entradas de auditoría estructuradas, combinadas con el syslog integrado de sudo, proporcionan trazabilidad de cada acción privilegiada

Aplicadas de forma coherente, estas prácticas reducen la superficie de ataque de su automatización, pasando de root-en-todo-momento a root-solo-cuando-sea-demostrablemente-necesario, la característica distintiva de un Bash reforzado y preparado para producción.