Il est bien difficile de déterminer la date de naissance exacte du noyau Linux. Est-ce qu’elle se situe en avril 1991, quand Linus Torvalds a réellement commencé à travailler sur son projet de nouveau noyau ? Est‐ce le 25 août 1991, quand il a posté son célèbre message (« just a hobby, won’t be big and professional like GNU ») sur le newsgroup comp.os.minix ? Est‐ce que nous devons retenir le mois de septembre 1991 quand la version 0.01 a été déposée sur le serveur FTP de l’Université de technologie d’Helsinki ?

Quelle que soit l’option retenue, l’année 2011 marque le vingtième anniversaire de ce prodigieux projet et, pour participer aux célébrations, LinuxFr a réalisé une interview de Linus Torvalds, dont vous trouverez une traduction en seconde partie de la dépêche.

Bien entendu, je recommande vigoureusement aux anglophones de lire la version originale de l’interview qui est présente en commentaire. Linus utilise souvent des expressions idiomatiques et le « Traduttore, traditore » est plus que jamais valable !

L'honorable fail2ban semble utilisé sur de très nombreuses petites infrastructures. NdM: Fail2ban est un framework de prévention contre les intrusions, écrit en Python (Wikipédia), ou dit autrement à bloquer et bannir des pénibles. Il est diffusé sous GPLv2+.

Il était installé sur mes serveurs, avant que j'essaie de le remplacer.

Mais dis-moi, pourquoi remplacer fail2ban ?

• Parce que fail2ban est lent
• Parce que sa configuration est très désagréable et mal documentée.

Mais dis-moi, il doit bien exister une alternative ?

Avant de me lancer yeux fermés dans l'implémentation d'une alternative, j'ai fait le tour du propriétaire libre :

• sshguard est uniquement adapté à SSH.
• crowdsec semble chouette, mais adapté à des grosses infras et à des workflows compliqués. De plus, je n'ai pas réussi à l'installer.
• salt est plus un WAF (Web Application Firewall). Pareil, semble chouette mais adapté à des grosses infrastructures.
• minos, développé par Exarius (un des CHATONS), efficace mais ne supporte que les logs stockés dans des fichiers texte et le pare-feu nftables.
• pyruse, que je découvre aujourd'hui sur LinuxFr.org avec l'étiquette fail2ban. Uniquement adapté à systemd/journald.

Cri de joie, de toutes les alternatives que j'ai trouvé, fail2ban semble être encore le mieux adapté !

Andres Freund, un développeur Postgres, s’est rendu compte dans les derniers jours que xz et liblzma ont été corrompus par l’un des mainteneurs du projet. Le problème a été découvert par chance, pour la seule raison que la performance de sshd s’était dégradée sur sa machine.

L’investigation d’Andres Freund a montré que Jia Tan, co-mainteneur de xz depuis environ un an et demi, a poussé plusieurs commits contenant une porte dérobée extrêmement bien cachée au milieu d’un certain nombre de contributions valables depuis environ deux ans et demi, après avoir gagné la confiance du mainteneur historique, Lasse Collin.

Jia Tan a ensuite fait deux versions de xz, la 5.6.0 et 5.6.1, et les a poussées vers les mainteneurs de différentes distributions, comme Fedora Rawhide, Debian Unstable, Kali Linux ou encore Suse. Les contributions de Jia Tan à divers projets sont maintenant en cours de ré-analyse, car il apparaît qu’il a contribué des changements maintenant louches à d’autres projets, comme oss-fuzz, maintenant considérés comme visant probablement à cacher cette porte dérobée.

La plupart des distributions affectées sont des versions bleeding edge, et sont revenues à une version antérieure de leurs paquets xz.

Les effets de cette porte dérobée ne sont pas complètement analysés, mais les investigations existantes montrent des détournements d’appels très suspects autour des fonctions de validation des secrets d’OpenSSH.

Cet épisode rappelle une nouvelle fois combien tout l’écosystème repose sur la bonne volonté et la bonne foi de contributeur·rice·s volontaires, surchargé·e·s de travail, et peu soutenu·e·s par l’industrie utilisant leur travail.

NdM : le sujet est frais, les analyses en cours, et de nouvelles informations apparaissent encore toutes les heures. Il convient donc de rester prudent, mesuré, et surtout factuel, dans les commentaires. Merci d’avance.

Le projet Capsicum, lancé l'année dernière, tente d’adapter le modèle de sécurité par capacités (« capabilities ») aux systèmes UNIX. En deux mots, il s’agit de permettre aux applications de faire tourner certaines parties de leur code dans des « sandboxes » (bacs à sable) aux droits très restreints, gérés finement, avec la possibilité de recevoir ou de déléguer dynamiquement une partie de ces droits.

C’est une approche de la sécurité qui mise sur la flexibilité et l’intégration directe dans les applications (au contraire de politiques externes décidées par l’administrateur système, comme avec SELinux) pour respecter le Principle of Least Authority, qui recommande qu’un bout de programme donné fonctionne avec seulement les droits dont il a besoin pour accomplir sa tâche. Ainsi, les conséquences d’une faille sont réduites et les vecteurs d’attaque diminuent énormément. Par exemple, je ne veux pas que le logiciel qui lit mes fichiers PDF ait le droit de lire le contenu de mon répertoire personnel et d’envoyer des e-mails.

Capsicum introduit de nouveaux appels et objets système, qui demandent une (relativement petite) modification du noyau, ainsi qu’une bibliothèque logicielle en espace utilisateur pour utiliser ces nouveaux appels système. FreeBSD a déjà fait les modifications nécessaires, et les chercheurs ont pu facilement convertir plusieurs applications au modèle Capsicum : tcpdump, dhclient, gzip et, avec l’aide d’un développeur Google, le navigateur Web chromium.

Capsicum peut ainsi renforcer considérablement la sécurité des applications UNIX classiques, sans demander de les recoder entièrement. Reste à voir si les développeurs du monde du Libre seront convaincus par ces approches compartimentées, et prêts à les prendre en compte lors de la conception de leurs logiciels.

Basée sur un journal, cette dépêche présente les mécanismes de génération de nombres (pseudo‑)aléatoires dans le noyau Linux, et fait le point sur les principales évolutions survenues entre les versions 3.17 (en octobre 2014) et 5.6 (en mars 2020).

Deux histoires d'informatique à l'hôtel traduites en français :

1. c'est celle d'un étudiant, Gökberk Yaltıraklı, qui « aime coder, écouter de la musique et voyager » et qui nous raconte sur son blog une enquête menée lors d'un séjour à l'hôtel. Son site est http://gkbrk.com/ et nous le remercions de nous autoriser à reproduire son article traduit.
2. c'est celle d'un autre voyageur, Matthew Garrett, qui nous raconte ses découvertes dans un hôtel qui n'a, a priori, pas fini sa mutation technologique… Et nous le remercions de nous autoriser à reproduire son article traduit.

Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.

OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.

Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).

Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.

Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.

La dernière dépêche de cette catégorie LinuxFr.org qui ne soit pas une dépêche récurrente type « Les meilleurs journaux du mois » ou « Les prix du mois » ou « Les statistiques de l'année » remonte à mai 2014 pour une mise à jour du serveur. Voici donc, à l'aube de l'été, quelques actualités de type « en coulisses ».