benoar a écrit 4238 commentaires

et plein d'autres petits trucs.

Ho, t'aurais pas du me lancer là-dessus : donc maintenant on a systemd dans l'initrd (!), une réinvention des user/group Unix avec un langage de définition tout nouveau et du contenu en JSON, l'intégration future de ce dernier bidule à sssd et LDAP, les homes dont on parlait, et du multi-instance pour le gestionnaire afin de palier à ses perf merdiques (que j'ai déjà constaté pour de vrai). Bon, je n'ai extrait que les trucs qui me déplaisent, il n'y a pas que ça, mais c'est un beau florilège je trouve.

En fait, il y a tout un paquet de modalités spécifiques à systemd qui dupliquent ce qui existait déjà avant. Faudrait que je fasse un jour un journal sur la philosophie « avec le moins de modalité possible » adoptée par Unix et Internet (l'IETF) : j'ai l'impression que ça n'est vraiment pas compris par beaucoup de monde. (il y a des critiques légitimes à ce modèle, mais je le trouve quand même vastement supérieur à ce machin de systemd)

La spécificité d'HTTP, c'est de s'être largement fossilisé sur les couches basses, et de n'avoir pas su évoluer alors que le courrier électronique s'est adapté aux services multiples avec les enregistrements MX, et plein d'autres protocoles avec des enregistrements SRV.

D'ailleurs je jetais un œil régulièrement au bug proposant l'amélioration de Firefox en lui ajoutant le support des SRV, et il a été fermé l'année dernière (WONTFIX), après vingt ans d'existence ! https://bugzilla.mozilla.org/show_bug.cgi?id=14328
La justification, après avoir eu moult débats et propositions de patchs jamais intégrés ? « Il n'y a pas de use-case utilisateur en vue, en particulier au vu de la migration vers les web-extension » : bref, le passage à la guillotine des web-extension pour justifier n'importe quoi. Le web vraiment décentralisé n'aura pas lieu.

Faut arrêter avec la sécurité à tout crin : la plupart des technos à la con (selon moi) modernes qui ont « innové » niveau sécurité sont pour des modèles de menaces qui ne me concernent absolument pas. Tu te pignoles peut-être sur l'evil maid, mais je pense que c'est parce que les mecs qui ont développé tous ces trucs ont des melons énormes et kiffent s'imaginer en rebel recherché par la CIA. Ça n'est pas mon cas, désolé.

Putain c'est même pas une blague : https://wiki.archlinux.org/index.php/Systemd-homed

Les téléphones portables ont toutes les fonctionnalités nécessaires pour qu'ils ne dérangent pas. De la même façon qu'on ne peut pas te contraindre à exécuter les JS de Taboola dans ton navigateur, le téléphone portable est ton outil.

L'important n'est pas ce qu'on peut faire (tout ordinateur est une machine généraliste qui peut tout faire), mais ce que font les gens en général : les réglages par défaut. Et j'observe que la majorité des gens transportent le dérangement en permanences, et s'attendent à ce que tout le monde fasse pareil, comme dit Tanguy (pareil pour Taboola). Bref, argument fallacieux.

Perso j'utilise toujours une souris à boule de 1996, et je lui fais un petit nettoyage tous les mois ou deux mois environ, ça suffit : c'est pas la mort. Elle a eu droit à de nouveaux contacteurs (boutons), par contre.

Oui, moi aussi. Pôle-Emploi incite fortement à aller sur LinkedIn, mais sur ce réseau je suis traité de robot et ne peut y accéder… bientôt l'exclusion sera sévère.

il ne devrait pas y avoir d'analyse comportementale sur la page d'informations.

Je sais pas si t'es au courant, mais les dernières start-up à la mode pour le paiement en ligne sont justement celles qui ne nécessitent rien d'autre qu'une analyse de comportement pour valider le paiement ! Je n'ai pas de lien sous la main, mais de mémoire Google y travaille également. Plus besoin de login ou de mdp, juste du JS partout pour t'analyser et t'identifier sans que tu ne t'en rendes compte ! Elle est pas belle la vie ?

Effectivement, c'est très important comme différence. Il y a quelques jours, j'ai vu Jancovici qui disait que quels que soient les moyens qu'on mette (ou pas) pour contrer le changement climatique, les températures des 20 prochaines années sont déjà déterminées à l'avance à cause de l'inertie de tous les systèmes de la Terre. Donc il faut en plus avoir des gens prêts à sacrifier beaucoup, sur une durée longue, sans même pouvoir observer de résultat positif à échéance « normale » (quasiment une génération sans voir de résultat, c'est énorme). Et encore, ça sera tout juste le début d'un vague changement de tendance.

Un Thinkpad parce qu'il n'y a que ça de vrai, série « T » pour du pro en taille raisonnable (14") (sinon « X » pour du réduit, mais va disparaître), et maintenant ils font de l'AMD donc T495 :
https://www.lenovo.com/fr/fr/laptops/thinkpad/t-series/T495/p/22TP2TTT495

La batterie n'est pas « amovible » au sens classique, mais se remplace si tu sais enlever quelques vis. Pour les deux disques, il y a potentiellement deux M.2, mais le second est un court donc ça va être galère. Et par contre, Windows obligatoire…

Vous avez tous les deux raison : je pense que NeoX parle de GPT, et toi d'UEFI :-)

Un doute m'est venu juste après avoir posté ce commentaire : existerait-il un module gitlab à weboob, afin de boucler la boucle ? Apparemment non. Ça aurait été méta-drôle, même si j'aurais plutôt ri méta-jaune.

J'arrive après la bataille, mais je voulais lancer un petit troll relatif au cœur du projet : on ma demandé de relancer un patch que j'avais proposé sur la ML (assez morte, par ailleurs) par le gitlab de weboob, sur https://git.weboob.org/
Et là je me suis dit « Comment ? Les devs de weboob osent demander de passer par le web afin de contribuer à ”web out of browser” ? ». Du coup ça m'a fait une excuse pourrie pour ne pas rebaser le patch et reporter le boulot à plus tard /o\

Intéressant comme méthode, mais ta création de partition en masse m'a tout de suite fait penser à plutôt utiliser le device mapper, cf man dmsetup(8).

Tu laisses ton disque non-partitionné, et tu crées un fichier qui contient la « table » des morceaux de disque que tu veux agréger dans un nouveau device, selon la syntaxe indiquée dans le manuel :

0 900000 linear /dev/sda 4100000
0 900000 linear /dev/sda 5100000
…

Ensuite tu crées le device :

dmsetup create disque_aggrege --table ma_table.txt
Sache que le Device Mapper est le mécanisme « bas-niveau » utilisé par lvm et dmraid (entre autres), c'est donc du « classique » mais que tu fais ici à la mano ! Par contre j'ai un petit doute sur l'imbrication de device (vu que tu va créer des mapping avec LVM sur ce device qui est déjà un aggrégat de mapping linéaire), mais je pense que ça passe normalement.

Si tu veux voir comment ça fait avec tes devices LVM actuels, histoire de comprendre :

dmsetup ls
dmsetup table mon_device


Ah, je ne savais pas pour les extensions.

Par contre, ton VirtualGL c'est autre chose : c'est utiliser l'accélération du client X11 pour envoyer des frames déjà rendues sur le client au serveur X11. Après, l'argument qu'ils avancent de la non-efficacité de faire de l'OpenGL à distance est peut-être vrai, mais du coup s'applique (de ce que je comprends) également à waypipe avec accélération 3D.

genre la 3D que propose simplement waypipe avec DMABUF.

X11 peut forwarder l'OpenGL sur le réseau depuis 20 ans à peu près…

Et en plus avec des bières, dans des bouteilles en verre ! C'est « hallucinant » d'une certaine manière, mais tellement humain en vrai.

Je ne suis pas sûr qu'on se soit bien compris, mais :

Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.

Si tu parles bien d'utiliser sa propre infrastructure qu'on maîtrise pour le triplage de la facture, oui effectivement ça n'est pas un choix facile. On ne peut malheureusement pas tout avoir.

Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.

Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).

Après, une attaque « via des logiciels établis » est toujours possible, mais on commence encore une fois selon moi à entrer dans des probabilités tellement basses que la question du compromis tiens toujours : je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.

Si tu as un master 2 ou un DESS, ta formation est aussi sérieuse et complète que celle d'un ingénieur

Peut-être pour certaines écoles d'ingé, plutôt privées comme tu l'indiques, mais j'ai « comparé » avec des gens que je connais bien issus d'école publiques renommées, et pour moi il y a quand même quelque-chose « en plus » avec celles-ci (INSA en l'occurence). Ou alors c'était ma fac qui n'était pas géniale…

Bon après il y a également l'effet réseau professionnel qui te permet « automatiquement » d'avoir des postes mieux après de bonnes écoles d'ingé, mais ça ça n'est pas très reluisant.

Le moindre pilote client de base de données ou wrapper Vagrant (et on va pas parler de Docker, KVM, XEN et co.) peuvent potentiellement permettre un nouveau vecteur d'attaque. Il doit pas y avoir grand monde avec le temps, les compétences et la volonté de "maitriser son informatique" à ce point.

À une époque, on ne filait pas un gros blob binaire construit spécifiquement pour une utilisation aux gens : on précisait des dépendances « standard », qui pouvaient même être intégrées à un système de gestion de paquet, on avait des soft qui s'adaptaient à des environnement un peu hétérogènes histoire de pouvoir tourner sur les environnements différents existant chez chacun, et on utilisait des formats et protocoles standards.

Aujourd'hui, on fait des images toutes prêtes qui incluent toutes les dépendances figées et inauditables, intégrées dans des systèmes ni signés et peu reproductibles, avec des softs qui ne tolèrent aucune souplesse et sont dans la monoculture, en utilisant des API propres à chaque appli et sans format standard définit.

L'industrie a bien changé en dix ans, oui. Je ne dis pas que le premier modèle n'a pas de désavantages (déploiement plus complexe, moindre rapidité d'évolution radicale, scalabilité plus manuelle), mais au moins niveau maîtrise, fiabilité et insensibilité à ce genre de bug on était beaucoup mieux lotis. Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien contre des petits avantages de praticité qui — en rétrospective — ne valent peut-être pas tant que ça le coup. Même si chacun aura un avis différent sur le côté duquel penche le compromis pour lui.

Perso j'ai choisi Debian, ça n'est pas un choix irréaliste : c'est reproductible, signé, auditable, standard, etc. Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.

Il y a un exploit Meltdown/Spectre qui permet de récupérer l’intégralité de la RAM, en quelques minutes, sans aucun log.

Ça a été montré pour un cas spécifique, mais perso je n'ai pas pu le reproduire, et d'autres personnes me l'ont également confirmé. C'était au début, ça s'est peut-être amélioré depuis, mais on reste sur des méthodes probabilistes qui dépendent d'un alignement de bonnes étoiles (même si oui, ça peut arriver).

Bah vas-y, donne nous tes astuces et bonnes pratiques, on attend que ça.

Ça se fait pas en un commentaire, et je ne suis pas un méga-spécialiste qui pourrait se permettre de lister ça sereinement. Ce que je veux dire, c'est que la publicité faite sur ces failles occulte un tas d'autres choses qui sont plus importantes, c'est tout.

tu fais tourner tous tes processus en root.

Pas ceux des utilisateurs déjà, puisque l'utilisation des droits est déjà une barrière pour les problèmes humains, qui par définition ne sont pas contrôlable par un admin comme les programmes qui tournent sur sa machine.

Pour les démons, effectivement on met une protection en plus à priori « pas nécessaire » que je trouve déloyal de comparer à cette faille-ci : je pense qu'il y a beaucoup plus de probabilité qu'arrive une RCE qui ne sera pas exploitable pour éscalader les droits que quelqu'un vienne te faire un cacheout sur des secrets spécifiques pour arriver à ses fins. Faire tourner des démons avec des droits distincts, c'est relativement simple, n'a pas d'impact de perf, et te protège de beaucoup de choses. Ici, c'est chiant à mettre en place, pour un gain vraiment très faible. C'est la différence que je fait.

Globalement, avec ce genre de faille, ça veut dire qu'à la moindre RCE, tu bypass les protections du système […] et qui installe un malware dans le bios/uefi

La probabilité que ça arrive est à mon avis assez faible. Mais bon, c'est juste mon avis.

En fait, on ne fait aucune pub pour toutes les bonnes pratiques autres qui sont beaucoup plus logiques et simples à appliquer, et on passe son temps à parler des ces trucs hyper techniques qui ont des probabilité de fonctionner tellement faible que ça en est ridicule. Ça fait parler de Intel, et du bad buzz c'est quand même du buzz, et on donne une attention complètement disproportionnée à ce genre de problème. Ça entraînera forcément une négligence sur d'autres aspects qui auraient pu être beaucoup plus constructifs.

Tu as l'air de dire que tout le monde doit maîtriser à mort son infra.

J'aimerais, mais je sais bien que ça n'est pas possible. Et à ce moment-là, comme le dit kowalsky, tu as bien d'autres problèmes plus prioritaires à te soucier que ces failles.

se connecter sur une de tes machines via un compte non privilégié, il peut utiliser cette faille --> ta super maîtrise est par terre.

Je suis d'accord qu'il faut avoir plusieurs niveaux de protection, mais franchement il y aura à mon avis plus simple que cette faille pour arriver à tes fins dans ce cas-là. On fait tout un foin sur cette histoire, alors que plein de gens font tourner des tas de containers pas à jours avec aucun suivi de CVE. Tu veux essayer de « mitiger » après avec ta super protection anti-Cacheout ? Ton ordre des priorités est vraiment étrange, selon moi.

Encore une fois, il faut voir dans quel contexte c'est exploitable : pour des gens qui font tourner du code malveillant utilisant les instructions TSX. Qui fait ça ? Ceux qui installent du code venu de n'importe où, sans vérifier. Vous étonnez-vous qu'après il y ait des problèmes ?

Ça affecte aussi ceux qui sont collocalisés sur des hyperviseurs avec des VMs adjacentes malveillantes : déjà, les chercheurs qui ont trouvé la faille indiquent avoir déjà prévenu les fournisseurs de cloud (ils ne précisent pas lesquels, comme si c'était évident qu'il n'y en ait que quelques gros…), et puis quand vous faites tourner votre code sur la machine de quelqu'un d'autre, vous étonnez-vous que vos données puissent éventuellement fuiter ?

Pour une fois, je ne vais pas râler sur l'utilisation à outrance de codes inconnus dans un browser par Javascript puisque cette faille-ci nécessite l'utilisation d'instructions TSX, qui ne sont pas accessibles en JS.

Bref, cette attaque est encore une fois très spécifique, et n'affecteront jamais des personnes qui utilisent uniquement du logiciel libre et maîtrisent leur informatique. Si vous utilisez du logiciel privateur ou faites tourner votre code sur la machine de quelqu'un d'autre, il y a bien d'autres « problèmes de sécurité » à vous soucier avant ce genre de faille ! Cf. ce que j'avais déjà dit ici.

Alors après c'est techniquement très intéressant à lire, merci patrick_g ! Et je ne suis pas un pro-Intel du tout, bien au contraire, je trouve que c'est « bien fait » pour eux qui ont toujours utilisé des méthodes très limite pour imposer leur mainmise sur l'industrie. Mais franchement, l'impact réel du truc… Ah si, ça permettra d'avoir des CPU Intel puissants pas cher d'occasion pour ceux qui n'utilisent que du libre !

Moi. Master universitaire, même si j'ai essayé d'entrer avant en école d'ingé mais n'ai jamais réussi. Comme Sébastien, tu as toujours légèrement l'impression d'être un usurpateur, mais avec l'expérience je me dis que « je compense ». Mais c'est vrai que la validation d'acquis m'avait toujours titillé : cependant, vu le long parcours (très bien rapporté !) il faut vraiment le vouloir…