Maintenant, comment faire pour donner accès à internet à une machine qui a une IP non routable ? C'est simple : on utilise un proxy qui lui aura une IP routable dans une plage réseau dédiée. C'est lui qui relaiera les paquets vers "le méchant ninternet"
Je ferais plutôt une entrée firewall dédiée à ca, en ipv6 comme en ipv4 (avec un nat en plus si besoin est). Les proxy web sont beaucoup moins intéressants qu'ils en ont l'air :
- C'est de la configuration client, rien n'empêche un client de ne pas utiliser de proxy pour faire ses requêtes, à par les règles du firewall réseau
- Au niveau des logs firewall, l'origine des flux visible est le proxy et non le client réel. Ca masque une partie des infos et rend pénible le débug ou l'analyse de flux
- Faut un proxy qui tienne la charge pour pas devenir un goulot d'étranglement. Ce problème s'applique aussi au firewall, mais il n'est pas vraiment utile de les multiplier dans le LAN, il y en a déjà assez dans le WAN.
- Leur plus gros usage en entreprise, c'est les règles de sécurités, qui servent en gros à filtrer des catégories de domaines. Déjà les URL ne sont pas toujours catégorisées de facon cohérentes, même sur de grosses solutions, d'autres part en télétravail, soit y a pas de VPN et donc pas de proxy obligatoire (un client peut toujours désactiver la conf proxy), soit il a un VPN, qui souvent a un beau split-tunnel configuré/configurable par le client pour le trafic web, et donc faire comme si il n'y avait pas de VPN.
En fait, les proxy web sont intéressants surtout dans certains cas particuliers.
Taper brutalement la tranche d'un disque dur sur une surface solide a été une vraie technique de sioux pour réparer temporairement certaines pannes. En bonus, parait qu'en plus de ranger les données, ca les compresse.
Arch est un classique, qui avec ses dérivés (comme Manjaro) a quand même l'air assez présent pourtant, avec des communautés actives.
Après, que les distros blending edges soient en recul par rapport aux desktops plus simples me parait être un bon signe, ca montre une certaine démocratisation de Linux (assez relative vu les données de statscounter).
Le gros buzzword du moment c'est l'IA, avec tout les marketeux qui essayent d'en mettre partout, surtout quand ca sert à rien, et sans trop savoir ce qu'ils font. Du coup on peut dire que le web 4.0 n'est déjà plus le web des mondes virtuels, mais plutôt celui de l'IA ?
"[…] la prochaine génération, le web 4.0, permettra une intégration entre les objets et environnements numériques et réels, ainsi qu'une amélioration des interactions entre l'homme et les machines."
On parle de ca du coup ?
Donc en gros, la définition du Web 4.0, c'est un ensemble de techno propriétaires auxquelles seuls certains acteurs peuvent participer en fonction de la taille du compte bancaire ?
Bon, plus sérieusement, je trouve que la définition du Web 4.0 est exactement la même que celle du Web 3.0 autour de 2005 quand on parlait de web 3D avec le légendaire VRML.
20 ans d'évolutions du web, pour réinventer les mêmes concepts au niveau institutionnel, mais en perdant le côté libre au passage.
Pour les dépôts customs, je parle de dépôts de .deb, pas de l'appstore snap. Tu peux toujours personnaliser ton /etc/apt/source.list.d, ca un dérivé de Debian. Tu peux d'ailleurs t'amuser à mettre les dépôts Debian et virer ceux de Canonical, t'amuser à réinstaller entièrement le système "in-place" et te retrouver avec un Debian à la place, c'est toujours techniquement possible.
Bah non parce qu’à tout moment ils pourraient être hébergés ailleurs. Surtout avec Git, qui rend la chose triviale. Alors oui c’est sûr, les issues, la CI, qui sont lié à Github et pas purement Git, non. Mais le code source oui et c’est ce qui compte le plus. Et même pour la CI, ce qui aura été mis en place pour GitHub ne sera clairement pas à jeter totalement pour migrer ailleurs, même si en effet c’est du taf.
Du coup c'est aussi le cas pour les snaps (du moins ceux de logiciels libres). Le code source étant libre, rien n'empêche de le récupérer, le build localement, générer un deb et l'installer avec un bon vieux dpkg. Et à tout moment, on peut virer l'intégration des snaps du système, et rajouter des dépôts pour avoir les .deb qu'on souhaite.
Avec ton explication sur en quoi dépendre de Github n'est pas un problème pour une distribution, je ne comprends pas en quoi l'intégration de snap dans Ubuntu en fait une distribution propriétaire. On est pas dans la situation d'un Windows update, qui est impossible à retirer de Windows (ou alors de facon non documenté), et distribuant des mises à jours obscures. Ca reste un composant qu'on peut retirer, la procédure est documenté officiellement, on peut toujours rajouter des dépôts customs, et les composants logiciels distribués ne sont pas obscures. On peut même toujours s'amuser à transformer son Ubuntu en Debian, il n'y a aucun verrouillage fait à ce niveau là (faut juste savoir utiliser apt/dpkg).
parce que je m'attends à ce que le gestionnaire de paquet m'avertisse au préalable si ça va tout casser.
J'ai pas ca sous Arch, FreeBSD ou même une Debian un peu ancienne, ce n'est pas une feature obligatoire d'un gestionnaire de paquets.
D'ailleurs sur des Debian 12, j'ai rencontré le cas où enlever un paquet propre de la distribution supprime la moitié de l'OS, sans avoir de gros message disant que ca va tout casser. Pourtant l'environnement en question est considéré comme un de ceux qui garantisse le plus la sécurité et la vie privée de l'utilisateur (si bien utilisé).
Mais du coup, une distribution reste dépendante aux dépôts logiciels ou miroirs qui sont configurés dedans. Qui sont dans 99% des cas hors de portées des utilisateurs.
Pire encore, pour accéder à ces dépôts, les distributions sont dépendantes de serveurs DNS externes (même si on a son propre résolveur DNS local, il est soit récursif ou forwarder, donc transmet les requêtes à l'extérieur), aux infras de FAI, etc. Du coup il y a toujours une dépendance à des services hors de contrôle de l'utilisateur.
Je suis entièrement d'accord avec toi sur le fait que dans tout les cas, peut importe les licences, les services en dehors du contrôle de l'utilisateur, et c'est bien là un de mes propos. Cette dépendance ne rend pas les distributions moins libres, du coup pourquoi dans ce cas, cette intégration de Snap rend Ubuntu non-libre ?
Sachant qu'une grosse partie des LL sont disponibles uniquement via Github, tu es du coup quand même dépendant d'un service propriétaire, même pour télécharger les tar.gz ou les codes sources. Est-ce que à cause de cette dépendance obligatoire à Github ces logiciels sont non-libres du coup ?
Par contre elles permettent quasiment toutes de changer ce serveur et même de s'en faire un en local.
Les données des miroirs proviennent soit de d'autres miroirs, soit des dépôts officiels de la distribution. Dans le cas (improbable, certes) où les dépôts officiels tournent sous IIS, peu importe l'existence de d'autres miroirs, la distribution reste dépendante de serveurs proprio. Est-elle non libre dans ce cas ?
Je ne sais pas trop. Nos distributions préférées sont dépendantes de leurs serveurs de dépôts. Rien n'indique que ce ne soient pas des Windows servers + IIS. Ca n'en fait pas pour autant des distributions non-libres.
De même, il y a un sacré nombre de projets libres dont le centre de distribution initial est uniquement Github, ce qui les rend dans une certaine mesure dépendant de cette plateforme. Est-ce que ca en fait des logiciels proprio du coup ?
Ou alors qu'est-ce qui empêche de virer Snap d'Ubuntu et de l'utiliser juste avec ses dépôts ? Ca fait plus de 10 ans que je n'ai pas utilisé Ubuntu, j'ai surement raté 2-3 trucs, mais il me semble qu'ils ont toujours des dépôts et que ca reste une distribution Gnu/Linux/Systemd. Du coup le fonctionnement d'une Ubuntu n'est pas dépendante de la présence un gestionnaire de Snap.
Bah apparemment, d'après certains par ici, fournir une stack logiciel libre avec un ou 2 composants proprio facultatif, c'est faire de l'openwashing (genre ici par exemple).
Posté par Astaoth .
En réponse au journal snap : de pire en pire..
Évalué à -7 (+5/-14).
Dernière modification le 28 janvier 2024 à 11:21.
Est-ce que tu crois 1s qu'il y a quelqu'un qui travaille en se satisfaisant de te pourrir la vie ?
Franchement, parfois la question se pose. Quand on voit le nombre de bugs qu'on peut rencontrer en 15 min d'utilisation de Plasma ou le nombre d'utilisateurs qui n'arrivent pas à quitter Vi …
Le TPM gére le démarrage d'un PC, utiliser une carte à puce sur un raspberry pi n'en fait pas un TPM.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Un PC et un programme ne sont pas du tout déterministes.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
La vitesse d’exécution s'ajuste selon la température et la charge, ces petits changements entrainent aussi des modifications d'utilisation des caches ce qui augmentent encore les différences. A voir si ces métriques sont encore utilisés, mais il était surtout question de hash et de signature.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
A l'origine, la root key du TPM ne devait pas être sous le contrôle de l'utilisateur.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
La spécification TPM proposait de vérifier toutes la chaines d’exécution et pas seulement le boot.
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
"Cory Doctorow, né le 17 juillet 1971 à Toronto en Ontario, est un blogueur, journaliste et auteur de science-fiction canado-britannique."
Je ne vois pas de bagage technique dans son CV, du coup je doute de la pertinence d'utiliser ses propos comme référence sur un sujet assez technique et méconnu. En particulier quand il compare la TPM à un composant de vaisseau interstellaire qui mène à l'explosion de celui-ci, dans un film de science-fiction.
La TPM n'est toujours pas une techno de surveillance comme tu le sous-entends. C'est une réponse à "l'evil maid attack", la seule possible à l'heure actuelle. Je t'encourage très fortement à lire la page wikipedia à son sujet.
En dehors d'une surveillance permanente de l'équipement, les seules facons de contrecarrer cette attaque, et donc toute modification de la chaine de boot qui ne peut pas être chiffré sur un volume LUKS c'est de signer les composants logiciels, et de mesurer leurs temps d'exécutions. Un PC et un programme étant déterministes, tant que le bootloader n'est pas modifié, la durée d'exécution de chacune de ses étapes doivent être strictement identique d'un boot à l'autre. Un changement de durée d'exécution indique une modification du bootloader. Contrairement à ce qu'a écrit ton auteur de SF préférée, la TPM ne surveille pas l'ensemble des logiciels qui tournent sur le PC, mais uniquement ceux de la phase de boot, quand le SecureBoot est actif.
La TPM ne serait une technologie de surveillance de l'utilisateur que si ses fonctionnalités ne pouvaient pas être désactivées (et on peut allègrement passer outre la TPM en désactivant le secure boot, encore une fois), si elle stockait les infos de chaque boot (c'est pas le cas, elle compare les durées d'exécutions et des signatures seulement, sans plus, et je doute un peu qu'elle ait les capacités de stockage pour stocker les données de tout les boots d'un PC), et si elle transmettait ces informations à des acteurs extérieurs (c'est toujours pas le cas, la TPM n'a pas de stack réseau). Et avant de faire un lien bancale entre la TPM et l'UEFI, il est totalement possible de trouver des TPM externe, qu'on utiliserait sur un raspi qui n'a pas d'UEFI. L'hypothèse que la TPM a été créé comme un dispositif de surveillance de l'utilisateur est donc erronée. Mais tout ceci n'a toujours aucun rapport avec l'attaque de l'article de Ars Technicas.
l’implémentation matériel d’un logiciel tournant hors de portée des utilisateur
Même un firmware de hardware libre reste hors de porté de l'utilisateur, en particulier de ceux n'ayant aucun bagage technique. Mais si les firmwares qui proposent des interfaces standardisés par des normes ISO pour les OS et drivers n'existaient pas, l'utopie d'avoir des OS indépendants de grosses sociétées resterait une fiction. Pour en avoir une vague idée, souvenons-nous de la sombre époque de ndiswrapper pour le wifi, et imaginons un seul instant être dans la même situation pour l'accès aux volumes de stockages par exemple.
Mon expression reste toujours aussi médiocre. Pour comprendre il vaudra mieux lire l’article. Permettez-moi d’ajouter que, par ailleurs, je n’ai pas de connaissances importantes en matière de firmware, et que donc mon propos ne fait que rapporter celui d’autrui. Mon jugement technique n’a que peu de valeur dans le domaine que nous discutons.
Au vu du contenu de son article, c'est également le cas de Cory Doctorow. Le problème est qu'il a pris des morceaux d'info ici et là, sans vraiment les comprendre, et au lieu de creuser le sujet, il les a assemblé à la facon d'un blogueur, journaliste et auteur de science-fiction. Malheureusement pour lui, nous ne sommes pas dans un roman de science-fiction, la TPM n'a pas les buts et fonctionnalités qu'il décrit, et les scénarios catastrophes qu'il mentionne restent … de la fiction.
Renseigne-toi vraiment sur ce qu'est une TPM, mets en place un secure boot, et testes les scénarios catastrophe de ton auteur préféré (lorsque possible) pour voir si ils sont réalistes ou non (par exemple, essaye d'avoir un ad-blocker dans ton navigateur web et vois si la TPM t'en empêche avec un secure boot actif).
Je ne suis pas sûr de comprendre le rapport entre l'attaque découverte et le contenu du journal.
L'attaque exploite une chaine de vulnérabilité sur les boots PXE et l'IPv6 de l'UEFI. Je ne suis pas sûr de comprendre le rapport avec les TPM du coup.
D'après Wikipedia, "Trusted Platform Module (TPM) was conceived by a computer industry consortium called Trusted Computing Group (TCG)." et "Members include Intel, AMD, IBM, Microsoft, and Cisco.". Du coup les TPM n'ont pas été créées juste par Microsoft.
Les TPM en tant que telles ne servent qu'à stocker des clefs et signatures cryptographiques, et il est totalement possible de les effacer et d'y mettre les siennes. C'est long et pénible, mais faisable sous le contrôle de l'utilisateur qui souhaite avoir son propre set de clefs et signatures. Si l'utilisateur ne veut pas s'embêter avec ca, il peut aussi juste désactiver le Secure Boot, comme à l'époque des BIOS. Du coup je ne vois pas trop le rapport avec les DRM.
Le journal fait mention de dispositifs de surveillance dans les ordis modernes après avoir parlé d'UEFI, de TPM et de cette nouvelle attaque.
Pour rappel, les TPM et UEFI n'ont rien à voir avec des dispositifs de surveillance. La fonction d'une TPM est de répondre à ce problème très bête et très dur à résoudre de "l'evil maid attack".
L'UEFI a été créé pour remplacer un BIOS vieillissant (il me semble que, un compatible-PC, à l'étape du BIOS, émule littéralement un IBM PC d'il y a 40 ans ; ca devient un peu long de compter quelques dizaines de Go de RAM pendant un POST), dont les mises à jours sont plus que scabreuses (en cas de plantage d'une maj, il faut remplacer la puce du BIOS par une nouvelle, flashée avec le firmware), et créé à une époque où les besoins en sécurités étaient différents.
Les buts et fonctionnalités initiales de l'UEFI sont plus ou moins les mêmes que celui des BIOS : être une interface basique d'exploitation du matériel et lancer le bootloader. Bien évidement qu'un UEFI peut exploiter le matériel, exactement de la même facon q'un BIOS peut le faire. D'ailleurs les boots PXE ne sont pas apparu avec les UEFI, donc rien ne dit que cette attaque n'existait pas avec les BIOS, mais n'a pas été découverte officiellement. On a d'ailleurs pas attendu les UEFI pour trouver des attaques sur les firmwares, je me souviens d'une histoire de disques durs d'il y a quelques années à ce sujet.
Ce journal parle enfin d'éthique sur les firmwares, et semble sous-entendre que les UEFI ne sont pas éthiques. Au vu de l'évolution de la recherche en sécurité durant la dernière décade, et des fonctions très similaires entre les BIOS et UEFI, est-ce que l'absence d'attaque connue de ce type sur les BIOS implique nécessairement leur impossibilité ? Et quel rapport avec l'éthique en fait ?
Pour rappel, la chaine de vulnérabilité nécessaire à cette attaque est disponible sur au moins un UEFI open-source, l'implémentation de référence d'Intel (sous licence BSD). Si j'ai bien compris la page wikipedia de EDK II (l'UEFI de Intel), il fait maintenant parti de Coreboot, la stack libre visant à remplacer les BIOS et UEFI. Mais peut-être que Coreboot n'est pas un projet éthique dans son principe ? D'ailleurs, serait-il plus éthique de ne pas avoir un firmware s'occupant de l'initialisation du matériel, du lancement du bootloader et présentant une interface standardisé du matériel à l'OS, et donc de devoir dépendre du bon vouloir des fabriquant de cartes mères ?
Et enfin, cette attaque nécessite une chaine de vulnérabilité assez importante (9 vulnérabilités du coup), et a comme pré-requis d'avoir le PXE actif, et peut-être aussi de l'IPv6 (sur certains UEFI, on peut choisir d'avoir du PXE uniquement en v4 ou v6). Cette vulnérabilité semble donc assez simple à mitiguer pour un particulier. Pour les UEFI virtuels, une mise à jour de l'hyperviseur corrigera les vulnérabilités ; pour les UEFI matériels, une mise à jour, faisable depuis l'OS pourra également bloquer l'attaque. Avec un BIOS, ce genre de patch serait beaucoup plus pénible à appliquer sur les environnements physiques, car il ne pourrait se faire que manuellement, en démarrant non pas l'OS mais directement le firmware de màj du BIOS, avec toujours le risque que si la màj se vautre, il faut remplacer la carte mère.
En conclusion, je trouve qu'utiliser un article sur une attaque d'un composant matériel pour dire que celui-ci ainsi qu'un autre composant matériel (pas impacté par l'attaque) sont des techno de surveillance, voir des backdoors, c'est assez peu éthique je trouve.
Ca concerne toutes les implémentation d'UEFI ayant ces vulnérabilités.
"The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft.".
J'imagine qu'on peut supposer qu'un UEFI open source peut largement être utilisé dans le monde de l'hypervision, et notamment des hyperviseurs open-sources.
Une de ces fameuses caméras qui se retrouve en ligne après ?
NB : ce site ne recense aucune caméra situé à l'intérieur d'un appartement normalement, mais d'autres le font. C'est d'ailleurs très amusant de faire aboyer une caméra dans un commerce.
Avec le Thinkpad E15 du boulot sous W10, j'étais obligé de le débrancher le soir, sinon il s'allumait pendant la nuit, pour installer des mises à jours que finalement il n'installait pas, et rester allumer toute la nuit. Au matin, j'avais largement de quoi tenir toute la matinée sans problème.
Sous QubesOS (pas réputé avoir la meilleure gestion énergétique et l’hibernation est impossible avec), je peux laisser l'ordi en veille toute la nuit, j'aurais quand même de la batterie le lendemain, sur un Dell avec un Intel gen10.
[^] # Re: IPv6 en réseau local
Posté par Astaoth . En réponse au journal IPv6, cela en valait-il la peine ?. Évalué à 2 (+0/-0). Dernière modification le 23 avril 2024 à 01:04.
Je ferais plutôt une entrée firewall dédiée à ca, en ipv6 comme en ipv4 (avec un nat en plus si besoin est). Les proxy web sont beaucoup moins intéressants qu'ils en ont l'air :
- C'est de la configuration client, rien n'empêche un client de ne pas utiliser de proxy pour faire ses requêtes, à par les règles du firewall réseau
- Au niveau des logs firewall, l'origine des flux visible est le proxy et non le client réel. Ca masque une partie des infos et rend pénible le débug ou l'analyse de flux
- Faut un proxy qui tienne la charge pour pas devenir un goulot d'étranglement. Ce problème s'applique aussi au firewall, mais il n'est pas vraiment utile de les multiplier dans le LAN, il y en a déjà assez dans le WAN.
- Leur plus gros usage en entreprise, c'est les règles de sécurités, qui servent en gros à filtrer des catégories de domaines. Déjà les URL ne sont pas toujours catégorisées de facon cohérentes, même sur de grosses solutions, d'autres part en télétravail, soit y a pas de VPN et donc pas de proxy obligatoire (un client peut toujours désactiver la conf proxy), soit il a un VPN, qui souvent a un beau split-tunnel configuré/configurable par le client pour le trafic web, et donc faire comme si il n'y avait pas de VPN.
En fait, les proxy web sont intéressants surtout dans certains cas particuliers.
Emacs le fait depuis 30 ans.
[^] # Re: Efficacité des bloqueurs de pub ?
Posté par Astaoth . En réponse à la dépêche Les enchères en temps réel, un danger pour la vie privée mais aussi pour la sécurité européenne. Évalué à 3 (+1/-0).
Donc en gros, dans le principe, pour lutter contre ce tracage, il faut lutter contre les générations de fingerprints de navigateurs webs ?
Emacs le fait depuis 30 ans.
[^] # Re: solutions à pas cher
Posté par Astaoth . En réponse au journal Migration prochaine de linuxfr. Évalué à 4 (+2/-0).
Taper brutalement la tranche d'un disque dur sur une surface solide a été une vraie technique de sioux pour réparer temporairement certaines pannes. En bonus, parait qu'en plus de ranger les données, ca les compresse.
Emacs le fait depuis 30 ans.
# Et Arch ?
Posté par Astaoth . En réponse au journal Les distro pionnières, en recul?. Évalué à 8 (+6/-0).
Arch est un classique, qui avec ses dérivés (comme Manjaro) a quand même l'air assez présent pourtant, avec des communautés actives.
Après, que les distros blending edges soient en recul par rapport aux desktops plus simples me parait être un bon signe, ca montre une certaine démocratisation de Linux (assez relative vu les données de statscounter).
Emacs le fait depuis 30 ans.
[^] # Re: Si j'ai bien compris la définition du web 4.0
Posté par Astaoth . En réponse au journal Web 4.0 : L'union européenne et les mondes virtuels. Évalué à 2 (+0/-0).
Le gros buzzword du moment c'est l'IA, avec tout les marketeux qui essayent d'en mettre partout, surtout quand ca sert à rien, et sans trop savoir ce qu'ils font. Du coup on peut dire que le web 4.0 n'est déjà plus le web des mondes virtuels, mais plutôt celui de l'IA ?
Emacs le fait depuis 30 ans.
# Si j'ai bien compris la définition du web 4.0
Posté par Astaoth . En réponse au journal Web 4.0 : L'union européenne et les mondes virtuels. Évalué à 6 (+4/-0). Dernière modification le 15 février 2024 à 17:10.
On parle de ca du coup ?
Donc en gros, la définition du Web 4.0, c'est un ensemble de techno propriétaires auxquelles seuls certains acteurs peuvent participer en fonction de la taille du compte bancaire ?
Bon, plus sérieusement, je trouve que la définition du Web 4.0 est exactement la même que celle du Web 3.0 autour de 2005 quand on parlait de web 3D avec le légendaire VRML.
20 ans d'évolutions du web, pour réinventer les mêmes concepts au niveau institutionnel, mais en perdant le côté libre au passage.
Emacs le fait depuis 30 ans.
[^] # Re: Un problème classique sous Windows
Posté par Astaoth . En réponse au journal Sudo natif sur Windows. Évalué à 8 (+6/-0).
Un peu comme la commande find en ms-dos du coup.
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2 (+0/-0).
Pour les dépôts customs, je parle de dépôts de .deb, pas de l'appstore snap. Tu peux toujours personnaliser ton /etc/apt/source.list.d, ca un dérivé de Debian. Tu peux d'ailleurs t'amuser à mettre les dépôts Debian et virer ceux de Canonical, t'amuser à réinstaller entièrement le système "in-place" et te retrouver avec un Debian à la place, c'est toujours techniquement possible.
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 3 (+2/-1).
Du coup c'est aussi le cas pour les snaps (du moins ceux de logiciels libres). Le code source étant libre, rien n'empêche de le récupérer, le build localement, générer un deb et l'installer avec un bon vieux dpkg. Et à tout moment, on peut virer l'intégration des snaps du système, et rajouter des dépôts pour avoir les .deb qu'on souhaite.
Avec ton explication sur en quoi dépendre de Github n'est pas un problème pour une distribution, je ne comprends pas en quoi l'intégration de snap dans Ubuntu en fait une distribution propriétaire. On est pas dans la situation d'un Windows update, qui est impossible à retirer de Windows (ou alors de facon non documenté), et distribuant des mises à jours obscures. Ca reste un composant qu'on peut retirer, la procédure est documenté officiellement, on peut toujours rajouter des dépôts customs, et les composants logiciels distribués ne sont pas obscures. On peut même toujours s'amuser à transformer son Ubuntu en Debian, il n'y a aucun verrouillage fait à ce niveau là (faut juste savoir utiliser apt/dpkg).
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 3 (+1/-0).
J'ai pas ca sous Arch, FreeBSD ou même une Debian un peu ancienne, ce n'est pas une feature obligatoire d'un gestionnaire de paquets.
D'ailleurs sur des Debian 12, j'ai rencontré le cas où enlever un paquet propre de la distribution supprime la moitié de l'OS, sans avoir de gros message disant que ca va tout casser. Pourtant l'environnement en question est considéré comme un de ceux qui garantisse le plus la sécurité et la vie privée de l'utilisateur (si bien utilisé).
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 0 (+0/-2).
Mais du coup, une distribution reste dépendante aux dépôts logiciels ou miroirs qui sont configurés dedans. Qui sont dans 99% des cas hors de portées des utilisateurs.
Pire encore, pour accéder à ces dépôts, les distributions sont dépendantes de serveurs DNS externes (même si on a son propre résolveur DNS local, il est soit récursif ou forwarder, donc transmet les requêtes à l'extérieur), aux infras de FAI, etc. Du coup il y a toujours une dépendance à des services hors de contrôle de l'utilisateur.
Je suis entièrement d'accord avec toi sur le fait que dans tout les cas, peut importe les licences, les services en dehors du contrôle de l'utilisateur, et c'est bien là un de mes propos. Cette dépendance ne rend pas les distributions moins libres, du coup pourquoi dans ce cas, cette intégration de Snap rend Ubuntu non-libre ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2 (+0/-0).
Oui je vois, mais du coup avoir son propre dépôt n'enlève pas la dépendance aux dépôts de la distribution ;)
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2 (+1/-1).
Sachant qu'une grosse partie des LL sont disponibles uniquement via Github, tu es du coup quand même dépendant d'un service propriétaire, même pour télécharger les tar.gz ou les codes sources. Est-ce que à cause de cette dépendance obligatoire à Github ces logiciels sont non-libres du coup ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 3 (+1/-0).
Les données des miroirs proviennent soit de d'autres miroirs, soit des dépôts officiels de la distribution. Dans le cas (improbable, certes) où les dépôts officiels tournent sous IIS, peu importe l'existence de d'autres miroirs, la distribution reste dépendante de serveurs proprio. Est-elle non libre dans ce cas ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 1 (+0/-1).
Je ne sais pas trop. Nos distributions préférées sont dépendantes de leurs serveurs de dépôts. Rien n'indique que ce ne soient pas des Windows servers + IIS. Ca n'en fait pas pour autant des distributions non-libres.
De même, il y a un sacré nombre de projets libres dont le centre de distribution initial est uniquement Github, ce qui les rend dans une certaine mesure dépendant de cette plateforme. Est-ce que ca en fait des logiciels proprio du coup ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2 (+0/-0).
Ou alors qu'est-ce qui empêche de virer Snap d'Ubuntu et de l'utiliser juste avec ses dépôts ? Ca fait plus de 10 ans que je n'ai pas utilisé Ubuntu, j'ai surement raté 2-3 trucs, mais il me semble qu'ils ont toujours des dépôts et que ca reste une distribution Gnu/Linux/Systemd. Du coup le fonctionnement d'une Ubuntu n'est pas dépendante de la présence un gestionnaire de Snap.
Emacs le fait depuis 30 ans.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 4 (+3/-1).
Bah apparemment, d'après certains par ici, fournir une stack logiciel libre avec un ou 2 composants proprio facultatif, c'est faire de l'openwashing (genre ici par exemple).
Emacs le fait depuis 30 ans.
[^] # Re: ouaip
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à -7 (+5/-14). Dernière modification le 28 janvier 2024 à 11:21.
Franchement, parfois la question se pose. Quand on voit le nombre de bugs qu'on peut rencontrer en 15 min d'utilisation de Plasma ou le nombre d'utilisateurs qui n'arrivent pas à quitter Vi …
Emacs le fait depuis 30 ans.
[^] # Re: Info périmée ?
Posté par Astaoth . En réponse au journal Piratage de Free-Work. Évalué à 3 (+1/-0).
Du coup logique que certains aient pas été averti, surtout si ils se sont inscrits après le piratage xD.
Emacs le fait depuis 30 ans.
[^] # Re: Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 5. Dernière modification le 19 janvier 2024 à 18:31.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
Emacs le fait depuis 30 ans.
[^] # Re: Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 3.
"Cory Doctorow, né le 17 juillet 1971 à Toronto en Ontario, est un blogueur, journaliste et auteur de science-fiction canado-britannique."
Je ne vois pas de bagage technique dans son CV, du coup je doute de la pertinence d'utiliser ses propos comme référence sur un sujet assez technique et méconnu. En particulier quand il compare la TPM à un composant de vaisseau interstellaire qui mène à l'explosion de celui-ci, dans un film de science-fiction.
La TPM n'est toujours pas une techno de surveillance comme tu le sous-entends. C'est une réponse à "l'evil maid attack", la seule possible à l'heure actuelle. Je t'encourage très fortement à lire la page wikipedia à son sujet.
En dehors d'une surveillance permanente de l'équipement, les seules facons de contrecarrer cette attaque, et donc toute modification de la chaine de boot qui ne peut pas être chiffré sur un volume LUKS c'est de signer les composants logiciels, et de mesurer leurs temps d'exécutions. Un PC et un programme étant déterministes, tant que le bootloader n'est pas modifié, la durée d'exécution de chacune de ses étapes doivent être strictement identique d'un boot à l'autre. Un changement de durée d'exécution indique une modification du bootloader. Contrairement à ce qu'a écrit ton auteur de SF préférée, la TPM ne surveille pas l'ensemble des logiciels qui tournent sur le PC, mais uniquement ceux de la phase de boot, quand le SecureBoot est actif.
La TPM ne serait une technologie de surveillance de l'utilisateur que si ses fonctionnalités ne pouvaient pas être désactivées (et on peut allègrement passer outre la TPM en désactivant le secure boot, encore une fois), si elle stockait les infos de chaque boot (c'est pas le cas, elle compare les durées d'exécutions et des signatures seulement, sans plus, et je doute un peu qu'elle ait les capacités de stockage pour stocker les données de tout les boots d'un PC), et si elle transmettait ces informations à des acteurs extérieurs (c'est toujours pas le cas, la TPM n'a pas de stack réseau). Et avant de faire un lien bancale entre la TPM et l'UEFI, il est totalement possible de trouver des TPM externe, qu'on utiliserait sur un raspi qui n'a pas d'UEFI. L'hypothèse que la TPM a été créé comme un dispositif de surveillance de l'utilisateur est donc erronée. Mais tout ceci n'a toujours aucun rapport avec l'attaque de l'article de Ars Technicas.
Même un firmware de hardware libre reste hors de porté de l'utilisateur, en particulier de ceux n'ayant aucun bagage technique. Mais si les firmwares qui proposent des interfaces standardisés par des normes ISO pour les OS et drivers n'existaient pas, l'utopie d'avoir des OS indépendants de grosses sociétées resterait une fiction. Pour en avoir une vague idée, souvenons-nous de la sombre époque de ndiswrapper pour le wifi, et imaginons un seul instant être dans la même situation pour l'accès aux volumes de stockages par exemple.
Au vu du contenu de son article, c'est également le cas de Cory Doctorow. Le problème est qu'il a pris des morceaux d'info ici et là, sans vraiment les comprendre, et au lieu de creuser le sujet, il les a assemblé à la facon d'un blogueur, journaliste et auteur de science-fiction. Malheureusement pour lui, nous ne sommes pas dans un roman de science-fiction, la TPM n'a pas les buts et fonctionnalités qu'il décrit, et les scénarios catastrophes qu'il mentionne restent … de la fiction.
Renseigne-toi vraiment sur ce qu'est une TPM, mets en place un secure boot, et testes les scénarios catastrophe de ton auteur préféré (lorsque possible) pour voir si ils sont réalistes ou non (par exemple, essaye d'avoir un ad-blocker dans ton navigateur web et vois si la TPM t'en empêche avec un secure boot actif).
Emacs le fait depuis 30 ans.
# Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 10. Dernière modification le 19 janvier 2024 à 03:08.
Je ne suis pas sûr de comprendre le rapport entre l'attaque découverte et le contenu du journal.
L'attaque exploite une chaine de vulnérabilité sur les boots PXE et l'IPv6 de l'UEFI. Je ne suis pas sûr de comprendre le rapport avec les TPM du coup.
D'après Wikipedia, "Trusted Platform Module (TPM) was conceived by a computer industry consortium called Trusted Computing Group (TCG)." et "Members include Intel, AMD, IBM, Microsoft, and Cisco.". Du coup les TPM n'ont pas été créées juste par Microsoft.
Les TPM en tant que telles ne servent qu'à stocker des clefs et signatures cryptographiques, et il est totalement possible de les effacer et d'y mettre les siennes. C'est long et pénible, mais faisable sous le contrôle de l'utilisateur qui souhaite avoir son propre set de clefs et signatures. Si l'utilisateur ne veut pas s'embêter avec ca, il peut aussi juste désactiver le Secure Boot, comme à l'époque des BIOS. Du coup je ne vois pas trop le rapport avec les DRM.
Le journal fait mention de dispositifs de surveillance dans les ordis modernes après avoir parlé d'UEFI, de TPM et de cette nouvelle attaque.
Pour rappel, les TPM et UEFI n'ont rien à voir avec des dispositifs de surveillance. La fonction d'une TPM est de répondre à ce problème très bête et très dur à résoudre de "l'evil maid attack".
L'UEFI a été créé pour remplacer un BIOS vieillissant (il me semble que, un compatible-PC, à l'étape du BIOS, émule littéralement un IBM PC d'il y a 40 ans ; ca devient un peu long de compter quelques dizaines de Go de RAM pendant un POST), dont les mises à jours sont plus que scabreuses (en cas de plantage d'une maj, il faut remplacer la puce du BIOS par une nouvelle, flashée avec le firmware), et créé à une époque où les besoins en sécurités étaient différents.
Les buts et fonctionnalités initiales de l'UEFI sont plus ou moins les mêmes que celui des BIOS : être une interface basique d'exploitation du matériel et lancer le bootloader. Bien évidement qu'un UEFI peut exploiter le matériel, exactement de la même facon q'un BIOS peut le faire. D'ailleurs les boots PXE ne sont pas apparu avec les UEFI, donc rien ne dit que cette attaque n'existait pas avec les BIOS, mais n'a pas été découverte officiellement. On a d'ailleurs pas attendu les UEFI pour trouver des attaques sur les firmwares, je me souviens d'une histoire de disques durs d'il y a quelques années à ce sujet.
Ce journal parle enfin d'éthique sur les firmwares, et semble sous-entendre que les UEFI ne sont pas éthiques. Au vu de l'évolution de la recherche en sécurité durant la dernière décade, et des fonctions très similaires entre les BIOS et UEFI, est-ce que l'absence d'attaque connue de ce type sur les BIOS implique nécessairement leur impossibilité ? Et quel rapport avec l'éthique en fait ?
Pour rappel, la chaine de vulnérabilité nécessaire à cette attaque est disponible sur au moins un UEFI open-source, l'implémentation de référence d'Intel (sous licence BSD). Si j'ai bien compris la page wikipedia de EDK II (l'UEFI de Intel), il fait maintenant parti de Coreboot, la stack libre visant à remplacer les BIOS et UEFI. Mais peut-être que Coreboot n'est pas un projet éthique dans son principe ? D'ailleurs, serait-il plus éthique de ne pas avoir un firmware s'occupant de l'initialisation du matériel, du lancement du bootloader et présentant une interface standardisé du matériel à l'OS, et donc de devoir dépendre du bon vouloir des fabriquant de cartes mères ?
Et enfin, cette attaque nécessite une chaine de vulnérabilité assez importante (9 vulnérabilités du coup), et a comme pré-requis d'avoir le PXE actif, et peut-être aussi de l'IPv6 (sur certains UEFI, on peut choisir d'avoir du PXE uniquement en v4 ou v6). Cette vulnérabilité semble donc assez simple à mitiguer pour un particulier. Pour les UEFI virtuels, une mise à jour de l'hyperviseur corrigera les vulnérabilités ; pour les UEFI matériels, une mise à jour, faisable depuis l'OS pourra également bloquer l'attaque. Avec un BIOS, ce genre de patch serait beaucoup plus pénible à appliquer sur les environnements physiques, car il ne pourrait se faire que manuellement, en démarrant non pas l'OS mais directement le firmware de màj du BIOS, avec toujours le risque que si la màj se vautre, il faut remplacer la carte mère.
En conclusion, je trouve qu'utiliser un article sur une attaque d'un composant matériel pour dire que celui-ci ainsi qu'un autre composant matériel (pas impacté par l'attaque) sont des techno de surveillance, voir des backdoors, c'est assez peu éthique je trouve.
Emacs le fait depuis 30 ans.
[^] # Re: du dur ou du cloud
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 6.
Ca concerne toutes les implémentation d'UEFI ayant ces vulnérabilités.
"The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft.".
J'imagine qu'on peut supposer qu'un UEFI open source peut largement être utilisé dans le monde de l'hypervision, et notamment des hyperviseurs open-sources.
Emacs le fait depuis 30 ans.
[^] # Re: Camera cachée
Posté par Astaoth . En réponse au journal J’ai fait fuir les voleurs (trop forte !?). Évalué à 5.
Une de ces fameuses caméras qui se retrouve en ligne après ?
NB : ce site ne recense aucune caméra situé à l'intérieur d'un appartement normalement, mais d'autres le font. C'est d'ailleurs très amusant de faire aboyer une caméra dans un commerce.
Emacs le fait depuis 30 ans.
[^] # Re: Batterie
Posté par Astaoth . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 3.
Avec le Thinkpad E15 du boulot sous W10, j'étais obligé de le débrancher le soir, sinon il s'allumait pendant la nuit, pour installer des mises à jours que finalement il n'installait pas, et rester allumer toute la nuit. Au matin, j'avais largement de quoi tenir toute la matinée sans problème.
Sous QubesOS (pas réputé avoir la meilleure gestion énergétique et l’hibernation est impossible avec), je peux laisser l'ordi en veille toute la nuit, j'aurais quand même de la batterie le lendemain, sur un Dell avec un Intel gen10.
Emacs le fait depuis 30 ans.