Les questions à la con - Page 69

vince (./2040) :
Tu souhaitais que Fedora ne soit plus installable sur les machines récentes ?

Si, en désactivant "Secure" Boot, ce qui est normalement possible sur toutes les machines x86/x86_64. (Même le monopole des signatures l'exige!)

("Secure" Boot sur les machines ARM est encore une autre histoire, ce n'est actuellement pas géré par Fedora et il n'y a pour l'instant rien de prévu à ce sujet.)

Et puis bon, secureboot reste une bonne solution pour se prémunir contre les "rootkits" et autres saloperies qui menancent l'intégrité du boot loader, non ?

C'est surtout une "bonne solution" pour ne pas pouvoir installer son propre noyau (et donc adieu aux libertés données par le logiciel libre)! (Le "shim" de Fedora a maintenant une fonctionnalité spéciale où l'utilisateur peut, par une procédure très complexe, rajouter sa clé et signer ses noyaux et/ou modules de noyau avec cette clé, et comme la procédure est obligatoirement interactive, ça semble être conforme aux critères de signature. Mais c'est plus compliqué que de désactiver "Secure" Boot tout simplement.)

Le noyau Linux, booté en mode "Secure", désactive aussi certaines fonctionnalités traditionnellement autorisées, par exemple l'accès direct aux ports I/O pour les applications tournant en root.

Et enfin, "Secure" Boot ne protège rien du tout parce qu'il ne protège pas du tout l'userspace! Il n'y a strictement rien qui empêche d'avoir un rootkit de type "Blue Pill", où l'UEFI boote un noyau signé qui boote un userspace non signé (il n'y a aucune vérification à cet endroit) qui boote 1. un rootkit et 2. une VM qui boote le vrai système d'exploitation. La VM peut même émuler "Secure" Boot et l'OS ne se rendra compte de rien du tout!

Donc en gros, vu que le secure boot est désactivable pour les utilisateurs avancés et qu'il faut être un utilisateur avancé pour customiser son noyau, le problème ne se pose pas.
Vu que madame michu ne saura pas aller changer le secure boot, c'est très bien que pour les distribs en version standard (destiné au grand public, sans modif) il y ait une clé...
Un accès bas niveau au matériel est une hérésie, même en root, seul le noyau doit pouvoir d'interface à cet effet.
Pour le dernier point, j'ai envie de rire : une protection du boot ne protège pas le userspace donc elle ne sert à rien ? Dis moi, t'aurais pas refusé le vaccin contre le tétanos sous prétexte qu'il ne protégeait pas de la grippe par hazard ?

http://www.lemonde.fr/politique/article/2013/02/15/le-conseil-constituionnel-annule-l-election-de-deux-deputees-ps-des-francais-de-l-etranger_1833158_823448.html => il se passe quoi pour les "travaux" effectués depuis leurs élections respectives ? (du genre si un de ces députés à posé un projet de loi, il est abandonné ?)

Kevin Kofler (./2041) :
Et enfin, "Secure" Boot ne protège rien du tout parce qu'il ne protège pas du tout l'userspace! Il n'y a strictement rien qui empêche d'avoir un rootkit de type "Blue Pill", où l'UEFI boote un noyau signé qui boote un userspace non signé (il n'y a aucune vérification à cet endroit) qui boote 1. un rootkit et 2. une VM qui boote le vrai système d'exploitation. La VM peut même émuler "Secure" Boot et l'OS ne se rendra compte de rien du tout!

Bah oui, on est bien d'accord, faut continuer avec un userspace signé, sinon ça n'a strictement aucun intérêt...

Sauf que si tu continues avec un userspace signé, ça protège un minimum, contrairement à ce que tu dis…

Le userspace de GNU/Linux n'est pas signé et ne le sera probablement jamais. "Secure" Boot se contrefiche du userspace.

vince (./2043) :
http://www.lemonde.fr/politique/article/2013/02/15/le-conseil-constituionnel-annule-l-election-de-deux-deputees-ps-des-francais-de-l-etranger_1833158_823448.html

Je ne peux qu'être d'accord avec le commentaire d'une personne utilisant le nick "Ali Baba":

Ali Baba 15/02/2013 - 21h09C'est quand même un comble de reprocher à un élu qui a du faire campagne à l'étranger, du fait que sa circonscription EST à l'étranger, d'avoir un compte à l'étranger pour régler ses dépenses de campagne!!

Kevin Kofler (./2045) :
Le userspace de GNU/Linux n'est pas signé et ne le sera probablement jamais. "Secure" Boot se contrefiche du userspace.

Ce n'est pas parce que GNU/Linux n'est capable d'offrir aucune garantie sur l'authenticité du code qui est exécuté qu'aucun OS n'est capable de le faire...

Peut-être que tu n'as absolument rien à faire de la sécurité, mais essaie de comprendre (je sais, c'est dur) que ce n'est pas le cas de tout le monde…

Si par "sécurité", tu entends "«sécurité» style iOS", c'est-à-dire "interdiction de faire tourner des programmes qui n'ont pas été explicitement approuvés par le constructeur" (parce que visiblement, c'est bien là où tu veux en venir), je n'en veux absolument pas, c'est clair.

Je suis preneur pour des solutions qui ne sont pas liberticides!

Kevin Kofler (./2046) :

vince (./2043) :
http://www.lemonde.fr/politique/article/2013/02/15/le-conseil-constituionnel-annule-l-election-de-deux-deputees-ps-des-francais-de-l-etranger_1833158_823448.html

Je ne peux qu'être d'accord avec le commentaire d'une personne utilisant le nick "Ali Baba":

Ali Baba 15/02/2013 - 21h09C'est quand même un comble de reprocher à un élu qui a du faire campagne à l'étranger, du fait que sa circonscription EST à l'étranger, d'avoir un compte à l'étranger pour régler ses dépenses de campagne!!

Le reproche avant tout n'est pas d'avoir eu un compte à l'étranger mais d'en avoir utilisé plusieurs pour la campagne et c'est formellement interdit. (et pour ton information, un compte bancaire français peut être utilisé à l'étranger)

Dans ce cas, il s'agit d'étranger hors Europe, et les transferts bancaires entre continents sont compliqués et chers (pour des raisons, il me semble, autant politiques (UE vs. USA vs. reste du monde) que techniques (systèmes informatiques différents)).

Ayant fait 2 fois le Google Summer of Code, je suis bien au courant du bordel que sont les transactions bancaires internationales.

Kevin Kofler (./2048) :
Si par "sécurité", tu entends "«sécurité» style iOS", c'est-à-dire "interdiction de faire tourner des programmes qui n'ont pas été explicitement approuvés par le constructeur" (parce que visiblement, c'est bien là où tu veux en venir), je n'en veux absolument pas, c'est clair.

Je suis preneur pour des solutions qui ne sont pas liberticides!

En l'occurrence, ce n'est pas le cas, je parle de garantir que le code qui est exécuté est bien celui que j'ai voulu mettre

Et bah, "Secure" Boot ne permet ça que de manière extrèmement compliquée (tu dois rajouter ta propre clé, virer celles d'office si tu ne fais pas confiance aux entreprises qui les contrôlent (et tu ne devrais pas!), resigner tous tes binaires avec ta clé (après avoir vérifié leur authenticité, et là tu dois forcément faire confiance à la signature de quelqu'un d'autre), et garantir qu'un malware ou un intrus humain n'aient pas accès à cette clé (ce dernier point me paraît limite impossible si tu veux être en mesure de signer les mises à jour)) et seulement pour le noyau, pas pour le userspace.

et tu sais que même avec un boot et un userspace signé par tes soins, une tasse de café renversée peut bloquer l'accès à ton userspace ?... On a compris que tu pensais du mal du secure boot parce qu'il n'a pas été suggéré par la communauté linux et que le système qui a été choisi a en l'occurence été adapté pour un maximum de sécurité pour le quidam moyen...

1) se baser sur le fait que SB est "normalement" désactivable n'est pas une garantie suffisante

2) SB a tout son sens sur une machine de contrôle industriel, par exemple sur celles qui contrôlent les centrales nucléaires.

et pour éviter a madame michu de se choper des virus.

squalyl (./2054) :
1) se baser sur le fait que SB est "normalement" désactivable n'est pas une garantie suffisante

Le fait que ce soit désactivable est une des conditions exigées pour le logo W8, et c'est le cas pour tout le matériel connu. S'il y a du matériel foireux, c'est la faute du matériel, il y aura toujours du matériel trop bogué pour faire tourner le système.

2) SB a tout son sens sur une machine de contrôle industriel, par exemple sur celles qui contrôlent les centrales nucléaires.

Fedora n'est pas fait pour des utilisations critiques de ce genre. En particulier, il n'y a aucune certification pour l'utilisation dans les centrales nucléaires. (Il faut une certification spéciale pour tout logiciel qui est employé dans ce contexte.) (Et puis, les centrales nucléaires devraient être interdites tout comme Restricted Boot. )

et pour éviter a madame michu de se choper des virus.

Et comme déjà expliqué, ça ne marche pas du tout pour ça, parce que ça ne protège que le démarrage et pas le userspace!

Kevin Kofler (./2055) :

squalyl (./2054) :
1) se baser sur le fait que SB est "normalement" désactivable n'est pas une garantie suffisante

Le fait que ce soit désactivable est une des conditions exigées pour le logo W8, et c'est le cas pour tout le matériel connu. S'il y a du matériel foireux, c'est la faute du matériel, il y aura toujours du matériel trop bogué pour faire tourner le système.

C'est hallucinant de voir à quel point tu es présomptueux... Tu fais partie de la "team" Fedora donc tu penses que le système est si parfait que s'il y a un bug, c'est forcément la faute au matériel

Si on ne peut pas désactiver Restricted Boot, c'est la faute du matériel, étant donné que la spec exige clairement que ce soit possible. C'est tout ce que j'ai dit!

ok, admettons que ce soit tjs possible, et mettons de coté le cas Michu; le coté défi technique "faire marcher linux sans désactiver SB, juste pour le plaisir d'obliger MS a signer un truc tiers", tu le places où?

Y a pas les schémas de la manette Steel Battalion qui traînent sur le net?

Avec le schéma et les bons matériaux je me demande si je serais capable d'en refabriquer un de récup', genre en carton

squalyl (./2058) :
ok, admettons que ce soit tjs possible, et mettons de coté le cas Michu; le coté défi technique "faire marcher linux sans désactiver SB, juste pour le plaisir d'obliger MS a signer un truc tiers", tu le places où?

Il n'y a aucun défi là, juste 100 dollars à verser (à Verisign, il paraît, même s'il n'est pas transparent à 100% où finit la somme versée à ce service).

alors je vois pas l'intéret du débat en entier.

Alors déjà, Red Hat a versé au moins 100 dollars (probablement plusieurs fois 100 dollars, parce que shim évolue) à un cartel monopolisant les signatures. Et ensuite, si on proteste, c'est à cause de ce que ça représente, et des restrictions des libertés qui vont avec. Pour moi, Restricted ("Secure") Boot tel qu'il est conçu est fondamentalement incompatible avec le principe du logiciel libre. Les développeurs de shim ont trouvé un workaround pour permettre un compromis (les fameux "machine owner keys" (MOK)), mais ça reste inutilement compliqué à utiliser (plus compliqué que de désactiver tout le bordel tout simplement) et il reste des restrictions (le noyau en mode "secure" interdit tout ce qui pourrait modifier le noyau: accès à la mémoire en userspace (même pour root), accès aux ports I/O en userspace (même pour root), chargement de modules non signés etc.). (Et puis, cette solution n'était pas prévue au départ quand le "feature" était déjà accepté pour Fedora, ça a été une idée de openSUSE.)

mais puisque ça marche sans secure boot, avec garantie que SB est désactivable, où est le pb

1. Que le support de "Secure" Boot de la part de GNU/Linux risque de rendre cette "fonctionnalité" non-désactivable dans le futur, avec l'argument que "de toute façon, les systèmes d'exploitation tiers le gèrent aussi, donc pourquoi le rendre désactivable".
2. Que ce n'est pas acceptable que GNU/Linux boote en mode non-libre par défaut (et AMHA, même qu'un tel mode non-libre existe – libre ou rien!).
3. Que ça n'apporte strictement rien parce qu'il est très simple de désactiver "Secure" Boot (et notamment beaucoup plus simple que la procédure très compliquée qu'il faut suivre pour utiliser un noyau modifié en mode "secure"). N'importe qui peut le faire. (Je me rappelle une époque où il fallait désactiver "Plug&Play Operating System" dans le BIOS ou Red Hat Linux ne démarrait pas du tout, ce n'était pas un vrai obstacle non plus.)
4. Que ça gaspille des ressources et crée des limitations pour tout le monde, par exemple, "Secure" Boot a été une des raisons des délais de Fedora 18.
5. Que Red Hat verse au nom de Fedora de l'argent au cartel qui monopolise les signatures.

Nhut (./2059) :
Y a pas les schémas de la manette Steel Battalion qui traînent sur le net?

C'est un périphérique USB, donc c'est quand même plus compliqué que les manettes des vielles consoles. De plus on ne peut pas se baser sur une manette Xbox normale, parce qu'il y a beaucoup plus de boutons.

Cependant ça doit être possible d'émuler la puce qu'il y a dedans et de faire un clone de la manette (à moins qu'ils aient délibérément compliqué les choses, mais je ne vois pas pourquoi, à priori). Tu devrais lancer l'idée dans la section Mecha du forum RGC, je suis sûr que certains seraient très intéressés

Kevin Kofler (./2064) :
1. Que le support de "Secure" Boot de la part de GNU/Linux risque de rendre cette "fonctionnalité" non-désactivable dans le futur, avec l'argument que "de toute façon, les systèmes d'exploitation tiers le gèrent aussi, donc pourquoi le rendre désactivable".
2. Que ce n'est pas acceptable que GNU/Linux boote en mode non-libre par défaut (et AMHA, même qu'un tel mode non-libre existe – libre ou rien!).
3. Que ça n'apporte strictement rien parce qu'il est très simple de désactiver "Secure" Boot (et notamment beaucoup plus simple que la procédure très compliquée qu'il faut suivre pour utiliser un noyau modifié en mode "secure"). N'importe qui peut le faire. (Je me rappelle une époque où il fallait désactiver "Plug&Play Operating System" dans le BIOS ou Red Hat Linux ne démarrait pas du tout, ce n'était pas un vrai obstacle non plus.)
4. Que ça gaspille des ressources et crée des limitations pour tout le monde, par exemple, "Secure" Boot a été une des raisons des délais de Fedora 18.
5. Que Red Hat verse au nom de Fedora de l'argent au cartel qui monopolise les signatures.

Va falloir te faire à l'idée que Red Hat veut gagner des sous, et que Fedora fait partie de cette stratégie

Bon, vous forkez ?

Moi j'en ai fini.

Ouais, pas sûr que ça serve à quelque chose de continuer le "débat".

Nhut (./2059) :
Y a pas les schémas de la manette Steel Battalion qui traînent sur le net?
Avec le schéma et les bons matériaux je me demande si je serais capable d'en refabriquer un de récup', genre en carton

Zerosquare (./2065) :
Tu devrais lancer l'idée dans la section Mecha du forum RGC, je suis sûr que certains seraient très intéressés