(en su mayoría) las personas no inyectan vulnerabilidades deliberadamente, ocurren por accidente. A medida que aumenta el volumen de código, aumenta el número de defectos. Pero no es solo el tamaño:la cantidad de errores aumenta con la complejidad del código y aumenta más rápido que linealmente. Así que más código es una mala noticia para la seguridad.
La superficie de ataque de systemd es mucho más grande que initd:la configuración predeterminada tiene varias interfaces.
Una gran molestia para mí es la filosofía de diseño; la intención es que systemd proporcione una forma más unificada para que los distribuidores integren servicios. Pero esto significa eliminar el control sobre el sistema de los administradores del sistema (más allá del impacto de reemplazar un ecosistema complejo pero bien entendido). Deliberadamente hace que sea difícil o imposible lograr algo que podría hacerse con initd (tenga en cuenta que hay muchas opciones para los administradores de servicios que se ejecutan bajo initd:djb daemontools, upstart, initng, rund, procd, openrc.... La mayoría de las cuales resuelven los problemas de paralelización/dependencia que limitan el sistema sysv rc init).
Gran parte de la lógica del inicio de un sistema Unix se implementa en scripts de shell. Esto hace que sea mucho más fácil no solo aplicar ingeniería inversa a la operación, sino también instrumentarla y ampliar las capacidades. Systemd traslada más lógica a binarios y se basa más en un complejo y pobremente documentado configuración.
La combinación de reducir deliberadamente el nivel de control por parte del administrador del sistema y no apoyar al administrador del sistema en su tarea hace que sea más difícil para ellos hacer su trabajo, lo que incluye garantizar la seguridad del sistema.
Otra consecuencia de toda esta complejidad en PID 1 significa que debería reiniciar su sistema con mucha más frecuencia. Además del impacto en la disponibilidad, esto también significa mover su sistema a través de una serie de estados intermedios, que pueden exponer temporalmente vulnerabilidades que son difíciles de detectar en un sistema homeostático. El uso de daemon-reexec para evitar esto genera un nuevo conjunto de problemas.
El modelo de dictador benévolo de por vida parece funcionar bien para el kernel de Linux, pero no es así como opera el resto de la industria de código abierto. De hecho, es quizás la excepción que confirma la regla:que el código abierto funciona porque nadie está a cargo, no a pesar de que nadie esté a cargo. Systemd asume el control sobre mucho de la funcionalidad en un sistema Linux, sin embargo, opera como una comunidad relativamente pequeña. Y según el premio pwnie, parece estar algo introvertido:no hay muchos ojos en el código:nadie escucha cuando se plantean inquietudes sobre el código.
Systemd es en realidad una colección de varias partes, y para que una comparación tenga sentido, debe comparar las partes que realmente se corresponden entre sí.
Primero veamos SysV init:este es un programa muy pequeño que se ejecuta como el primer proceso después del arranque que realiza una configuración muy básica, luego lee un archivo de configuración (/etc/inittab ) e inicia uno o más programas configurados en el mismo, pudiendo reiniciarlos opcionalmente al salir. También abre algunos canales de comunicación (/dev/initctl , manejadores de señales) que hacen posible cambiar el nivel de ejecución actual, cuyo cambio dará como resultado que se ejecuten otros programas, nuevamente como se configuró en /etc/inittab .
Y eso es. Obviamente, esto no tiene una gran superficie de ataque, simplemente porque no hace casi nada. Por otro lado, todo lo demás que se requiere para administrar un sistema típico se delega en programas externos:cómo iniciar y detener un servicio específico (por ejemplo, servidor web, base de datos, red...), dependencias entre servicios (es decir, iniciar la base de datos primero , solo entonces el servidor web), monitoreo más complejo (funcionalidad de vigilancia), eliminación de privilegios y sandboxing, activación de servicios bajo demanda (por ejemplo, inetd), montaje de sistemas de archivos, ... Systemd integra gran parte de esta funcionalidad y, por lo tanto, es más complejo.
Ahora, la integración de estas cosas en un lugar central tiene un gran potencial para reducir la complejidad y la fragilidad general y, por lo tanto, hacer que el sistema sea más seguro. Tome las diversas funciones de "sandboxing", incluida la eliminación de privilegios, la restricción del acceso a ciertos directorios, directorios temporales privados, la configuración de espacios de nombres separados, el aislamiento de la red... Para systemd, estos son bastante fáciles de implementar como parte de la configuración del entorno de servicios, que - como gerente de servicio - debe hacer de todos modos. En contraste, con SysV init, se tendría que usar un programa separado; en la práctica, esto sería un conjunto de scripts de shell, o estaría integrado en los servicios individuales, extendiendo así el código "riesgoso" a más lugares.
Además, systemd proporciona al administrador del sistema los medios para configurar estas funciones fácilmente (unas pocas líneas en un archivo de configuración), lo que evita tener que implementarlas por sí mismo (lo que en algunos casos puede incluso implicar la modificación y recompilación de servicios). Por supuesto, en la práctica esto significa que no se utilizan en absoluto. Desde el punto de vista de la seguridad, el formato de configuración de estilo ini también es una ventaja sobre los scripts de shell turing-complete que se utilizan con SysV init.
En cuanto al modelo de desarrollo detrás de systemd:lo veo como una ventaja en comparación con la alternativa, porque hay un lugar central donde ocurre el desarrollo (¡y las pruebas exhaustivas!), que contrasta con la combinación anterior de código principalmente específico de distribución. Incluso el propio núcleo de inicio de SysV difería entre distribuciones, porque su flujo ascendente puede considerarse muerto. Y, contrariamente a lo que otros dicen, systemd upstream en realidad responde muy bien y está abierto a solicitudes de cambios razonables.
Dicho esto, puedo ver una situación en la que las cosas son diferentes, que es cuando las funciones proporcionadas por systemd no son necesarias, por ejemplo, si desea construir un enrutador o una puerta de enlace de red simple donde el conjunto de servicios requeridos se conoce de antemano y nunca cambiará Incluso allí, es posible que desee aprovechar las funciones de sandboxing fáciles de usar y, de todos modos, este es un caso especial que no se aplica a la gran mayoría de los sistemas.