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...
Programmer en Rust, c’est bien. Mais programmer, toujours en Rust, des générateurs de code Rust, exécutés tout juste au moment de la compilation, c’est mieux ! Voilà ce que permettent les macros, avec toujours cette efficacité redoutable à laquelle nous a habitués ce langage.
Inventé en 1989 par Tim Berners-Lee dans les bureaux du CERN et grandement inspiré par les idées du projet Xanadu conçu par Ted Nelson en 1965, le protocole HTTP, ou HyperText Transfer Protocol est probablement l’une des solutions de communication les plus utilisées sur Internet. Même si certains de ses concurrents reviennent au goût du jour, comme Gopher avec le minimaliste Gemini, HTTP reste de facto le protocole utilisé par tous les navigateurs sur le marché. En plus d’être simple, extensible et sans états, il est évolutif, ayant à son actif pas moins de 5 versions spécifiées. Bref, il était impensable de pouvoir l’ignorer plus longtemps, et encore moins acceptable de faire fi de son utilisation au sein de l’écosystème Erlang...
Continuons cette série sur les codes fantastiques avec les classes vides de C++