Entre los desarrolladores del gestor de sistema systemd se está discutiendo la cuestión de reducir las dependencias de la biblioteca libsystemd, que no solo se vincula a componentes de systemd, sino también a muchas aplicaciones externas. Por ejemplo, en Fedora, más de 150 paquetes utilizan libsystemd como dependencia. El iniciador de la discusión considera que la inclusión de bibliotecas externas adicionales en libsystemd, que no son controladas por los desarrolladores de systemd, aumenta significativamente la superficie de ataque en caso de compromiso de estas bibliotecas externas, tal como ocurrió con la biblioteca liblzma.
Además de liblzma y glibc, en libsystemd también se cargan las bibliotecas libzstd, liblz4 y libgcrypt, siendo el mantenimiento de la seguridad de estas bibliotecas una tarea críticamente importante. En libsystemd se proporciona acceso a 12 API básicas (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path y sd-resolve), y se plantea la situación en la que una aplicación que utiliza libsystemd solo para invocar la función sd_notify para informar a systemd sobre un cambio de estado o sd_journal para registrar datos en el log, se vincula a todas las demás bibliotecas y controladores de API. Como solución, se propone dividir libsystemd en varias bibliotecas independientes responsables de API específicas, lo que permitiría cargar dependencias externas solo donde son necesarias.
Los desarrolladores de systemd consideran que la división no es práctica, ya que los controladores presentes en libsystemd están interrelacionados. La división requeriría un enorme trabajo y resultaría en una pérdida de eficiencia o en la necesidad de duplicar el código. Para reducir el uso de memoria en libsystemd, recientemente se tomó la decisión de implementar la carga dinámica de las bibliotecas liblzma, libzstd y liblz4 mediante la llamada dlopen() en situaciones donde sus funciones son realmente necesarias. Un cambio similar se implementará a partir de la próxima versión para libgcrypt.
Esta solución ha sido objeto de críticas, ya que en lugar de un enlace explícito y obvio, la carga de bibliotecas externas ahora se realizará de manera implícita, lo que complicará el diagnóstico, ya que no es evidente la conexión entre las llamadas API de libsystemd y la invocación de funciones de bibliotecas externas. El simple cambio a la carga mediante dlopen() no cambia la arquitectura, sino que oculta los componentes externos de los mantenedores y usuarios.
Leonard Pottering expresó su categórico desacuerdo con la idea de dividir libsystemd en varias bibliotecas, ya que tal paso complicaría significativamente el uso compartido del código en systemd y requeriría que se convirtieran todos los manejadores internos en públicos o que se compilaran estáticamente en cada biblioteca. En el primer caso, surgirían problemas con el mantenimiento de la estabilidad de la API y los espacios de nombres, y en el segundo, aumentaría el tamaño debido a la duplicación de código.
La carga de bibliotecas externas solo según sea necesario, implementada para la próxima versión, es considerada por Leonard como una estrategia óptima. Se sugiere resolver el problema de la complicación para obtener información sobre las bibliotecas cargadas dinámicamente añadiendo campos adicionales a los archivos ELF con información sobre estas dependencias dinámicas, que pueden ser manejadas por los depuradores y mostrarse en la salida de la utilidad readelf.
En cuanto a la vinculación de un gran número de aplicaciones con libsystemd, Leonard recomendó a los desarrolladores de aplicaciones que no intenten cargar libsystemd por una sola función, sino que implementen el manejador de protocolos a nivel de aplicación. Por ejemplo, la implementación de la funcionalidad sd_notify() es bastante trivial y puede resumirse en unas pocas líneas de código al utilizar sockets UNIX (AF_UNIX). Desde 2017, existe una implementación aislada de sd_notify disponible para OpenSSH, y recientemente ha sido aceptada en la rama portable de OpenSSH 9.8, cuyo lanzamiento está previsto para mediados de verano.
Fuente: opennet.ru
