Endurecer servicios Linux con systemd: permisos mínimos

Reduce alcance del proceso antes de cambiar el sistema

Un servicio que ejecuta una aplicación web no suele necesitar control total del servidor. Si el proceso corre como root o puede modificar cualquier ruta, un fallo de la aplicación también puede afectar archivos y servicios que no necesita. systemd permite limitar identidad, escritura y acceso al entorno desde la unidad del servicio.

No existe un bloque de directivas válido para todas las aplicaciones. Primero identifica qué usuario ejecuta el proceso, qué archivos necesita leer y dónde debe escribir. Después aplica una restricción por vez y prueba el flujo real. La documentación de systemd.exec explica estas opciones y sus dependencias del kernel y del entorno.

Inspecciona la unidad sin modificarla

Antes de editar, guarda la configuración efectiva y los síntomas actuales. Estos comandos consultan estado y configuración; no reinician el servicio:

systemctl status miapp.service --no-pager
systemctl cat miapp.service
systemctl show miapp.service -p User -p Group -p WorkingDirectory -p StateDirectory -p ReadWritePaths
systemd-analyze security --no-pager miapp.service

• systemctl cat muestra la unidad y sus drop-ins.
• systemctl show expone propiedades efectivas seleccionadas.
• systemd-analyze security señala controles de sandbox ausentes o activos.

El nivel de exposición de systemd-analyze security es una estimación de las restricciones que systemd reconoce. No es un análisis de vulnerabilidades, no evalúa toda la lógica de la aplicación y no prueba que el servicio esté seguro. La documentación advierte que las restricciones dependen de la configuración combinada y del acceso a otros servicios del sistema.

Si el servicio ya falla al iniciar, primero sigue la guía de diagnóstico de systemd. El endurecimiento y la investigación de una falla son tareas distintas.

Empieza por una identidad de servicio

Define un usuario y grupo separados para la aplicación. Comprueba que los archivos ejecutables y de configuración sean legibles para esa identidad, que los secretos no sean accesibles a otros usuarios y que las carpetas de escritura sean las mínimas necesarias. No cambies propietarios en bloque: podrías quitar acceso a una dependencia o exponer archivos sensibles.

Si la aplicación mantiene estado, systemd puede crear rutas de estado, ejecución, caché o logs con opciones como StateDirectory= y RuntimeDirectory=. Esto ayuda a declarar dónde necesita escribir. Confirma compatibilidad con la versión instalada y con el usuario configurado para la unidad.

Aplica restricciones por etapas

Algunas opciones quedan limitadas dentro de contenedores o si faltan funciones del kernel. También pueden romper aplicaciones que escriben fuera de sus directorios de estado, leen archivos del hogar o necesitan privilegios específicos. Lee man systemd.exec en el host y ajusta una restricción por cambio.

Ejemplo de drop-in para una aplicación con estado

Este ejemplo supone que la unidad ya usa el usuario miapp, que la aplicación guarda estado en /var/lib/miapp y que su versión de systemd admite estas directivas. No lo copies sin confirmar rutas, permisos y compatibilidad:

[Service]
User=miapp
Group=miapp
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=strict
StateDirectory=miapp

StateDirectory=miapp declara el directorio de estado administrado por systemd bajo /var/lib; esa ruta queda exceptuada de la restricción de solo lectura de ProtectSystem=strict. Si la aplicación necesita escribir en otra ubicación, documenta por qué y permite únicamente esa ruta. No habilites acceso de escritura global para resolver un error de permisos.

El ejemplo no configura capacidades Linux ni bloquea familias de red. Añade esos controles solo después de identificar las llamadas, sockets y puertos que el servicio requiere. Un límite incorrecto puede impedir que abra su puerto o contacte una dependencia.

Valida en staging y conserva una reversa

1. Guarda la unidad y los drop-ins actuales; registra usuario, rutas y versión de systemd.
2. Prueba el cambio en staging o en una ventana acordada, no sobre el único servicio productivo.
3. Valida la unidad con systemd-analyze verify usando la ruta real del archivo de unidad.
4. Recarga systemd y reinicia solo cuando aceptes la posible interrupción del servicio.
5. Comprueba respuesta de la aplicación, permisos, escritura de estado, conexiones necesarias y logs.
6. Si algo falla, restaura el drop-in anterior, recarga y repite las comprobaciones funcionales.

Revisa de nuevo systemd-analyze security miapp.service y conserva su salida junto con la prueba funcional. Un score menor no reemplaza la validación. Para una operación estable, añade una prueba de restauración según la guía de respaldos y restauración Linux y define alertas que indiquen si el servicio deja de responder con la guía de monitoreo de servidores.

Una configuración segura depende del servicio real

El objetivo no es activar todas las casillas del análisis. Es reducir permisos al mínimo compatible con el proceso, documentar excepciones y probar el servicio después de cada cambio. La plantilla debe adaptarse a la aplicación, la distribución, la versión de systemd y el modelo de despliegue.