9,90 € TTC
p. 06 FrankenPHP : vers une nouvelle génération de serveurs PHP ?
p. 14 Gestion des releases avec JFrog Artifactory et Nexus
p. 32 Développement de macros en Rust
p. 44 Gestion des périphériques USB sous [Free|Net|Open]BSD
p. 58 Les codes fantastiques : co-vide
p. 60 Alpine.js : un framework JavaScript minimaliste
p. 68 Création d’un serveur web avec Erlang/OTP et inets httpd
Quelque chose m’inquiète (peut-être)...
Une publication sœur (MISC 131) a dernièrement publié un article fort intéressant concernant NYSM et mettant en lumière le danger que présentent des outils de post-exploitation basés sur eBPF, permettant relativement facilement à l’attaquant de dissimuler sa présence ainsi que celle des outils qu’il aura laissés derrière lui.
À la lecture de l’article, on peut naturellement se dire que ceci est relativement étrange. Pourquoi donc eBPF, ou n’importe quel mécanisme de traçage, profilage ou débogage, serait-il activé dans le kernel d’un système en production ? Après tout, la première chose que l’on fait pour un serveur bare metal n’est-elle pas de précisément recompiler un kernel parfaitement adapté au matériel et débarrassé de toutes fonctionnalités et de tous pilotes superflus, inutiles ou potentiellement contre-productifs (dangereux) ?
Il semblerait que non, en tout cas plus de nos jours, où les kernels de distribution sont tout simplement utilisés tels quel, sans autre forme de procès. On m’a même expliqué que c’était la norme et que, je cite « de toute façon, on ne peut plus attendre d’un SRE/SysOps/SysAdmin qu’il sache configurer et recompiler un noyau ». Il est vrai que lorsqu’on voit que la solution « normale » à une fuite mémoire d’un applicatif est un redémarrage récurrent du conteneur ou pod, il est évident que mon questionnement était, a posteriori, très naïf sinon stupide...
Honnêtement, je ne sais même pas si je dois en être inquiet, ou consterné ou simplement me résigner à cette réalité, en me disant que si je n’administre plus de serveurs (et ne veux plus) comme par le passé, préférant m’intéresser au code et uniquement au code, il y a de bonnes raisons. Celle-ci en est clairement une et je vous avouerai même que, quelque part, j’en arrive même à comprendre et apprécier la suppression des LKM d’OpenBSD il y a 10 ans déjà...
Denis Bodor
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...

Lancé il y a quelques semaines à peine, le projet Quarkus propose un fonctionnement révolutionnaire de Java, où son exécution ultra optimisée en fait non seulement un parfait candidat pour la conception de service de type « Serverless », mais aussi pour le déploiement sur Docker. Le projet va même encore plus loin, en proposant de transformer l’application Java en un exécutable natif ! Rapide tour d’horizon, en quelques pages et par la pratique, pour illustrer la prise en main de la technologie…
À partir de 2011, avec l’augmentation des attaques sur les autorités de certification X.509 [1], le système de vérification hiérarchique des certificats (PKIX – Public Key Infrastructure using X.509) utilisé dans TLS (Transport Layer Security) montre quelques signes de faiblesse. Un second système de vérification utilisant DNS se met alors en place, avec le protocole DANE (DNS-Based Authentication of Named Entities) [2]. Je vous propose donc de voir comment mettre en œuvre tout cela.
Nous avons vu dans l'épisode précédent comment décoder le code convolutif par algorithme de Viterbi, pour passer des symboles radiofréquences de la modulation QPSK aux bits. Nous sommes restés sur un échec de décodage, que nous allons corriger ici pour aboutir à la restitution des images issues du décodage JPEG, en passant par les diverses couches protocolaires de la liaison numérique.