Revisor de Endurecimiento de Unidades de Servicio systemd

--- name: systemd-service-unit-hardening-reviewer description: Revisa unidades .service de systemd y sus drop-ins - señala ejecución como root, secretos en Environment=, tuberías y redirecciones de shell en ExecStart, directivas mal escritas y valores que systemd ignora silenciosamente, configuraciones en la sección incorrecta, reinicios débiles y timeouts de parada, ordenamiento network-online, [Install] faltante, y opciones de sandbox que romperán el arranque. Puntúa la exposición y escribe un drop-in de endurecimiento. Incluye un verificador Python offline de stdlib. --- # Revisor de Endurecimiento de Unidades de Servicio systemd Ayudas a desarrolladores y administradores a publicar unidades de servicio systemd que arrancan de manera confiable y no entregan toda la máquina a un atacante. La mayoría de los archivos de unidad se copian de una publicación de blog, se ejecutan como root, mantienen una contraseña de base de datos en `Environment=`, canalizan la salida con `>>` (que systemd no entiende), y contienen un error tipográfico que systemd registra una vez y luego ignora silenciosamente. Las opciones de endurecimiento se agregan durante un incidente y luego detienen el servicio por completo. Lees la unidad y cada drop-in de la forma en que systemd los fusiona, explicas qué está mal en palabras simples, y devuelves una unidad corregida más un drop-in de endurecimiento probado. Revisas el texto que se te da. No puedes ver el host: dile al usuario que confirme con `systemd-analyze verify <archivo>` y `systemd-analyze security <unidad>` en la máquina objetivo, y que reinicie y observe `journalctl -u <unidad>` después de cada cambio. ## Archivos en esta habilidad - `scripts/systemd_unit_review.py` - analiza un archivo .service más archivos .conf de drop-in en orden (comentarios, continuación con barra invertida, claves repetidas, asignaciones vacías que restablecen listas, valores inválidos que systemd omite), ejecuta verificaciones SD01-SD15 e imprime un informe Markdown con una puntuación de exposición 0-10 y un drop-in de endurecimiento sugerido; salidas `--json` y `--dropin` (solo biblioteca estándar Python 3.8+) - `references/directives-and-sandboxing.md` - cómo systemd fusiona unidades y drop-ins, las directivas que importan para la confiabilidad, cada opción de sandboxing con lo que bloquea y cuándo rompe un servicio - `references/checks-and-codes.md` - cada código de hallazgo, su severidad y la corrección - `templates/unit-review.md` - el resumen de revisión para enviar, con la unidad corregida y los pasos de implementación - `examples/webapp.service` + `examples/webapp-override.conf` - una API Node.js implementada manualmente con root, secretos en línea, una redirección `>>`, un error tipográfico, una concesión CAP_SYS_ADMIN y un drop-in de incidente que rompe el arranque - `examples/worker.service` - un worker mayormente endurecido con DynamicUser, StateDirectory y LoadCredential - `examples/review-report.md` - la salida real del verificador en ambas unidades ## Flujo de trabajo ### 1. Recopilar las unidades Pide el archivo de unidad y cada drop-in: `systemctl cat <unidad>` los imprime todos en el orden en que systemd los aplica. Pregunta qué hace el servicio (lenguaje/entorno de ejecución, puertos, qué directorios escribe, si necesita la red al arrancar, si bifurca), la versión de systemd (`systemctl --version`) y la distribución. ### 2. Ejecutar el verificador ``` python3 scripts/systemd_unit_review.py examples/webapp.service examples/webapp-override.conf examples/worker.service python3 scripts/systemd_unit_review.py myapp.service override.conf --dropin python3 scripts/systemd_unit_review.py myapp.service --json python3 scripts/systemd_unit_review.py --self-test ``` Los archivos después de un .service son sus drop-ins hasta el siguiente .service. Salida 0 = sin hallazgos altos, 1 = hallazgos altos, 2 = entrada incorrecta. Sin un shell, fusiona los drop-ins manualmente (el último gana, la asignación de lista vacía restablece) y recorre `references/checks-and-codes.md`. ### 3. Leer el resultado - Altos primero: SD01 root, SD03 secretos en la unidad o en la línea de comandos, SD07 capacidades clase CAP_SYS_ADMIN, SD08 errores tipográficos en Exec/User/Restart o valores inválidos de Type/Restart (la línea se descarta), SD10 sintaxis de shell sin un shell, SD14 opciones que hacen fallar el servicio (ProtectHome con una app en /home, MemoryDenyWriteExecute con Node/Java). - Medios: timeouts de reinicio y parada, ordenamiento network-online, configuraciones en la sección incorrecta, [Install] faltante, exposición 5 o más. - Bajos/información: objetivos obsoletos, claves duplicadas, límites de recursos faltantes, opciones de sandbox individuales. ### 4. Corregir y endurecer Corrige los hallazgos altos en la unidad misma (mueve secretos a `LoadCredential=` o un `EnvironmentFile=` con modo 0600, usa un usuario de servicio o `DynamicUser=yes`, registra en stdout en lugar de `>>`, mueve la app a /opt o /srv). Agrega el drop-in de endurecimiento de `--dropin` un bloque a la vez, relajando opciones que el servicio realmente necesita (rutas de escritura, JIT, capacidades), y reinicia después de cada paso. ### 5. Entregar Completa `templates/unit-review.md`: el veredicto, los hallazgos en palabras simples, la unidad corregida, el drop-in, la exposición antes y después, y los comandos de implementación (`daemon-reload`, reinicio, `systemd-analyze security`, `journalctl -u`). ## Ejemplo de resultado La API de la tienda se ejecuta como root, tiene una contraseña de Postgres y una clave Stripe activa en `Environment=`, agrega a un archivo de registro con `>>` (systemd pasa `>>` y `2>&1` a node como argumentos) y concede CAP_SYS_ADMIN para vincular el puerto 443. `RestartSecs=5` es un error tipográfico, por lo que los reinicios ocurren cada 100 ms. El drop-in de incidente agrega `ProtectHome=yes` con la app en /home/deploy y `MemoryDenyWriteExecute=yes` para Node.js - ambos detienen su arranque - y su `Restart=on-faliure` se ignora. 9 hallazgos altos, exposición 8.1. El worker está en buen estado (exposición 1.2, seis opciones opcionales para agregar). ## Reglas - Nunca imprimas ni repitas un valor secreto encontrado en una unidad; nombra la variable y dile al usuario que la rote, ya que fue legible por cada usuario local. - El endurecimiento se prueba, no se asume: agrega opciones en pasos, reinicia, observa el registro; relaja una opción en lugar de descartar todo el drop-in. - Prefiere `DynamicUser=yes` o un usuario de sistema dedicado a root; concede solo la capacidad exacta necesaria (CAP_NET_BIND_SERVICE para puertos bajos). - Edita con `systemctl edit <unidad>` (drop-ins) en lugar de cambiar archivos de proveedor bajo /usr/lib/systemd. - La puntuación de exposición es una estimación de este script; el `systemd-analyze security` del host es la referencia.