Un meilleur job mieux payé ?

Deviens chef de projet, développeur, ingénieur, informaticien

Mets à jour ton profil pro

ça m'intéresse

Canonical détaille ses plans pour le support de l'UEFI Secure Boot
GRUB 2 ne sera plus utilisé par défaut sur les futures versions d'Ubuntu

Le , par Hinault Romaric, Responsable .NET
Pour son futur système d’exploitation Windows 8, Microsoft a opté pour l’utilisation de l’UEFI ( Unified Extensible Firmware Interface) en remplacement du BIOS.

Les constructeurs désireux de proposer des dispositifs sous l’OS seront donc obligés de passer à l’UEFI, avec une activation par défaut de la fonction Secure Boot.

Cette fonctionnalité de sécurité offrira au système d’exploitation un processus de démarrage signé et mesuré, qui aide à protéger le PC en détectant les logiciels malveillants au démarrage, et en empêchant le chargement de ceux-ci.

Le revers de la médaille de cette nouveauté est qu’elle rend compliquée l’installation en dual-boot d’un système alternatif (Linux par exemple) sur un dispositif. En effet, le firmware UEFI embarque une clé de sécurité, et le système d’exploitation doit connaitre la clé pour démarrer.

Vivement critiquée par les acteurs de l’open source (Red Hat, Canonical, etc.), Microsoft a finalement autorisé la mise en place des clés spécifiques pour les plateformes Intel.

Les éditeurs des systèmes Linux travaillent donc actuellement sur des solutions pour prendre en charge l’UEFI. Canonical vient de livrer ses plans pour son système d’exploitation Ubuntu.

La société a déjà généré une clé Ubuntu, et est en active discussion avec les partenaires pour l’intégration de cette clé dans le firmware UEFI.

La clé ne pouvant être divulguée, les futures versions d’Ubuntu ne pourront plus utiliser GRUB 2 sur les systèmes ou le Secure Boot est activé. En effet, GRUB 2 étant publié sous une licence GPL 3, l’intégralité de son corde source doit rester de ce fait accessible.

Les versions suivantes d’Ubuntu à partir de la 12.10, utiliseront une version modifiée du chargeur d'Intel Efilinux.

Red Hat, pour sa part, a déjà trouvé une solution pour la prise en charge de l’UEFI et le Secure Boot sur architecture Intel. La firme a travaillé avec Microsoft et des fabricants afin de trouver un moyen de fournir des clés pour ses distributions.

La solution de Red Hat a été mise à la disposition des autres éditeurs qui devront s'acquitter d'un droit de 99 dollars chez Verisign pour obtenir une clé valide. Solution que Canonical a préféré ignorer.

Source : Ubuntu


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de maxwell302 maxwell302 - Membre confirmé http://www.developpez.com
le 25/06/2012 à 16:52
Si à terme le BIOS est remplacé par l'UEFI, si les responsables des différentes distrib linux/unix/whatever veulent pouvoir installer leurs OS sur les nouvelles machines équipée de l'UEFI, ils devront les adapter.
Et ils ont déja commencé.

Alors ou est le problème?

Ne pas pouvoir installer une version obsolète sur une machine récente?
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 25/06/2012 à 17:31
Citation Envoyé par l.bruninx  Voir le message
Sur les bonne carte mère équipée UEFI, il suffit de désactiver l'option "Secure Boot" et la question ne se pose plus (protection de polichinelle).

Pour le moment, mais nul doute que cette option risque de disparaitre sur la majorité des machines à venir.
Citation Envoyé par l.bruninx  Voir le message
Bien sûr, en tant que client, vous pouvez demander à votre revendeur d'ordinateurs de vous fournir du bon matériel (C-à-d, celui que vous pouvez configurer comme vous l'entendez, ce qui exclut les marques qui ferment intentionnellement leur produit).

Certes mais, la tendance actuelle ne va malheureusement pas du tout dans ce sens. La micro informatique est toujours moins un domaine d'experts qui souhaitent avoir le contrôle de son matériel.
Citation Envoyé par abriotde  Voir le message
le principe est le même. Il suffit de rechercher une signature valide de microsoft.
Mais le principe si je ne me trompe pas va plus loin... Il s'agit de calculer un Hash (http://fr.wikipedia.org/wiki/Hash) du programme de boot et de signer ce Hash avec la clef privé.

Oui je n'ai pas détaillé ça car c'est le principe de base d'une signature électronique, de n'être valide que pour les données pour lesquelles elle a été généré. A moins de trouver une collision sur le hash, mais ça m'étonnerait que SecureBoot utilise un algo de hash compromis.

Donc une analyse même poussée de Windows au débogueur ne donnera rien, car si le boot est modifié d'un seul octet, la signature ne sera plus valide. Il faudrait en régénérer une nouvelle à partir de la clé privé que Microsoft garde bien sûr à l’abri, chez lui, probablement sur une machine déconnectée.

Citation Envoyé par maxwell302  Voir le message
Si à terme le BIOS est remplacé par l'UEFI, si les responsables des différentes distrib linux/unix/whatever veulent pouvoir installer leurs OS sur les nouvelles machines équipée de l'UEFI, ils devront les adapter.
Et ils ont déja commencé.

Alors ou est le problème?

Il n'y a pas de problème a part la GPLv3 qui interdit explicitement ça sauf si on fournit la clé privée, ce qui est inenvisageable car ça ruinerait le principe même de la protection.

Heureusement, il y a des licences reconnues libres qui n'ont pas cette restriction. Mais grub se retrouve hors-jeu.
Avatar de eti0123456789 eti0123456789 - Membre du Club http://www.developpez.com
le 25/06/2012 à 18:00
Citation Envoyé par maxwell302  Voir le message
Si à terme le BIOS est remplacé par l'UEFI, si les responsables des différentes distrib linux/unix/whatever veulent pouvoir installer leurs OS sur les nouvelles machines équipée de l'UEFI, ils devront les adapter.
Et ils ont déja commencé.

Alors ou est le problème?

Ne pas pouvoir installer une version obsolète sur une machine récente?

Le problème est un problème de fond, c'est celui de l'informatique de confiance, qui paradoxalement est de nature à donner moins confiance à l'utilisateur expert, puisqu'il doit s'en remettre à des autorités de signature pour attester de la "sécurité" de l'OS qu'il exécute : on décide que seule une poignée d'entreprises ont le pouvoir d'autoriser l'exécution de tel ou tel programme/OS sur tous les ordinateurs, même ceux dont l'utilisateur souhaite utiliser explicitement un autre programme (qui peut être libre, non libre, venir d'une entreprise, d'une communauté, peu importe, ce n'est pas la question). Cela a quand même une tendance anti-concurrentielle assez forte !
Avatar de yesilay yesilay - Futur Membre du Club http://www.developpez.com
le 26/06/2012 à 21:30
S'ils veulent vraiment sécuriser le démarrage du windows, ils feront mieux d'améliorer la sécurité au niveau des services/applications lancés une fois que windows a booté. Une applet java(rançonware) a rendu ma machine inutilisable. Je suis ingénieur en informatique et j'ai toujours pas trouver comment restaurer les icons du bureau. J'ai essayé plein de truc.
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 27/06/2012 à 7:20
Pour le coup une applet Java avec le droit suffisant pour pourrir ton système, ça doit être signé depuis toujours. Si tu acceptes d’accorder le droit de détruire ton système à des programmes douteux, je vois mal comment Windows y pourrait quelquechose.
Avatar de yesilay yesilay - Futur Membre du Club http://www.developpez.com
le 27/06/2012 à 10:45
Citation Envoyé par Uther  Voir le message
Pour le coup une applet Java avec le droit suffisant pour pourrir ton système, ça doit être signé depuis toujours. Si tu acceptes d’accorder le droit de détruire ton système à des programmes douteux, je vois mal comment Windows y pourrait quelquechose.

Je suis d'accord qu'il ne faut pas accepter les applets non signés. Mais le fait que, même en mode de récupération, une application se lance et qu'elle arrive à bloquer le clavier, la souris, c'est n'importe quoi. Au moins, le mode de récupération doit être vraiment sécurisé, sinon il ne faut pas l'appeler mode de recupération.
Avatar de gangsoleil gangsoleil - Modérateur http://www.developpez.com
le 27/06/2012 à 12:35
Citation Envoyé par Hinault Romaric  Voir le message
La solution de Red Hat a été mise à la disposition des autres éditeurs qui devront s'acquitter d'un droit de 99 dollars chez Verisign pour obtenir une clé valide. Solution que Canonical a préféré ignorer.

Il est vrai que la signature par une entreprise externe est une solution extremement fiable, qui n'a jamais pose de probleme...

Les deux solutions sont mauvaises, car le principe meme de l'UEFI est mauvais : je veux certifier quoi ? Que c'est bien mon OS qui bootes, et pas un autre ? Mais quel est l'interet ? Certainement pas les virus, car des virus qui remplacent la sequence de boot, c'est franchement rare.
A moins que je ne veuille certifier que mon OS est garantie pour cette CM ?

A moins que le but ne soit d'empecher les OS autres que Windows d'exister ? A titre personnel, Windows, Ubuntu, RedHat, Fedora et consors sont tous dans le meme panier des trucs ultra lourds et finalement peu securises. Mais je crains que demain le choix ne se reduisent a ces OS.
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 27/06/2012 à 13:14
Citation Envoyé par yesilay
Je suis d'accord qu'il ne faut pas accepter les applets non signés. Mais le fait que, même en mode de récupération, une application se lance et qu'elle arrive à bloquer le clavier, la souris, c'est n'importe quoi. Au moins, le mode de récupération doit être vraiment sécurisé, sinon il ne faut pas l'appeler mode de recupération.

Le mode récupération est normalement fait pour récupérer des incidents techniques, pas des malwares. De toute façon s'il ne pouvait pas s’exécuter en mode récupération, un logiciel avec tous les droits pourrait volontairement flinguer ce mode.
Et si le noyau protège les fichiers système (je ne sais pas si c'est le cas), il pourrait attaquer le bootloader, d’où l’intérêt de le protéger.
Avatar de HRS HRS - Membre confirmé http://www.developpez.com
le 29/06/2012 à 15:14
Si j'ai bien compris, le verrou "secure boot" ne concerne pas seulement les OS qu'on veut installer sur le disque dur, mais aussi ceux ("live") qu'on peut booter à partir du lecteur CD/DVD ou du port USB

Donc avant d'acheter un PC, l'acquéreur aura intérêt à vérifier qu'il peut booter un OS quelconque à partir d'une des 2 entrées et ce sera au vendeur de démontrer que le "secure boot" peut-être désactivé
Avatar de Freem Freem - Membre émérite http://www.developpez.com
le 02/07/2012 à 11:23
Citation Envoyé par gangsoleil  Voir le message
Il est vrai que la signature par une entreprise externe est une solution extremement fiable, qui n'a jamais pose de probleme...

Les deux solutions sont mauvaises, car le principe meme de l'UEFI est mauvais : je veux certifier quoi ? Que c'est bien mon OS qui bootes, et pas un autre ? Mais quel est l'interet ? Certainement pas les virus, car des virus qui remplacent la sequence de boot, c'est franchement rare.
A moins que je ne veuille certifier que mon OS est garantie pour cette CM ?

A moins que le but ne soit d'empecher les OS autres que Windows d'exister ? A titre personnel, Windows, Ubuntu, RedHat, Fedora et consors sont tous dans le meme panier des trucs ultra lourds et finalement peu securises. Mais je crains que demain le choix ne se reduisent a ces OS.

Par curiosité, quel os utilises-tu? BSD?

Enfin, au sujet de l'UEFI, je n'ai toujours pas compris ce que l'on reproche au BIOS...
Le BIOS vérifie une partie de mon matos, active/désactive un certain nombre de chose selon les volonté de celui qui a le pass... et l'UEFI, il ajoute quoi?
Sur ma bécanne: la souris et le chinois. Super...
A noter que j'ai le contrôle sur bien moins de choses qu'avec les BIOS "ancestraux" et que je soupçonne qu'il cause des problèmes sur mes périphériques SATA (qui marchent très bien sur d'autres bécannes, et de façon aléatoire sur celle en question).

Et pour la signature, j'ai bien compris que ton affirmation est ironique, mais pour enfoncer le clou, de mémoire, une "autorité de confiance" (diginotar, ou un truc du genre) a eu pas mal de souci il y a quelques mois, en refusant d'admettre qu'ils s'étaient faits pirater, ce qui a exposé au risque de nombreuses machines, y compris des machines sensibles...

La seule confiance que l'on peut placer dans une entreprise, c'est celle dans le fait que celle-ci préfèrera toujours entuber les clients si ça peut lui rapporter de l'argent...
Avatar de gangsoleil gangsoleil - Modérateur http://www.developpez.com
le 02/07/2012 à 13:24
Citation Envoyé par Freem  Voir le message
Par curiosité, quel os utilises-tu? BSD?

Oui, entre autre. Mais regardons les OS :
Windows : pas de soucis, Microsoft fait partie du consortium
Linux : On compte 420 distributions.... Alors certes, RedHat, Mandriva, Ubuntu et Suse se taillent la part du lion, et vont suivre les conneries de l'UEFI, mais quid des autres ?
BSD : pareil : pas de grosses entreprises derriere, et une communaute qui se mefie, a raison, des middleware que l'on pourrait introduire sous l'OS (voir ci-dessous)
Unix : les principaux sont pousses par des grands groupes (Oracle, IBM, HP), qui vont suivre.

Citation Envoyé par Freem  Voir le message
Enfin, au sujet de l'UEFI, je n'ai toujours pas compris ce que l'on reproche au BIOS...

Officiellement, de n'etre pas securise.
Sinon, on peut aussi voir que l'UEFI permet de tout controller, et donc d'autoriser ou non l'OS de faire certaines choses.

Pour les processeurs ARM par exemple, Microsoft pousse pour que les constructeurs ne permettent pas le boot d'un OS non signe. Lorsqu'on sait que tous les smartphones sont equipes de processeurs ARM, on voit tout de suite la logique : vous achetez un smartphone avec un OS, et vous ne pouvez pas en changer.

L'UEFI permet aussi l'utilisation de DRM avant le boot de l'OS. On peut donc imaginer qu'il soit capable d'interdire certaines choses a l'OS....

L'article wikipedia sur l'UEFI est assez bien fait.
FR : https://secure.wikimedia.org/wikipedia/fr/wiki/UEFI
EN : https://en.wikipedia.org/wiki/Unifie...ware_Interface

Citation Envoyé par Freem  Voir le message
Et pour la signature, j'ai bien compris que ton affirmation est ironique, mais pour enfoncer le clou, de mémoire, une "autorité de confiance" (diginotar, ou un truc du genre) a eu pas mal de souci il y a quelques mois, en refusant d'admettre qu'ils s'étaient faits pirater, ce qui a exposé au risque de nombreuses machines, y compris des machines sensibles...

S'il n'y en avait qu'une !
Offres d'emploi IT
Développeur JAVA J2EE
HUMANLOG - Provence Alpes Côte d'Azur - Sophia Antipolis
Urgent - Développeur .Net Confirmé H/F
Mac Allister Freelance - Ile de France - Paris (75000)
Ingénieur système unix h/f
Sogeti France - Midi Pyrénées - Toulouse (31000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil