Hardening de servicios systemd: lo que la puntuación de exposición no te dice
Ejecuta systemd-analyze security en una máquina cualquiera y obtendrás una tabla de servicios con un número junto a cada uno. Resulta tentador leer ese número como un veredicto. La página de manual dice, en términos inusualmente directos, que no lo es.
Qué mide realmente el comando
systemd-analyze security inspecciona los ajustes de seguridad y de sandboxing de las unidades de servicio. Si se le da el nombre de una unidad, muestra un análisis detallado; si no se le da ninguno, inspecciona todas las unidades de servicio de larga duración cargadas en ese momento e imprime una tabla escueta.
Asigna a cada ajuste relevante un exposure level (nivel de exposición) numérico y después calcula un valor global para la unidad. La documentación lo describe como «una estimación en el rango 0.0…10.0 que indica hasta qué punto un servicio está expuesto desde el punto de vista de la seguridad». Los valores altos significan que se ha aplicado muy poco sandboxing. Los valores bajos significan un sandboxing estricto y restricciones fuertes.
Hasta aquí parece un escáner. La parte importante es la advertencia que viene a continuación.
Los tres límites que el manual declara abiertamente
Solo ve lo que el propio systemd implementa. La documentación es explícita: la herramienta «solo analiza las funciones de seguridad por servicio que el propio systemd implementa», lo que significa que «cualquier mecanismo de seguridad adicional aplicado por el código del servicio mismo no se tiene en cuenta». Un servicio que renuncia a sus privilegios internamente, se aplica un chroot a sí mismo o usa su propio filtro seccomp no recibe crédito alguno.
Una puntuación alta no significa vulnerable. Esta frase merece citarse entera, porque es la que la gente se salta: un exposure level alto «ni significa que no haya un sandboxing efectivo aplicado por el código del propio servicio, ni que el servicio sea realmente vulnerable a ataques remotos o locales». Lo que sí indica es que el servicio «podría beneficiarse de ajustes adicionales».
Los ajustes individuales pueden deshacerse. El manual advierte de que muchos ajustes de sandboxing «individualmente pueden eludirse» si no se combinan con otros. Da un caso concreto: un servicio que conserva el privilegio de establecer o deshacer puntos de montaje puede revertir desde su propio código muchas de las demás opciones de sandboxing. La herramienta tiene en cuenta algunas de estas relaciones, pero la documentación dice con claridad que no las contempla todas.
Por qué «combinados» es la palabra clave
Vale la pena detenerse en el ejemplo de los puntos de montaje, porque cambia la forma en que deberías leer tus propios resultados.
Si una unidad puede manipular puntos de montaje, entonces las restricciones expresadas como visibilidad del sistema de ficheros pueden ser revertidas potencialmente por el propio servicio. La restricción sigue estando declarada, y la puntuación la sigue contando, pero su valor práctico depende de que haya otro ajuste presente junto a ella.
Por eso el enfoque de lista de comprobación produce resultados decepcionantes. Elegir las tres directivas que bajan la puntuación más rápido puede dejar una configuración que puntúa bien y aguanta mal. La conclusión de la propia documentación es que cada servicio debería usar «los ajustes de sandboxing y de seguridad más completos y estrictos posibles», y no una selección de ellos.
Cómo usar la puntuación sin malinterpretarla
Una lectura viable, coherente con lo que el manual afirma sobre la herramienta:
Trátala como un inventario, no como una auditoría. Te dice qué protecciones a nivel de systemd faltan. Eso es genuinamente útil y barato de obtener. No te dice si un servicio es seguro.
Compárate contigo mismo a lo largo del tiempo. El uso más fiable es la detección de regresiones: una unidad cuyo exposure level sube tras actualizar un paquete o cambiar la configuración merece que se investigue. Esa comparación tiene sentido aunque el número absoluto no sea un veredicto.
No clasifiques servicios de terceros por su puntuación. Dos servicios con el mismo número pueden tener una exposición real muy distinta, porque la herramienta no puede ver el sandboxing que uno de ellos aplica internamente. Ordenarlos por la puntuación premiaría al que más declara y castigaría al que más hace.
Empieza por las unidades realmente alcanzables. Un servicio expuesto a la red con un exposure level alto es un asunto muy distinto de un temporizador local con el mismo número. La puntuación no sabe cuál es cuál; tú sí.
El resumen honesto
systemd-analyze security es una buena herramienta que se describe a sí misma con exactitud, algo más raro de lo que debería. Mide el sandboxing a nivel de systemd que has declarado, en una escala de 0 a 10, y dice explícitamente que un número alto no es un hallazgo de vulnerabilidad y que un número bajo no es un certificado de buena salud.
Úsala para encontrar protecciones que faltan y para detectar regresiones. Combina ajustes en lugar de escoger los más baratos, ya que el manual advierte de que las restricciones aisladas pueden deshacerse desde dentro del servicio. Y ten presente que el número describe tu configuración, no tu superficie de ataque.
Para la capa que hay por debajo de esta, nuestra guía de hardening de Linux cubre los parámetros del kernel, sysctl y el control de acceso obligatorio.
La descripción del comando, el rango de exposición de 0.0 a 10.0, los tres límites declarados y el ejemplo de los puntos de montaje están tomados de la página de manual de systemd-analyze tal como se distribuye con systemd 255. La redacción y el comportamiento pueden cambiar entre versiones de systemd; consulta el manual de la versión que estés ejecutando. Este artículo no incluye ninguna muestra de salida del comando, porque el entorno usado para escribirlo no ejecuta systemd como PID 1, e inventar una habría tergiversado un resultado real.