La situation déplorable des administrateurs système

closeCet article a été publié il y a 8 ans 11 mois 13 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Cet article est une traduction de la création d’un blogueur allemand, Erich Schubert, doctorant en maths et informatique. Un point de vue que j’ai tendance à partager, et qui me freine dans l’étude des technologies à la mode ces derniers temps chez les sysadmins devenus trop feignants (vous savez, Docker et compagnie). Et j’y apporte ma petite touche à la fin.

L’administration système est dans un sale état. Une catastrophe.

Je ne me plains pas des administrateurs systèmes « old-school ». Ils savent comment garder leurs système en marche, gérer leurs méthodes de mises à jour.

Cette charge est dirigée contre les containers, les VMs préconstruites, et du bordel qu’ils créent parce que leurs concepts oublient la notion de confiance et de mises à niveau.

Considérez par exemple Hadoop. Personne ne semble aujourd’hui capable de construire Hadoop « de rien ». C’est un incroyable bordel de dépendances, de versions minimales et d’outils de compilation.

Aucun de ces « beaux » outils n’est compilable par un traditionnel make. Chaque outil débarque avec ses propres méthodes « du jour », incompatibles, non-portables, pour leur construction.

Et vu que personne n’est plus capable de tout compiler à la main, tout le monde ne fait que télécharger des binaires précompilés sur des sites aléatoires. Souvent sans aucune forme d’authentification ou de signature.

Le paradis des virus et de la NSA. Vous n’avez même plus besoin d’exploiter des failles de sécurité. Faites juste une « app » ou une VM ou une image Docker, et laissez les gens la télécharger et exécuter votre binaire malicieux dans leur réseau.

La page Wiki d’Hadoop de Debian est un exemple typique. Pour l’essentiel, les gens ont abandonné en 2010 l’idée de contruire Hadoop à partir des sources pour Debian et ont offert de jolis paquets.

Pour construire Apache Bigtop, vous avez apparemment besoin d’installer puppet3 en premier. Le laisser télécharger des données « magiques » depuis le net. Ensuite il essaie de lancer sudo puppet pour activer les portes dérobées de la NSA (par exemple, il télécharge et installe une version périmée du JDK, parce qu’il vous considère trop stupide pour installer Java vous-même). Et espère que la compilation gradle ne va pas lancer deux-cents lignes inutiles d’erreurs.

Je ne plaisante pas. Il va essayer d’exécuter des commandes telles que :

Notez que ça n’installe même pas le paquet correctement, ça ne fait que le décompresser dans le dossier root. Le téléchargement ne vérifie aucune signature, et évite soigneusement tout certificat SSL (source : Bigtop puppet manifests).

Même si la compilation fonctionne, ça va impliquer que Maven télécharge des binaires non signés depuis Internet, et les utiliser pour ladite compilation.

Au lieu de définir des architectures claires, modulaires, tout aujourd’hui finit en une horreur de dépendances interverrouillées. La dernière fois que j’ai vérifié, le classpath Hadoop avait plus de cents fichiers JAR. Je parie qu’il doit être de 150 maintenant, sans même utiliser l’un des bordels HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch (ou n’importe quel autre chaos d’Apache) pour l’instant.

Stack est le nouveau terme pour « Je n’ai aucune idée de ce que je suis en train d’utiliser ».

Maven, Ivy et sbt sont les outils à la mode pour obtenir un système qui passe sont temps à télécharger des binaires non signés sur Internet et les exécuter directement sur votre ordinateur.

Et avec les containers, ce massacre est encore pire.

Avez-vous essayé de mettre à jour la sécurité d’un container ?

Essentiellement, l’approche Docker se résume à télécharger un binaire non signé, l’exécuter, en espérant qu’il ne contienne aucune porte dérobée vers le réseau de votre société.

On dirait les sharewares pour Windows des années 90 pour moi.

Quand va-t-on voir apparaître la première image Docker qui contiendra la barre d’outils Ask pour navigateurs ? Le premier ver informatique à se propager au moyen d’une image Docker vérolée ?


Il y a quelques années, les distributions Linux tentaient de proposer un système d’exploitation sécurisé. Avec des paquets signés, construits à partir d’une chaine de confiance. On pouvait même reproduire un paquet.

Mais depuis, tout à été « Windowsisé ». Les « apps » sont la nouvelle course, que vous téléchargez et exécutez, sans même vous sentir concerné par leur sécurité, ou de la possibilité de passer à la nouvelle version. Parce que « vous n’avez qu’une vie » (NdT : You Live Only Once, YOLO, souvent synonyme qu’on fait une bêtise parce qu’on a qu’une occasion pour la faire).

Mise à jour : On m’a fait remarquer que ça a commencé bien avant Docker : « Docker est le nouveau « curl |sudo bash ». C’est vrai, mais maintenant, avec ces outils, il est devenu « standard » de télécharger et d’exécuter des programmes indignes de confiance dans votre « datacenter ». C’est moche, vraiment moche. Avant, les admins s’acharnaient à éviter les failles de sécurité, maintenant ils s’appellent eux-même « devops » et les introduisent d’eux-mêmes joyeusement dans leurs réseaux !

(Fin de la traduction)


J’ai déjà pu légèrement aborder cette approche lors de mes différents tests pour trouver une plateforme performante pour le blog. J’essaye le plus possible de ne pas sortir de la distribution, et de n’utiliser que des paquets fournis avec elle. Petits exemples :

  • Pour installer HHVM, il faut ajouter un dépôt externe, et dans ce cas faire confiance à Facebook (haha)
  • Pareil si vous voulez tester une version plus récente de PHP que celle fournie par Debian
  • et encore pareil pour MariaDB (ça a d’ailleurs inauguré le blog)
  • sans parler d’Nginx (la version proposée par Debian est actuellement très, très vieille).
  • Si je me suis restreint à la version antédiluvienne de MongoDB que fournit Debian pour mes premiers tests, afin de profiter des nombreuses améliorations des versions suivantes vous devez là aussi vous tourner vers leur dépôt maison.

Au moins ces exemples sont de « bons » exemples : chacun des dépôts tiers cités dispose d’une clé de signature, certes souvent hébergée chez Canonical, mais une signature tout de même. Et votre gestionnaire de paquets refusera de les installer sans votre permission expresse en l’absence de clé. Prenez le cas d’Opera : Pour Linux ils ne proposent qu’un .deb que vous pourrez installer sans aucune vérification de l’intégrité du paquet. Même sous Windows maintenant l’installateur dispose du certificat de l’éditeur.

Mais l’un des problèmes évoqué par l’auteur reste entier : certains de ces outils peuvent être sacrément difficiles voire impossibles à compiler vous-même sans installer une armée de dépendances, en croisant les doigts pour que les versions utilisées par votre distribution conviendront. Car dans le cas contraire, il vous faudra une sacrée dose de patience et d’huile de coude (j’ai eu le tour pour tenter d’installer le serveur Firefox Account qui repose sur node.js–Si je chope le premier gars qui a dit « tiens et si on exécutait du JavaScript côté serveur ? »…), le tout en complexifiant votre infrastructure logicielle et rendant plus difficile sa maintenance.

Le cas d’HHVM est symptomatique de cette situation. Je vous laisse lire la page du Wiki pour la compilation sous Debian. Vous devez commencer par installer une armée de paquets (j’en ai compté 70 pour la première « passe »), qui auront peut-être en plus des dépendances, afin de compiler une nouvelle version du compilateur GCC lui-même (la version Debian est « trop vieille »), ainsi qu’un outil Google externe (dont la doc HHVM renvoie encore vers Google Code, qui doit fermer à la fin de l’année). Ensuite seulement, vous pouvez envisager de compiler HHVM. J’espère que vous savez croiser les doigts de pieds en plus des mains, sans parler du temps que ça prend. Et une fois compilé, il faut l’intégrer dans l’architecture et le paramétrer, bref, une montagne de boulot.

Et Docker… C’est beau, à la mode, simple, « puissant », mais qui vous dit que l’image que vous téléchargez est propre ? Comment s’assurer que l’image Docker pour une version d’Ubuntu (très populaire) est strictement identique à une installation en dur ? Comment maintenir une telle image à jour de manière sécurisée ? La critique est la même pour les images toutes prêtes de machines virtuelles. Les admins « pressés » iront chercher au plus simple, et finiront par récupérer certes un outil « tout prêt », mais sans avoir la recette de cuisine pour la reproduire et la « valider ». Une très bonne façon de montrer comment s’éloigner de l’esprit du Logiciel Libre (toujours avoir la recette, la source).

Photo : XKCD

9 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
La Mangouste
La Mangouste
17/04/2015 11:48

Merci pour cet article, enrichissant comme bien souvent. Je ne vais pas parler de ce que je ne connais pas (hadoop), mais en ce qui concerne Docker, je trouve la critique un peu acerbe. L’outil en lui même permet une certaine sécurité, offerte par l’utilisation des namespaces qui « cloisonnent » les ressources du conteneur. Quant aux sources utilisée pour le conteneur, de nombreuses distributions et outils publient officiellement des sources pour Docker. On se retrouve confronté au même problème de confiance que lorsqu’on récupère des dépendances ou des binaires (signés ou pas) ; il faut faire confiance à un moment ou… Lire la suite »

Cascador
Cascador
18/04/2015 08:00
Répondre à  Seboss666

Salut Seboss, Je fais un effort, je tape sur Disqus lol. J’adore les réflexions sur les usages dans notre métier, c’est un article fort intéressant. En ce qui me concerne, je ne suis que peu d’accord sur ce qui a été dit concernant Docker : – Pour être parfaitement clair sur l’exemple de WordPress il faut préciser que oui l’image n’est pas fournie par Automaticc mais elle est directement fournie par Docker https://registry.hub.docker.com/_/wordpress/. Pour moi on est à la seconde marche du podium et je trouve du coup l’exemple assez mal choisi – A tout moment c’est une histoire de… Lire la suite »

Cascador
Cascador
19/04/2015 10:20

Pour info : http://www.silicon.fr/docker-engine-1-6-pense-aux-ops-et-officialise-le-client-windows-114275.html

Parmi les nouveautés (du registre 2.0), on notera le support en natif de TLS
pour garantir la sécurité des échanges de Docker Engine. Une réponse à
ceux qui critiquent la faiblesse de la sécurité de Docker.

Tcho !

Quentin ADAM
Quentin ADAM
03/09/2015 17:03

Pour amener de l’eau à ton moulin http://www.banyanops.com/blog/analyzing-docker-hub/

Loïc BLOT
03/09/2015 23:59

Je dirais qu’il faudrait peut être arrêter Linux et ces « facilités » et se concentrer sur des systèmes robustes avec qui on sait ce qu’il se passe, du genre FreeBSD par exemple et son système de ports, où tout est compilable, aucun blob inséré dans le noyau ni dans les paquets.

bohwaz
06/06/2016 08:59

Pour Opera c’est pas vrai il y a un repo, avec la clé GPG etc. : https://deb.opera.com/manual.html

Mais sinon complètement d’accord sur le fond !

Même sans docker etc. par exemple avec PHP on a Composer, un gestionnaire de paquets qui ne vérifie pas la signature des paquets… Perso j’évite de l’utiliser. En plus il y avait déjà PEAR et PECL, donc je vois pas trop ce que ça apporte.

Florent Viel
07/06/2016 12:45

Docker propose un système de signature des images, donc on peut valider ce qu’on télécharge. De plus les Dockerfile permettant de construire ces images sont la plupart de temps ouvert et disponible afin de connaître la recette pour construire tel ou tel projet.

Je vois plutôt ce billet comme un rant contre les nouvelles manières de faire, plutôt qu’une recherche sur ce qui existe.