UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

tshirtman · Le 29/10/2011, à 11:08

Ce que je ne comprends pas, c'est qu'on puisse prendre une décision technique sans lire un petit peu les différentes approches proposées, et leurs implications!

Moi non plus je n'accepterais pas de ne pas pouvoir manager les clés présentes dans mon ordinateur, ou au pire (mais je préfèrerai vraiment la première solution), de ne pas pouvoir désactiver le secure boot, c'est l'évidence et il n'y a pas besoin d'en débattre! J'explique juste que le secure boot, si le possesseur de la machine, et non pas l'OEM, est en charge de la gestion de clés, est vraiment une bonne chose. T'as lus le PDF que j'ai donné? écris par un architecte chez cannonical, un senior dev chez red hat, et un dev kernel, pas exactement des branques en informatique, ou des anti-libristes, à priori.

sam7 · Le 29/10/2011, à 12:28

Je viens de découvrir ceci :

Nicolas Barcet a écrit :

If you are working for an OEM or ODM, please read this...
White Paper: Secure Boot impact on Linux « Canonical Blog
[url]http://[Merci de relire les règles]/v4Y22A[/url]
Traduction "google" d'extraits du lien ci-dessus :
"Canonical , en collaboration avec Red Hat , publie aujourd'hui une livre blanc soulignant les implications de ces exigences pour les utilisateurs et les fabricants. Le document fournit également des recommandations sur la façon de mettre en oeuvre "démarrage sécurisé", afin de s'assurer que les utilisateurs restent sous le contrôle de leur PC."
"Le Forum UEFI, dont Canonical est membre, est de définir l'interface entre votre prochaine génération du système du firmware et de tout système d'exploitation qui tourne sur elle. Les nouvelles spécifications rendront les systèmes Ubuntu boot plus rapide, avoir une vie meilleure batterie et sont plus faciles à configurer."
"Boot sécurisé doit être disponible pour tous les utilisateurs
Canonical avec succès des partenariats avec les fabricants d'ordinateurs d'expédier des millions d'Ubuntu pré-installé des systèmes de chaque année. Bien que cette répartition sera de continuer à prospérer, nous sommes inquiets pour les utilisateurs désireux d'installer la distribution Linux sur un PC vendu avec Boot sécurisé "ON"."

Canonical (entre autres) est impliqué dans ce processus ... affaire à suivre donc

Dernière modification par sam7 (Le 29/10/2011, à 16:08)

tshirtman · Le 29/10/2011, à 12:36

c'est fou, j'ai vraiment l'impression d'etre invisible desfois

helly · Le 29/10/2011, à 12:40

Anéfé >_< !

sam7 · Le 30/10/2011, à 00:18

Red Hat et Canonical s'unissent pour contrer le Secure Boot.
PDF (en) : http://ozlabs.org/docs/uefi-secure-boot … -linux.pdf

Canonical and Red Hat Join Forces to Stop Secure Boot - Softpedia
http://news.softpedia.com/news/Canonica … 0834.shtml

tshirtman · Le 30/10/2011, à 00:18

>_>

tshirtman · Le 30/10/2011, à 00:19

il y a 24 heures tshirtman a écrit :

http://ozlabs.org/docs/uefi-secure-boot … -linux.pdf
un peu plus officiel que les explications de Matthew Garrett sur son blog, mais grosso modo la meme chose, désolé pour les anglophobes, je vais juste traduire ce bout:
For support purposes, the mechanism provided for key management must be consistent across
platforms, and provide a simple method of booting custom software, including from removable
media. A suggested implementation may be to scan removable media for signing keys and prompt
the user for their installation, or using the specification-defined setup mode to allow key
reconfiguration
Pour des raisons de support, le mécanisme proposé pour la gestion des clés doit etre consistent d'une plateforme à l'autre, et offrir une méthode simple pour démarrer des firmwares spécifiques, en particulier depuis des médias amovibles. Une implémentation possible peut etre de scanner les médias amovibles à la recherche de clés de signatures et proposer à l'utilisateur leur installation, ou utiliser la configuration définit par la spécification pour permettre la reconfiguration de clés.
---
Pour moi c'est une solution suffisante, acceptable, relativement simple, et qui ne diminue en rien l'intéret du secure boot.

edit, et l'article de softpedia est faux, il ne s'agit pas de combattre le secure boot, mais de s'arranger pour qu'il soit une bonne chose pour nous.

Dernière modification par tshirtman (Le 30/10/2011, à 00:21)

Haleth · Le 30/10/2011, à 21:37

tshirtman, si j'ai bien compris, il ne s'agit pas de signer tout les prgm, mais seulement un unique prgm : le bootloader (et / ou un bout d'OS, j'sais pas trop)
Dans ces conditions, une fois qu'un OS valide est lancé, tu peux faire tourner n'importe qu'elle saloperie dessus, impunement.
Remarque, il faut deja faire ca pour contaminer le bootloader, ce qui reviens à ma remarque précendent : UEFI = serpent qui se mord la queue.

tshirtman · Le 30/10/2011, à 22:08

Non, on peut actuellement signer tout le reste, pas le bootloader, hors, celui ci est la base de tout le reste, et ne pas pouvoir le signer crée une impossibilité de sécuriser toute la suite, vu que toute étape non signé peut compromettre les suivantes, en remplaçant un binaire par un autre. Sécuriser le bootloader est donc une étape importante, indispensable à la sécurisation du reste.

Sinon windows signe déjà actuellement les binairs, et demande confirmation de lancement quand ça vient d'internet ou quand la signature n'est pas connue (ou absente), ça n’empêche pas de dire "oui" si on sait ce qu'on fait.

Après, UEFI ne résoudra pas les soucis de windows une fois lancé, mais ça limitera les dégats d'une augmentation de privilèges. Remarque, chez nous aussi les augmentations de privilèges du à des failles de sécurités arrivent, et permettent souvent d'executer du code arbitraire, et donc de modifier le système. Valider le bootloader, et par effet cascade, tout le reste, permettrait d'avoir simplement à redémarrer un système pour le récupérer "clean".

Haleth · Le 30/10/2011, à 22:14

Ouais, ok, j'ai compris.
Sous la majorité des distrib nux, tu as des gestionnaires de paquets.
Sous win, quand tu veux un truc, tu prend l'premier lien sur google, et tu test voir si ca fonctionne ou pas.

tshirtman · Le 30/10/2011, à 22:18

Après, je dis pas qu'on en a un besoin urgent, mais si on peut le tourner à notre avantage, c'est une bonne chose et il ne faut pas s'en priver, en plus, je ne pense pas qu'on ait une chance de jouer au bras de fer avec microsoft. Autant tourner la situation à notre avantage.

sam7 · Le 31/10/2011, à 13:01

je vous invite à consulter ceci pour avoir un peu plus d'informations ... & les liens qui y sont donnés (en anglais malheureusement)
http://sam7-blog.sujets-libres.fr/2011/ … t-du-bios/

tshirtman · Le 31/10/2011, à 13:06

@sam7: tu lis le fil ou t'es en écriture seule? je dis pas que ton blog sert à rien, mais ça fait un peu autiste ta façon d'agir là.

sorrodje · Le 31/10/2011, à 13:15

tshirtman a écrit :

@sam7: tu lis le fil ou t'es en écriture seule?

Sam7 .. toutes les infos sont déjà dans le topic .. arrête de promouvoir ton blog à tous les coins de forum.

tshirtman · Le 03/11/2011, à 22:53

kamui57 a écrit :

Ça a déjà l'air en place chez HP, quelqu'un rapporte en anglais ne pas avoir pu installer grub sur un pc hp.
http://benjaminkerensa.com/2011/10/23/u … gin-linux/

http://mjg59.dreamwidth.org/7411.html
j'avais pas trop été voir, mais d'après ce qu'en dit matthew garrett, si ça a sans doute un rapport avec l'UEFI, ça ne peut pas avoir de rapport avec le secure boot, qui n'est pas encore en place, c'est plus probablement un bug soit dans l'UEFI du pc en question, soit dans la gestion de l'UEFI par linux. Et c'est en cours de résolution , nouveau soft = nouveaux bugs, rien de neuf sous le soleil .

patrick L · Le 03/11/2011, à 23:11

@tshirtman

est ce que avec une signature par exemple sha1 on peut signer des données, (ca bien sur) et ensuite avoir un changement et virer le changement suite au changement des données via un virus.

exemple
charger piste 1 secteur 20, jmp 100h
et dedans on a virus

charger virus secteur 20, jmp 100h

et si le boot est vérolé c'est bien joli mais ca veut dire que le pc ne charge plus... sauf si on peut revenir à un état initial.

Haleth · Le 03/11/2011, à 23:31

C'est interessant comme théorie, sauf qu'empecher le PC de booter n'est que rarement le but (aucun interet, ormis le sadique plaisir de faire chier autrui).
De plus, cela requiert les droits administrateurs : il est plus simple, donc, de .. supprimer tout les fichiers, par exemple.

tshirtman · Le 04/11/2011, à 00:13

un virus qui mettrait en pane les ordis ne se répandrait pas vite, en effet, et donc perdrait beaucoup de son intéret.

Et non, la signature ne permet pas de reconstituer les données, seulement un contrôle de l'intégrité.

helly · Le 04/11/2011, à 10:57

Un virus a pour but de prendre le contrôle d’une machine ou de reccupérer des données.
Un virus qui détruit des données, ça ne sert à rien !

redo_fr · Le 04/11/2011, à 11:29

helly a écrit :

Un virus qui détruit des données, ça ne sert à rien !

Je dois être pervers, moi je vois au moins deux utilisations d'un virus "destructeur":

1*/ Infecter un concurrent pour lui faire prendre du retard
2*/ Détruire mes propres données "douteuses" en cas de contrôle policier

Il doit sûrement il y avoir d'autres utilités ^_^

tshirtman · Le 04/11/2011, à 11:34

si tu es capable de 1/, pas besoin d'un virus
pour 2/ pas besoin d'un virus

jnq · Le 04/11/2011, à 11:37

Bonjour, un virus est illusoire pour le 2/

helly · Le 04/11/2011, à 11:44

Pour le 2 : shred, wipe, dd…
S’pas les outils qui manquent.

jnq · Le 04/11/2011, à 12:01

Désolé helly t'as perdus. Les experts ne t'embaucherons jamais. On peut toujours récupérer les données d'un dd en salle blanche et en irm, il n'y a qu'un champ magnétique de quelques teslas suivit du pilon qui garantie la destruction réel des données. Ne pas oublier qu'un dd ne fait qu'écrire et n'efface jamais. L'alignement des têtes de lecture écriture n'est jamais parfait à chaque passage et laisse des imperfections magnétiques.
Quand au ssd il sont les seuls pour le moment à permettre l'effacement réel des données.

Dernière modification par jnq (Le 04/11/2011, à 12:11)

tshirtman · Le 04/11/2011, à 15:03

@jnq: shred peut faire plusieurs passes, et dd aussi, et non, même en salle blanche, ça fait pas tout, plusieurs écritures aléatoires, et tu va t'amuser pour les chercher, tes imperfections magnétiques, pour trouver des données cohérentes. Après c'est de l'ordre du palimpseste informatique, et vu les optimisations faites pour écrire par les disques, ça devient vraiment de l'ordre de l'impossible.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#151 Le 29/10/2011, à 11:08

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#152 Le 29/10/2011, à 12:28

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#153 Le 29/10/2011, à 12:36

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#154 Le 29/10/2011, à 12:40

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#155 Le 30/10/2011, à 00:18

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#156 Le 30/10/2011, à 00:18

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#157 Le 30/10/2011, à 00:19

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#158 Le 30/10/2011, à 21:37

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#159 Le 30/10/2011, à 22:08

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#160 Le 30/10/2011, à 22:14

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#161 Le 30/10/2011, à 22:18

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#162 Le 31/10/2011, à 13:01

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#163 Le 31/10/2011, à 13:06

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#164 Le 31/10/2011, à 13:15

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#165 Le 03/11/2011, à 22:53

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#166 Le 03/11/2011, à 23:11

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#167 Le 03/11/2011, à 23:31

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#168 Le 04/11/2011, à 00:13

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#169 Le 04/11/2011, à 10:57

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#170 Le 04/11/2011, à 11:29

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#171 Le 04/11/2011, à 11:34

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#172 Le 04/11/2011, à 11:37

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#173 Le 04/11/2011, à 11:44

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#174 Le 04/11/2011, à 12:01

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

#175 Le 04/11/2011, à 15:03

Re : UEFI et TPM...Quand Microsoft veut empêcher les OS alternatifs

Pied de page des forums