SUSE détaille ses plans pour le démarrage sécurisé

[alphadi]

Vojtěch Pavlík ingénieur chez SUSE a détaillé les plans de l'entreprise pour mettre en œuvre le Boot sécurisé EFI. La société cherche à adopter une approche semblable à celle que le projet Fedora veut inclure dans Fedora 18. Selon un précédent post de blog de Kirch Olaf, l'entreprise prévoit également de recommander leur approche au projet openSUSE. Bien que similaire, les plans de SUSE diffèrent dans certins points clés de Fedora et plusieurs développeurs de Fedora ont déjà laissé entendre que leur projet pourrait modifier leur approche et intégrer certains changements du projet SUSE. Le plan détaillé par Pavlík voit la distribution SUSE faire usage de shim bootloader développé par Fedora. SUSE prévoit de proposer deux versions distinctes de shim, celui signé avec une clé fournie par Microsoft (similaire à l'approche de Fedora) et celui signé avec la clé propre SUSE. La signature shim avec sa propre clé est quelque chose que la communauté Fedora a écarté lorsque ils ont formulé leur stratégie de démarrage sécurisé et l'approche SUSE est très semblable à des parties du plan de Canonical pour Ubuntu.
Le plan de SUSE voit le processus de démarrage se replier sur la touche de Microsoft sur les systèmes où une clé SUSE ne peuvent pas être fournie par le matériel. Un nouvel aspect de la proposition de Pavlik est un add-on pour shim que SUSE développera et qui permet au logiciel de calcul supplémentaires de clés publiques à partir d'un fichier distinct sur le disque dur. Ces touches peuvent ensuite être utilisées pour vérifier GRUB et le noyau Linux en outre lors du démarrage. Dans le plan de Fedora, ces clés seront directement intégrés dans le binaire de shim ce qui signifie que shim doit être recompilé et re-signé à chaque fois qu'une nouvelle clé est ajoutée. Les développeurs de SUSE ont nommé les clés publiques dans ce fichier MOKs (Machine Owner Keys). Les utilisateurs peuvent ajouter de nouvelles MOKs à leur système par l'activation d'un raccourci clavier dans shim pour démarrer ce que Pavlík appelle le 'processus d'inscription" ("enrolement process"). Lorsqu'une nouvelle clé est ajoutée, shim crée un hachage de celui-ci et le sauvegarde dans une variable "Boot Services Only" dans le firmware UEFI. Cela permet à shim de détecter si les touches ont été falsifiées. Comme pour les plans de Fedora, le chargeur de démarrage shim minimal invoquera le GRUB 2 le plus flexible s'il a été signée avec la clé propre à SUSE ou l'un des MOKs. Pour atteindre cet objectif, shim passe la liste des MOKs à GRUB. GRUB lui-même va alors vérifier l'intégrité des noyaux qu'il veut démarrer. La façon dont shim est prévue fonctionner est censée rendre plus facile pour les utilisateurs le démarrage de leurs propres noyaux avec Boot sécurisé activé. Les utilisateurs peuvent simplement fournir leurs propres MOKs via shim au lieu d'avoir à signer shim et GRUB avec leur propre clé qui doit ensuite être chargée sur le firmware UEFI (un processus qui diffère entre les implémentations matérielles). Un autre avantage de cette approche est la possibilité de dual-boot du noyau des différentes distributions. Ceux-ci peuvent être vérifiés en incluant une MOK pour chaque distribution. Cette approche est plus facile pour l'utilisateur, mais contrecarre l'un des concepts de UEFI qui avaient été c...çu pour faciliter le double amorçage en donnant à l'utilisateur un choix des différents chargeurs au moment du démarrage.
L'approche SUSE permet également aux utilisateurs de modifier librement leur version de GRUB 2, tout en rendant possible l'utilisation de cette version modifiée pour démarrer leurs systèmes. Ceci est conforme à l '"anti-Tivoisation" clause de la GPLv3 et devrait éviter le problème d'avoir à divulguer les clés de signature, qui a conduit canonical à éviter la licence GPLv3 de GRUB2. Le développeur de Red Hat Matthew Garrett, qui dirige le développement des plans de Fedora pour démarrage sécurisé, a appelé la mise en œuvre de SUSE du fichier MOK et sa protection par l'intermédiaire d'un des services d'amorçage de UEFI par une seule variable "une merveilleuse et élégante solution." ("a wonderfully elegant solution.") Garrett suppose que l'extension shim de SUSE va trouver sa voie dans l'approche de démarrage de Fedora, car il simplifie le processus, mais ne veut pas dire quand cela se produirait. Greg Kroah-Hartman de la Linux Foundation a également déclaré dans un message sur Google + qu'il apprécie l'approche de SUSE. Dans le même temps, Josh Boyer, qui est maintient le noyau de Fedora, a posté un long blog dans lequel il résume ses expériences avec le Boot sécurisé. Ce post donne quelques éclaircissements sur les spécificités du démarrage sécurisé car il affecte Linux et met également en lumière certains problèmes rencontrés dans ce domaine. Source: h-online.

[fanch]

Salut,

si je comprends bien (mais rien n'est moins sûr), un utilisateur de Suze ou Fedora pourra en quelque sorte manipuler le boot sécurisé.
Supposons un petit "malveillant" qui aura un média live d'une de ces deux distributions. Il pourra donc, s'il a un accès à la machine, rendre complètement inopérant ce fameux "secure-boot".
Quelle belle sécurité, lorsqu'on offre la clé du cadenas au public...

Mais, je suppose que comme la plupart des idées M$oft, on pourra y ajouter un genre d'anti-petit-malveillant. Moyennant finances, bien entendu...

[alphadi]

attendons de voir

[jpsan]

M$ n'est pas aussi fermé qu'on le dit. La preuve, ils demandent de l'aide à des tiers pour bloquer leurs failles de sécurité.

Bon ok, là je suis méchant ; ils ont quand même quelques produits au top niveau de la technologie, des programmes efficaces qui fonctionnent très bien comme Microsoft Security Essential. C'est leur meilleur programme.

Celui qu'il n'auraient pas eu besoin de créer si il avaient su faire un système d'exploitation.

[alphadi]

tres drôle

[fanch]

Salut !

cépafo !