L'UEFI pourrissait déjà la vie des gens qui souhaitait installer un linux sur leur PC…
Maintenant arrive la "Virtualization-based Security". Ce serait un moyen de créer une "région sécurisée" dans la mémoire.
Et alors ?
Et alors, si vous aviez l'habitude de tranquillement vous évader de votre environnement Windows d'entreprise à coup de linux sous VirtualBox, pourquoi pas piloté par Vagrant, hé bien vous risquez de vous voir imposer Hyper-V comme solution unique de virtualisation pour d'obscures raisons de sécurité.
# Je ne suis pas sûr que tu aies bien compris
Posté par Renault (site web personnel) . Évalué à 10.
Mouais, je ne trouve pas personnellement que ce soit encore le cas aujourd'hui. Honnêtement, tu ne vois pas la différence.
L'UEFI apporte même un certain confort, tu peux faire du multiboot en te débarrassant de GRUB ou équivalent (car l'UEFI permet nativement de le faire lui même), tu as bien plus d'options et de souplesse qu'un BIOS traditionnel… Le partitionnement GPT c'est quand même agréable par rapport à son ancêtre.
Je ne vois pas en quoi cet article te permet d'aller vers ta conclusion.
De ce que j'en ai compris, le but est de sécuriser des logiciels sous Windows par des procédés matériels. Donc je ne vois pas le rapport avec la virtualisation habituelle type VirtualBox, et encore moins avec Linux qui virtualiserait un Windows. On ne parle que d'applications sous Windows…
De plus, ce qui est décrit est un cahier des charges pour définir ce qu'est un ordinateur sécurisé. Un peu comme Intel pour les Ultrabook. Cela ne va concerner que certains produits définis (probablement pour des professionnels) et n'empêchera pas de faire autrement (tout comme on a des ordinateurs portables non ultrabook). Mais les constructeurs ne pourront pas abuser d'un terme commercial autour de la sécurité de leur produit s'ils ne respectent pas le cahier des charges en question.
J'ai peut être mal compris de quoi il était question, mais pour l'instant je ne vois pas le lien entre l'article et ce que tu énonces.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par dantes94 . Évalué à 5.
"De ce que j'en ai compris, le but est de sécuriser des logiciels sous Windows par des procédés matériels. Donc je ne vois pas le rapport avec la virtualisation habituelle type VirtualBox, et encore moins avec Linux qui virtualiserait un Windows. On ne parle que d'applications sous Windows…"
J'ai peut-être mal compris son propos mais j'avais saisis la chose dans le sens inverse a savoir un environnement Windows qui ferait tourné une machine virtuelle VirtualBox contenant un OS Linux.
Après j'ignorais qu'il y avais des gens qui ont le besoin de "s'évader" de leur Windows en entreprise. C'est si terrible que ça d'utiliser Windows ?
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par jihele . Évalué à 10.
Ben oui. Windows ça sert juste à faire tourner Outlook et MS Office. Pour travailler il faut une VM.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à 8. Dernière modification le 08 novembre 2017 à 15:34.
Perso je fais l'inverse ca evite d'avoir des merdes et quand la VM devient trop grosse apres tous les update et bien je reinstalle (je copie la VM windows de base) ca me fait moins perdre de temps.
Autre avantage, vu que windows ne sait toujours pas faire des updates sans redemarrer le pc et le bloquer pendant des dizaines de minutes, je suis sur que cela ne m'arrive pas au mauvais moment.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par jihele . Évalué à 4.
On a pas toujours le choix. Je parle du point de vue du développeur dont la boîte impose l'environnement MS (Windows + Outlook + Office…). J'ai pas le droit de changer le système, mais je peux utiliser une VM pour
respirerbosser.Ça a des avantages aussi : je peux avoir plusieurs VM avec des environnements différents. Si je travaillais sur le système hôte, ce serait plus compliqué de mettre à jour tout le système car ça pourrait impacter les développements.
Dans la pratique, je bosse sur une VM Debian et j'ai une VM par version d'OS. Côté système hôte, j'ai le Windows livré avec l'ordi. La question du changement de version d'OS se pose pas trop. L'ordi mourra sans doute avec la même version. Et si je change d'ordi, je déplace mes VM et c'est bon.
Si j'avais un hôte Linux, peut-être que j'utiliserais des VM ou du Docker. Plus vraisemblablement, j'aurais la flemme et mettre ça en place et c'est pas si grave parce que je fais principalement du Python/virtualenv.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par ff9097 . Évalué à 7.
Pauvre développeur
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Psychofox (Mastodon) . Évalué à 2.
Soit-dit en passant tu peux déjà utiliser du docker sous windows avec des containers windows ou linux (bon il y'a une couche virtu derrière mais tu n'as pas besoin de la voir).
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Renault (site web personnel) . Évalué à 6.
Je pense qu'il faut arrêter avec le mythe de Microsoft ce sont des imbéciles qui ne savent pas faire des MaJ. Pour avoir bossé sur ce genre de sujet (pour des systèmes embarqués), c'est loin d'être des mauvais sur le sujet.
En fait installer à chaud la mise à jour d'un logiciel, c'est totalement stupide. Oui. C'est le meilleur moyen pour avoir des bogues difficilement reproductibles et compréhensibles, d'avoir une mise à jour que partielle ou d'avoir une corruption de sa machine.
Car, déjà, plus tu as de composants qui tournent, qui prennent des ressources et peuvent faire planter la machine, plus le risque que la MaJ n'aille pas au bout augmente. D'ailleurs, plusieurs distributions ont expérimenté dans leur vie des MaJ qui lancées depuis un terminal dans une console graphique posait des soucis.
En plus, pour qu'une MaJ soit bien appliquée, il faut très souvent relancer toute la machine. Sinon, les bibliothèques ou programmes bas niveaux que tu mets à jour ne seront pas rechargés, en mémoire tu auras l'ancienne version voire un mélange des deux. Et ce mélange peut mener à des problèmes assez amusants pour le système qui ne comprend pas forcément ce qui se passe (le chemin d'une bibliothèque nécessaire est le même que celui d'un autre programme déjà en mémoire, mais les fichiers diffèrent, ils vont tenter d'optimiser la consommation mémoire en partageant la bibliothèque alors qu'en fait ce sera potentiellement incompatible).
La seule façon de faire les MaJ à chaud, ce sont les applications dans des bacs à sable où il suffit de recharger le bac à sable et c'est bon car toutes les dépendances seront correctement rafraîchies. Bizarrement, les grands acteurs (Microsoft, Google et Apple, des branquignoles apparemment pour toi) appliquent cette politique : mise à jour système, il faut redémarrer pour l'appliquer (à chaud ce n'est que le téléchargement), si bac à sable (application de leur Store) suffit de relancer l'application.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à 10.
Je ne commmente pas trop le fait de redemarrer mais le fait que cela prenne parfois 30 minutes ou plus. Loi de Murphy aidant c'est toujours au mauvais moment. Je redemarre mon linux quand j'ai un kernel ou une libc6 updated (au minimum) mais le redemarrage c'est instantane, il ne me met pas un message "je fais un update" et il bloque a 17% pendant des dizaines de minutes.
Honnetement la facon dont Microsoft fait ses mises a jour moi ca me fait rigoler donc qu'ils continuent. Le nombre de fois ou je vois ma femme pester parceque son ordi fait une mise a jour au redemarrage et que cela prend le temps necessaire a installer 3 linux je ne les compte plus (1 fois par mois minimum). L'avant-derniere fois cela marchait tellement bien la mise a jour que le support pro de dell a fait une re-installation totale du PC (heureusement que les cles usb live avec linux existe pour faire la sauvegarde…) c'etait beau :).
Comme je refuse de m'occuper de ce genre de truc (je suis pas fou non plus apres je serais le responsable des problemes) je trouve le concept interessant a regarder.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Renault (site web personnel) . Évalué à 4.
Tu n'as pas lu tout ce que j'ai dit. Pour éviter qu'une MaJ foire, il doit être fait dans un environnement minimal. Pour Windows, Android ou macOS / iOS c'est au redémarrage de la machine. D'ailleurs, GNOME Logiciels (avec PackageKit) reprend également cette logique pour cette raison.
Après que ce soit trop long ou fait à des moments peu opportuns, je peux le comprendre mais c'est un autre sujet. Cela n'empêche pas que le redémarrage et l'installation dite hors ligne sont nécessaires.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à 3.
Tu veux dire que les mises a jour que je fais de linux depuis preque 20 ans ont toujours foires?
Curieux il ne me semblait pourtant, j'ai toujours pu utiliser mon ordi sans probleme avant, pendant et apres.
Je veux bien que pour un gros serveur cela soit necessaire de rebooter a chaque mise a jour (d'ou le fait que tu ais des soft vieux de 4 ans…) mais bon quand je fais une mise a jour de libreoffice je suis a peu pres persuade que un reboot est totalement inutile…
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par freem . Évalué à 5.
Il a dis que les mises à jour système nécessitent un reboot. Ce qui, en gros, veut dire les libs et programmes qui sont nécessaires à faire fonctionner ta machine et qui ne peuvent être déchargées aisément. En gros, le kernel, la libc, l'init. Dans une moindre mesure, X11 (il te faut au moins fermer ta session à priori), dbus & co.
LibreOffice ne fait pas vraiment partie de cette couche bas niveau la.
Après, je pense aussi que microsoft traîne pas mal de casseroles, je pense notamment au fait que le système dans son ensemble manque d'organisation au niveau des dépendances, ce qui fait qu'une lib sera bien souvent installée de nombreuses fois sur le système, et du coup la mettre à jour est loin d'être aussi rapide et «simple» que sur d'autres systèmes qui utilisent une hiérarchie plus clean, qui ont aussi plus de contrôle sur qui met quoi où: Microsoft n'a aucun contrôle sur ce que font les installateurs, ou presque. Tandis qu'avec des systèmes tels que Debian, ou l'immense majorité des paquets installés (je parle du cas que j'imagine le plus répandu, pas des machines avec des chiées d'images docker, de repo externes ou de trucs installés à coup de
make;make installproviens d'un dépôt maîtrisé par la distribution, c'est plus simple.[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à 3.
Ben oui je suis d'accord sauf que pour Microsoft MS Office fait parti du systeme une fois installer et que une mise a jour de ce derniere te reboot aussi ta machine.
Et cela c'est sans compter Edge (mise a joru de firefox je n'ai toujours pas besoin de redemarrer mon PC) and co.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Psychofox (Mastodon) . Évalué à 1.
Oui niveau casseroles c'est gratiné chez microsoft.
Sans vouloir se lancer dans le gros bordel qui traine dans la registry, un exemple bête :
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Christophe B. (site web personnel) . Évalué à 0.
Ma solution :
Le pc sous Linux avec Thunderbird et Libreoffice
Et des VM windows avec virtualbox (c'est plus simple a sauvegarder)
Et Double Boot : une petite partition juste de quoi installer quelques jeux …
Et j'évite les MAJ sauf pour Linux (et pour les jeux :) )
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par damaki . Évalué à 2.
Quand ton environnement cible en production est sous Linux, c'est quand même beaucoup plus simple d'avoir au moins une VM en local pour tester voire développer. Même le sous-système Linux pour Windows ne remplace pas une vraie VM, ou un conteneur si c'est votre préférence.
Après oui, s'évader de Windows est un peu exagéré.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à -3.
Ah ouias ca c'est super cool surtout quand c'est utilise dans les updates de Dell et que ce dernier ne peut plus redemarrer ton windows qui ne pointe plus au bon endroit. Histoire vecu (avec le pc de ma femme XPS13 et vous pouvez regarder sur le net pour verifier). Moi j'en rigole encore.
Sinon c'est super bien UEFI, tu as droit a encore moins d'option de configuration sur certains pc (lenovo pour ne pas les citer) qu'avec un bios.
Bon maintenant que les distribs linux ont le certificat de microsoft pour l'installation je dois avouer que c'est assez transparent donc cela n'a plus trop d'impact.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Anonyme . Évalué à 3.
Tu confonds la technologie EFI et son implémentation par les fabricants. Ce que j'ai pu constater c'est que même avant l'UEFI il y avait moins d'options de BIOS sur les portables que sur les fixes, d'autant plus quand ce sont des cartes-mères vendues à la pièce et pas des PC OEM. Aussi, le suivi des mises à jour est moins bon sur le bas de gamme que sur les configurations destinées aux joueurs mais ça aussi ça dépend des marques et des époques.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à -1.
Oui oui je "confond"… mais bon quand deux implementations par deux des plus gros vendeurs de PC du monde sont merdique.
Alors autant le probleme lenovo ok c'est lenovo qui fait le minima pour supported cette techno autant le probleme dell c'est la facon donc c'est utilise mais il est vrai que en bidouillant dans l'efi et en remettant la bon chemin ca permettait de fonctionner.
Mais bon desole autant je trouve la version apple comme etant vraiment fonctionnel autant la version PC est tout simplement merdique avec a peine une petite amelioration du bios et surtout pas les fonctionnalite interessante que j'ai vu sur Mac.
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Anonyme . Évalué à 2.
Il n'y a pas de version "PC" ou de version "Mac", c'est la même architecture x86_64 et la même technologie EFI. C'est comme si tu disais que le BIOS c'est de la merde parce que ceux de AMI ne sont pas au niveau de ceux de Phoenix que tu as testé. C'est uniquement l'implémentation qui est différente selon chaque marque et qui peut même être différente selon les gammes et les modèles.
Si les fabricants de portables font mal leur travail, ce n'est pas de la faute de l'EFI. Ça fait très longtemps qu'on trouve des BIOS tatoués qui contiennent une liste blanche des cartes d'extensions supportés, c'est un problème des équipementiers.
Sinon par curiosité, quelles sont les fonctionnalités intéressantes de l'UEFI que tu trouves sur Mac et pas ailleurs ?
[^] # Re: Je ne suis pas sûr que tu aies bien compris
Posté par Albert_ . Évalué à 2. Dernière modification le 10 novembre 2017 à 16:49.
Un collegue avait une sauvegarde de son systeme sur un DD externe. Une mauvaise mise a jour de MacOSX a casser le systeme. La "reinstallation" a ete faite en quelques minutes directement en brachant le DD externe. Me demande pas ce qu'il a fait ca fait quelques temps deja mais j'avais trouve ca bien cool.
Et oui je sais que le probleme c'est l'implementation et j'en ai donne deux exemples merdique (pour des raisons differentes) fait par deux des plus gros fabricants de PC.
# Best practices
Posté par Psychofox (Mastodon) . Évalué à 2.
Ce que je vois c'est que ce document est un simple document présentant les best practices pour avoir une sécurité au plus haut dans un environnement microsoft. On voit ce genre de documents pour tous types de matériels/logiciels.
Ce n'est donc pas une norme et rien qui soit destiné à pourrir le monde linux. De ce que j'en sais il y'a déjà plein de trucs dans ce document qui existent déjà (comme TPM par exemple) que tout un chacun peut décider de désactiver dans le firmware/bios de sa machine.
Du reste pendant des années les fabricants ont maintenu des firmware qui fonctionnent de façon bios legacy ou UEFI ce qui a fait que l'UEFI n'a jamais pourri la vie de qui que ce soit. Mon Linux boote très bien sur UEFI merci bien.
[^] # Re: Best practices
Posté par totof2000 . Évalué à 4.
C'est complètement faux : cf le problème de certificat Microsoft pour l'UEFI
Le mien aussi, mais il suffit de lire les forums pour se rendre compte que ça n'a pas toujours été le cas pour tout le monde.
[^] # Re: Best practices
Posté par Psychofox (Mastodon) . Évalué à 3.
Ouais dans le cas où tu insistais pour utiliser UEFI. Mais si tu passais en mode legacy il n'y avait aucune problème. Je n'ai personnellement jamais vu de firmware/bios pc qui ne fournissait pas ce mode legacy qui fonctionne comme un bios standard.
[^] # Re: Best practices
Posté par totof2000 . Évalué à 3. Dernière modification le 08 novembre 2017 à 21:41.
Ben j'en ai un (asus) qui n'a pas de mode legacy. Par chance, pas de problème pour installer un Linux dessus, mais je répète, regarde les forums, tu trouveras des messages de personnes qui ont eu des problèmes pour le faire. Alors certes c'est pas non plus tous les PC qui ont posé problème, mais il est faux de dire qu'il n'y en a pas.
[^] # Re: Best practices
Posté par Renault (site web personnel) . Évalué à 9.
De même qu'avec des BIOS bogué ou tatoué, tu n'étais pas à l'abri d'un soucis pour installer Linux non plus…
[^] # Re: Best practices
Posté par oinkoink_daotter . Évalué à 4.
Ca vraiment existé en vrai, des PC x86 pour lesquelles on ne pouvait pas désactiver secureboot (sans passer en mode legacy) ?
De mémoire, la polémique avait eu lieu lorsque les exigences de MS pour avoir le logo "designed for windows 8" étaient sorties, avant que ce ne soit implémenté sur les machines, et MS avait très rapidement précisé le truc.
[^] # Re: Best practices
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 11 novembre 2017 à 10:48.
Exactement. Je n'en ai jamais vu passer, j'ai jamais vu passer un nom de modèle où clairement tu ne pouvais pas mettre autre chose que Windows.
Et puis faut pas cracher sur UEFI tout de même : il offre juste la possibilité de ne booter qu'un OS signé, quel que soit cet OS. Si tu veux signer ton Linux et mettre les clés dans ton UEFI, c'est possible.
Ma bible sur le sujet : http://www.rodsbooks.com/linux-uefi/
Et avec ça, j'ai jamais été emmerdé, ni par Windows, ni par Ubuntu qui au début faisait vraiment de la merde et cassait le boot de Windows pour s'y mettre à la place (et mal booter Windows parfois).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Best practices
Posté par totof2000 . Évalué à 0.
Personne ne crache sur l'UEFI: il est ici question de se méfier des recommandations de Microsoft qui pourraient imposer des spécifications qui poseraient problème à ceux qui veulent utiliser des machines sans windows. La discussion a ensuite dérivé sur l'UEFI, qui pour certains n'a jamais posé de problème. Pour ma part, j'ai constaté que bien que pour moi ça se soit toujours bien passé, ça n'a pas été le cas pour tout le monde. L'un des exemples est le problème du certificat microsoft nécessaire pour démarrer un système sécurisé. Comme toujours ce n'est pas la techno en elle-même qui pose problème mais l'utilisation qui pourrait en être faite. Il est donc normal selon moi de rester vigilant (sans non plus tomber inutilement dans la paranoïa).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.