In light of recent events, a significant debate has emerged about the vulnerabilities in which systemd is indirectly involved, especially during the sshd/xz backdoor incident (CVE-2024-3094), highlighted the potential security risks associated with the dependencies of libsystemd, a library crucial for integrating services with systemd.
The crux of the issue lies in the observation that libsystemd, by being linked to all systemd services and any third-party services wishing to communicate with systemd, introduces extra dependencies that may serve as sources of vulnerabilities.
The proposed solution to this vulnerability concern is a substantial reduction of libsystemd’s dependencies to only include libc, the standard C library, thereby minimizing the attack surface for potential security threats. Current implementations include several other libraries, which may not be necessary for implementing core libsystemd functionalities.
In response to these concerns, a feature request has been raised for systemd to minimize libsystemd’s dependencies to just libc. The rationale behind this request is to strip down libsystemd to its core functionalities, thereby reducing the risk of vulnerabilities that could compromise system security.
However, this approach may involve reorganizing libsystemd into multiple libraries, each catering to specific APIs, and ensuring that only the necessary dependencies are included where they are genuinely needed.
Lennart Poettering, a key figure behind systemd, addressed the concerns by highlighting recent changes that alleviate some of these security worries. According to him, libsystemd no longer mandates compression libraries as hard dependencies in the latest git main version.
Moreover, plans are underway to remove libgcrypt as a hard dependency, further streamlining libsystemd and enhancing system security. Additionally, it was noted that sshd has implemented the sd_notify() function independently, a move Poettering recommends for projects of such a nature.
Finally, the discussion also touched on the possibility of exposing dynamic loading (dlopen) information in a manner that could be read from ELF metadata, offering a more transparent way to understand and manage dependencies.
This proposal suggests a collaborative approach, encouraging input and support from various stakeholders in the Linux ecosystem, including package maintainers and system builders.
The details of the entire discussion and proposal are available for follow-up on the project’s GitHub repository.
