Entre os desenvolvedores do gerenciador de sistema systemd, há uma discussão sobre a redução das dependências da biblioteca libsystemd, que está vinculada não apenas aos componentes do systemd, mas também a muitos aplicativos externos. Por exemplo, no Fedora, mais de 150 pacotes usam libsystemd como dependência. O iniciador da discussão acredita que a inclusão de bibliotecas externas adicionais na libsystemd, que não são controladas pelos desenvolvedores do systemd, aumenta significativamente a superfície de ataque em caso de comprometimento das bibliotecas externas, como ocorreu com a biblioteca liblzma.
Além da liblzma e glibc, a libsystemd também carrega as bibliotecas libzstd, liblz4 e libgcrypt, e a manutenção da segurança dessas bibliotecas se torna uma tarefa crítica. A libsystemd oferece acesso a 12 APIs principais (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path e sd-resolve), criando uma situação em que um aplicativo que utiliza a libsystemd apenas para chamar a função sd_notify para informar ao systemd sobre alterações de estado ou sd_journal para registrar dados no log, acaba se vinculando a todas as outras bibliotecas e manipuladores de API. Como solução, sugere-se dividir a libsystemd em várias bibliotecas separadas, responsáveis por APIs individuais, o que permitirá carregar dependências externas apenas onde forem necessárias.
Os desenvolvedores do systemd consideram a divisão inadequada, uma vez que os manipuladores presentes na libsystemd são interdependentes. A divisão exigiria um enorme trabalho e resultaria em perda de eficiência ou na necessidade de duplicação de código. Para reduzir o uso de memória na libsystemd, foi recentemente aprovada uma alteração implementando o carregamento dinâmico das bibliotecas liblzma, libzstd e liblz4 por meio da chamada dlopen(), em situações em que suas funções são realmente necessárias. Uma alteração semelhante será implementada na próxima versão para a libgcrypt.
Essa solução foi alvo de críticas, pois, em vez de um vínculo explícito e notável, o carregamento de bibliotecas externas agora será feito de forma implícita, o que complicará o diagnóstico, pois a relação entre as chamadas de API da libsystemd e as chamadas de funções de bibliotecas externas não será clara. A transição para o carregamento por meio da dlopen() em si não altera a arquitetura, mas apenas oculta os componentes externos dos desenvolvedores e usuários.
Lenart Pottering expressou forte desacordo com a ideia de dividir a libsystemd em várias bibliotecas, pois tal passo tornaria substancialmente mais difícil o compartilhamento de código no systemd e exigiria tornar todos os manipuladores internos públicos ou compilá-los estaticamente em cada biblioteca separadamente. No primeiro caso, surgiriam problemas de manutenção da estabilidade da API e namespaces, enquanto no segundo levaria ao aumento do tamanho devido à duplicação de código.
A carga de bibliotecas externas somente quando necessária, implementada para a próxima versão, é vista por Lenart como uma estratégia ideal. A proposta para resolver o problema da complexidade na obtenção de dados sobre bibliotecas carregadas dinamicamente é adicionar campos adicionais nos arquivos ELF com informações sobre essas dependências dinâmicas, que podem ser processadas por depuradores e exibidas na saída da ferramenta readelf.
Quanto à vinculação da libsystemd a um grande número de aplicativos, Lenart recomendou que desenvolvedores não tentem carregar a libsystemd apenas para uma função, mas implementem o manipulador de protocolo no nível do aplicativo. Por exemplo, a implementação da funcionalidade sd_notify() é bastante trivial e pode ser condensada em algumas linhas de código utilizando sockets UNIX (AF_UNIX). Uma implementação isolada de sd_notify disponível desde 2017 para OpenSSH foi recentemente aceita na versão portátil do OpenSSH 9.8, cujo lançamento está previsto para meados do verão.
Fonte: opennet.ru
