(principalement) les gens n'injectent pas délibérément des vulnérabilités, elles se produisent par accident. Plus le volume de code augmente, plus le nombre de défauts augmente. Mais ce n'est pas seulement la taille - le nombre de bogues augmente avec la complexité du code et il augmente plus vite que linéairement. Donc, plus de code est une mauvaise nouvelle pour la sécurité.
La surface d'attaque de systemd est massivement plus grande que celle d'initd - la configuration par défaut a plusieurs interfaces.
Un gros ennui pour moi est la philosophie de conception; l'intention est que systemd offre aux distributeurs un moyen plus unifié d'intégrer les services. Mais cela signifie retirer le contrôle du système aux administrateurs système (au-delà de l'impact du remplacement d'un écosystème complexe mais bien compris). Cela rend délibérément difficile ou impossible de réaliser ce qui pourrait être fait avec initd (notez qu'il existe de nombreuses options pour les gestionnaires de services fonctionnant sous initd - djb daemontools, upstart, initng, rund, procd, openrc .... dont la plupart résolvent les problèmes de parallélisation/dépendance qui limitent le système sysv rc init).
Une grande partie de la logique de démarrage d'un système Unix est implémentée dans des scripts shell. Cela facilite non seulement la rétro-ingénierie de l'opération, mais également son instrumentation et l'extension des capacités. Systemd déplace plus de logique dans les binaires et s'appuie davantage sur un complexe et mal documenté configuration.
La combinaison de la réduction délibérée du niveau de contrôle par l'administrateur système et du fait de ne pas soutenir l'administrateur système dans sa tâche rend plus difficile pour lui de faire son travail - ce qui implique d'assurer la sécurité du système.
Une autre conséquence de toute cette complexité dans le PID 1 signifie que vous devrez redémarrer votre système beaucoup plus fréquemment. En plus de l'impact sur la disponibilité, cela signifie également faire passer votre système par une série d'états intermédiaires - qui peuvent temporairement exposer des vulnérabilités difficiles à détecter sur un système homéostatique. L'utilisation de daemon-reexec pour contourner ce problème pose un nouvel ensemble de problèmes.
Le modèle du dictateur bienveillant à vie semble bien fonctionner pour le noyau Linux, mais ce n'est pas ainsi que fonctionne le reste de l'industrie open source. En effet, c'est peut-être l'exception qui confirme la règle - que l'open source fonctionne parce que personne n'est en charge, pas malgré que personne ne soit en charge. Systemd prend le contrôle d'un lot des fonctionnalités d'un système Linux, mais il fonctionne comme une communauté relativement petite. Et selon le prix pwnie, il semble être quelque peu introspectif :il n'y a pas beaucoup de globes oculaires sur le code :personne n'écoute lorsque des inquiétudes sont soulevées à propos du code.
Systemd est en fait une collection de plusieurs parties, et pour qu'une comparaison ait un sens, vous devez comparer les parties qui correspondent réellement les unes aux autres.
Regardons d'abord SysV init :il s'agit d'un très petit programme qui est exécuté comme le premier processus après le démarrage qui effectue une configuration très basique, puis lit un fichier de configuration (/etc/inittab ) et démarre un ou plusieurs programmes qui y sont configurés, en les redémarrant éventuellement lorsqu'ils se terminent. Il ouvre également certains canaux de communication (/dev/initctl , gestionnaires de signaux) qui permettent de changer le niveau d'exécution actuel, dont un changement entraînera l'exécution d'autres programmes, toujours comme configuré dans /etc/inittab .
Et c'est tout. Évidemment, celui-ci n'a pas une grande surface d'attaque, simplement parce qu'il ne fait presque rien. D'un autre côté, tout ce qui est nécessaire pour gérer réellement un système typique est délégué à des programmes externes :comment démarrer et arrêter un service spécifique (par exemple, serveur Web, base de données, réseau...), les dépendances entre les services (c'est-à-dire démarrer la base de données en premier , puis seulement le serveur web), surveillance plus complexe (fonctionnalité de surveillance), suppression de privilèges et sandboxing, activation de service à la demande (par exemple inetd), montage de systèmes de fichiers, ... Systemd intègre une grande partie de cette fonctionnalité et est donc plus complexe.
Maintenant, l'intégration de ces choses dans un endroit central a un grand potentiel pour réduire la complexité et la fragilité globales et ainsi rendre le système plus sûr. Prenez les différentes fonctionnalités de "sandboxing", y compris la suppression des privilèges, la restriction de l'accès à certains répertoires, les répertoires temporaires privés, les paramètres d'espaces de noms séparés, l'isolation du réseau... Pour systemd, elles sont assez faciles à mettre en œuvre dans le cadre de la configuration de l'environnement de services, qui - en tant que gestionnaire de service - doit le faire de toute façon. En revanche, avec SysV init, un programme séparé devrait être utilisé; en pratique, il s'agirait d'un ensemble de scripts shell, ou il serait intégré dans les services individuels, répartissant ainsi le code "risqué" sur plus d'endroits.
De plus, systemd fournit à l'administrateur système les moyens de configurer facilement ces fonctionnalités (quelques lignes dans un fichier de configuration), les dispensant d'avoir à les implémenter eux-mêmes (ce qui dans certains cas peut même impliquer la modification et la recompilation des services !). Bien sûr, dans la pratique, cela signifie qu'ils ne sont pas du tout utilisés. Du point de vue de la sécurité, le format de configuration de style ini est également un avantage par rapport aux scripts shell turing-complete utilisés avec SysV init.
Quant au modèle de développement derrière systemd :je vois cela comme un avantage par rapport à l'alternative, car il y a un endroit central où le développement (et des tests approfondis !) se produit, ce qui contraste avec le mélange précédent de code principalement spécifique à la distribution. Même le noyau d'init SysV lui-même différait d'une distribution à l'autre, car son amont peut être considéré comme mort. Et contrairement à ce que d'autres disent, systemd amont est en fait très réactif et ouvert aux demandes de changement raisonnables.
Cela dit, je peux voir une situation où les choses sont différentes, c'est-à-dire lorsque les fonctionnalités fournies par systemd ne sont pas nécessaires, par exemple si vous souhaitez créer un routeur ou une simple passerelle réseau où l'ensemble des services requis est connu à l'avance et ne changera jamais. Même là, vous voudrez peut-être profiter des fonctionnalités de sandboxing faciles à utiliser, et c'est de toute façon un cas particulier qui ne s'applique pas à la grande majorité des systèmes.