Journal Un mot de passe, ça s'efface chez Grub2

Posté par . Licence CC by-sa
Tags : aucun
20
17
déc.
2015

Une vulnérabilité de Grub2 a été trouvée à partir de la version 1.98 jusqu'à la 2.02. La vulnérabilité permet à des utilisateurs locaux de s'acquitter du mot de passe au boot. L'attaquant a alors accès au grub shell au bout de 24 frappes sur la touche Effacement.

Cela paraît assez énorme comme bogue. Et pourtant…

http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html

http://linux.slashdot.org/story/15/12/16/040223/0-day-grub2-authentication-bypass-hits-linux

  • # On veut des noms

    Posté par (page perso) . Évalué à 10.

    Il y a des gens qui utilisent le mot de passe dans grub ?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: On veut des noms

      Posté par . Évalué à 7.

      C'est probablement utile dans certaines situations. Par exemple dans une école où des mauvais plaisantains vont chercher à devenir root.

      • [^] # Re: On veut des noms

        Posté par (page perso) . Évalué à 3.

        Oui, je vous plusieurs cas d'utilisation théoriques, mais je demande si chier utilisé en pratique.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: On veut des noms

      Posté par . Évalué à 4.

      Oui, bien sûr ! Cela fait parti des outils de délégation de taches d'administration à différentes équipes de divers niveaux. C'est comme bloquer le bios par mdp. Perso je préfère mettre timeout=0 sur grub et grub2 (avec updatekernel=1). De toutes façons un hypothétique boot qui se passe mal à ce niveau là ne se résoudra pas tout seul, alors grub, à part pour les dev noyau…

    • [^] # Re: On veut des noms

      Posté par . Évalué à 5.

      En entreprise, certainement.

  • # Pfiou

    Posté par . Évalué à -9.

    12 pages pour expliquer qu'appuyer 28 fois sur backspace et ensuite enter fait planter grub. Mais ils n'ont pas balancé l'auteur du commit…

    • [^] # Re: Pfiou

      Posté par . Évalué à 10.

      Mais ils n'ont pas balancé l'auteur du commit…

      Je vois pas en quoi c'est vraiment pertinent.

      Voilà le commit
      http://git.savannah.gnu.org/cgit/grub.git/commit/?id=b391bdb2f2c5ccf29da66cecdbfb7566656a704d

      L'auteur est autant en cause que ceux qui ont accepté le patch et que tous les gens qui auraient du étudier le code en profondeur. En attendant, on était tous content d'avoir un chargeur de démarrage qui évolue et avec de nouvelles fonctionnalités.

      TL;DR : arrêtons de blâmer les gens qui bossent, apprenons tous des erreurs de chacun et avançons.

      • [^] # Re: Pfiou

        Posté par . Évalué à 4.

        Une phalange et il sera excusé

    • [^] # Re: Pfiou

      Posté par (page perso) . Évalué à 10.

      Ils expliquent en 12 pages comment ils ont trouvé moyen d'exploiter ce integer underflow… le 28 fois n'est pas là par hasard, c'est l'adresse mémoire écrasée qui est ainsi visée.

      Il faut arrêter de dénier un trou de sécurité. Oui il existait, et oui il a été bouché. Peu importe si vous n'utilisiez pas le mot de passe GRUB2, toute sécurité proposée et contournable est un bug.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Pfiou

      Posté par . Évalué à 10.

      Ouais, enfin si tu regardes les 12 pages, y'a 1/2 page qui explique pourquoi Grub plante quand on appuie 28 fois sur backspace (hint: c'est un unsigned underflow sur une variable qui est ensuite utilisée comme index dans un tableau). Ensuite le reste c'est comment exploiter cette vulnérabilité pour en faire une attaque. Et c'est pas complètement trivial, au moins pour les gens (dont je fais partie) qui sont pas spécialisés dans la sécurité. En plus le post est didactique et bien écrit, donc y'a vraiment pas matière à critiquer.

  • # Il y a des gens qui comptent sur le mot de passe de Grub ?

    Posté par (page perso) . Évalué à 0.

    Est-ce vraiment une sécurité ?

    J’attends de voir quand une pression sur une touche permettra décoder un volume chiffré avec cryptsetup.

    Note : Avec un volume chiffré, il suffit de valider par entrée pour avoir accès au grub shell… mais vous n’irez pas bien loin avec ça car vous n’avez même pas encore chargé les modules de grub pour démarrer un noyau, et qui restent illisibles.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

      Posté par . Évalué à 5.

      Et de toute façon sans chiffrement une machine à laquelle on a un accès physique est compromise…

    • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

      Posté par . Évalué à 10.

      Est-ce vraiment une sécurité ?

      Non, mais ils ont grub bien faire.

      -->[]

    • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

      Posté par (page perso) . Évalué à 6.

      Je me suis posé la même question mais oui il existe un risque: le shell grub-rescue et grub est assez complet pour permettre de modifier le kernel/initrd qui vont être utilisé pour le prochain boot et les compromettre en y integrant un keylogger/whatever et ainsi obtenir les codes de ton volume chiffré ou ceux de tes comptes

      • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

        Posté par (page perso) . Évalué à 2.

        Euh, le kernel et l’initrd sont dans le volume chiffré chez moi, ainsi que /boot/grub (et donc les 258 .mod qui sont dans /boot/grub/i386-pc/, ainsi que le fichier grub.cfg qui contient les différents ordres de démarrage), je t’assures que le shell rescue sur lequel je tombe quand je rate la saisie de mon mot de passe est vraiment très très limité, c’est celui qui tient dans les 446 octets avant la table de partition, et les quelques octets supplémentaires qui traînent entre la table de partition et la première partition. En gros, de pas chiffré il y a de quoi :

        1. afficher quelque chose de manière très limitée (genre vga ou un truc très basique)
        2. lire l’entrée standard (clavier) en très très limité (il n’y a même pas de boucle pour te redemander le mot de passe si tu échoues)
        3. lire une table de partition pour trouver l’adresse de ton volume chiffré
        4. déchiffrer les données du volume
        5. trouver l’adresse du volume logique de ton système de fichier
        6. trouver l’adresse des modules grub dans ton système de fichier

        À partir de là, GRUB charge des modules bien plus complet : affichage graphique avancée (plein de couleurs, pleine résolutions, images, polices de caractères…), prise en charge avancée des système de fichiers (avec même parfois le support de l’écriture dans certains cas), édition de texte, etc. Après ça GRUB peut interpréter le fichier grub.cfg et charger les fichiers demandés pour amorcer le système GNU/Linux ou autre chose.

        Si tu pars du principe que /boot est en clair (avec les modules de grub, l’initrd, le noyau etc.) l’accès physique au disque te permet déjà de placer ton keylogger dans l’initrd, pas besoin de t’embêter à démarrer grub pour ça.

        ___________
        Note : c’est ce que signifiait _« vous n’irez pas bien loin avec ça car vous n’avez même pas encore chargé les modules de grub pour démarrer un noyau, et qui restent illisibles »
        .

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

          Posté par (page perso) . Évalué à 6.

          Pour info, voici à quoi ressemble un "rescue shell" avec un disque entièrement chiffré (incluant GRUB excepté cette invite-là) :

          grub cryptodisk fail

          Le “rescue shell” permet rien d’autre tant qu'on ne déchiffre pas un disque :

          grub cryptodisk unable

          On peut seulement charger les modules suivants après avoir déchiffré le disque :

          grub cryptodisk rescue

          C’est après ce cryptomount réussi que l’on peut charger des modules pour charger un noyau, lancer un éditeur, charger un fichier de config, modifier le système de fichier s'il est accessible dans des conditions simplistes (systèmes sur volume chiffré ou lvm uniquement en lecture seule, sûrement à cause de la complexité tout simplement), ou lancer un shell GRUB normal à la place du shell de récupération. Ce que nous faisons ici puisque GRUB est correctement configuré. Autrement on pourrait tout faire à la main, chargeant le noyau et l’initrd depuis le volume désormais déchiffré. Pour l’annecdote, le module “configfile” qui va lire /boot/grub/grub.cfg n’est même pas encore chargé (il sera chargé en passant au shell normal, mais on peut le faire à la main), même ce module est laissé dans le volume chiffré. Il en est de même pour un module inutile et sans risque comme le module “font” qui permet d’afficher des caractères spéciaux (comme le cadre du menu). En gros, à part cryptomount, ls (qui liste les volumes disponibles) et des détails comme ça, absolument rien n’est accessible à celui qui n’a pas la clé de déchiffrement, pas même l’aide, autant dire qu’il ne va pas loin.

          Une fois le module normal chargé, on peut charger le shell, s’il y a un “mot de passe GRUB”, c’est ici qu’il est demandé, autant dire qu’il ne sert à rien du tout et que si tu arrives là, c’est que tu connais la clé du volume chiffré. Il n’y a pas de mot de passe GRUB, donc le menu s’ouvre à l’ouverture du shell normal :

          grub cryptodisk normal

          Mais si on n’avait pas le mot de passe GRUB, on pourrait simplement charger le fichier grub.cfg à la main ou lancer un noyau à la main. De toute manière, si vous êtes à ce niveau-là, le système de fichier est déjà compromis, le chiffrement est déjà cassé.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

            Posté par (page perso) . Évalué à 1.

            Ce n'est pas vraiment le cas d'usage typique… Je rencontre plus de systèmes avec un /boot en clair et le reste de l'OS sur un volume crypté que ton cas

            • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

              Posté par (page perso) . Évalué à 6.

              Je rencontre plus de systèmes avec un /boot en clair et le reste de l'OS sur un volume crypté que ton cas

              Dans ce cas il serait dangereux de croire que le mot de passe de GRUB serait une sécurité (une fausse impression de sécurité endort la vigilance).

              Ce n'est pas vraiment le cas d'usage typique…

              Et c’est vraiment dommage, GRUB est réellement capable de retrouver ses petits dans un système de fichier sur un volume logique dans un volume LUKS sur un RAID sur une partition GPT. Pourquoi se priver?

              Effectivement, il semble que les grandes distributions utilisent encore le schéma d’un /boot/ séparé en clair, et que pire, la variable GRUB_ENABLE_CRYPTODISK est placée à n par défaut ce qui empêche GRUB de s’installer dans une telle configuration (il suffit juste de la mettre à y).

              Je crois que j’ai utilisé la méthode /boot séparée pendant six ans, et que cela fait au moins deux ans que j’inclus /boot et donc GRUB dans le volume chiffré. Et ça marche très très très bien.

              En réalité, la seconde méthode est beaucoup plus pratique, car utiliser un /boot séparé, en plus d’être en clair, apporte le risque de remplir la partition, et cela m’est arrivé plein de fois à force de monter en version tous les six mois. Vous vous trouvez assez bête lorsqu’apt se vautre en pleine montée de version parce que la génération du nouvel initramfs s’est mangé la limite du système de fichier de /boot.

              Avec un /boot à part, il faut constamment s’assurer qu’il ne reste pas trop d’anciens noyaux à chaque mise à jour, c’est prise de tête, et c’est un truc à rendre le système indémarrable ! Le risque est trop grand et ça m’est arrivé souvent ! Vraiment, placer /boot dans le même système de fichier que / placé dans un même volume chiffré est la solution la meilleure, d’un point de vue sécurité, et d’un point de vue stabilité. Pourquoi s’en priver ?

              ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

          Posté par . Évalué à 3.

          Euh, le kernel et l’initrd sont dans le volume chiffré chez moi, ainsi que /boot/grub (et donc les 258 .mod qui sont dans /boot/grub/i386-pc/, ainsi que le fichier grub.cfg qui contient les différents ordres de démarrage)
          Question au passage, tu as fait ça comment ? Tu utilises quelle distribution ? C'est chiffré avec TrueCrypt ou bien les outils GNU/Linux standards ?

          Par exemple sous Debian cette option n'est pas proposée par défaut (seulement le chiffrement de tout sauf /boot).

          • [^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?

            Posté par (page perso) . Évalué à 9. Dernière modification le 21/12/15 à 11:13.

            Tu utilises quelle distribution ?

            Ubuntu, mais ça marche aussi sous Debian (même méthode).

            C'est chiffré avec TrueCrypt ou bien les outils GNU/Linux standards ?

            Je n’ai jamais touché de ma vie à TrueCrypt. J’utilise donc le système LUKS.

            sous Debian cette option n'est pas proposée par défaut (seulement le chiffrement de tout sauf /boot).

            Oui malheureusement, et Ubuntu ne fait que copier coller Debian là-dessus. Comme évoqué, c’est un truc à foirer son boot à l’ajout/mise à jour d’un noyau.

            Tu as fait ça comment ?

            En fait je n’ai pas utilisé l’outil de partitionnement de la distro depuis au moins 8 ans, parce que quand j’ai commencé à chiffrer (en utilisant un boot séparé), l’installeur ne permettait pas encore de le faire à l’installation. Aujourd’hui l’installeur propose de chiffrer à l’installation, mais pas comme je veux.

            Au début je lançais le CD d’installation, puis au moment venu de partitionner j’ouvrais un terminal et je faisais ma tambouille, puis je revenais à la procédure d’installation et sélectionnais les volumes créés. Désormais je fais ça a la méthode debootstrap : Je démarre sur une Debian/Ubuntu existante, je partitionne les disques avec GPT, je crée le RAID, je chiffre un volume dessus, je déchiffre le volume chiffré que j’emploie comme volume physique pour un groupe de volume dans lequel j’ajoute les volumes logiques /, /home et swap. Après ça je formate mes volumes, je debootstrap sur /, puis chroot dessus pour créer le /etc/fstab et le /etc/crypttab, active l’option de GRUB citée, installe GRUB dans le MBR, regénère l’initramfs et voilà.

            Je pourrais faire un journal si vous voulez.

            ce commentaire est sous licence cc by 4 et précédentes

  • # Gravissime

    Posté par . Évalué à 10.

    Mes collègues bossant pour le coté obscur n'ont pas manqué de m'envoyer le lien

    Je leur ai fais remarqué que pour une fois qu'il y avait une faille de sécurité autant diffuser l'information …

    Mais à leur remarque insidieuse : " des patchs a passer en vue (avec un smiley)"

    j'ai répondu que non … pour accéder au mot de passe de grub il fallait rebooter et comme cela n'arrivait que tous les 3 ans … pas la peine de se fatiguer

    Et à la fin de l'envoi je touche :

    "C'est sur que sur certain OS ou le reboot est considéré comme un remède il y a plus de risque"

    sur ce je leur ai souhaité de bonnes fêtes …

    • [^] # Re: Gravissime

      Posté par (page perso) . Évalué à 3.

      "C'est sur que sur certain OS ou le reboot est considéré comme un remède il y a plus de risque"

      Et il n’y a même pas l’option pour ce mot de passe, donc il n’y a même pas besoin d’appuyer sur une touche du clavier un certain nombre de fois, seulement laisser la machine démarrer.

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Gravissime

      Posté par . Évalué à 4. Dernière modification le 18/12/15 à 13:32.

      Je crois comprendre un sous-entendu de guerre de tranchées entre GNU/Linux et Windows. Mais là on parle de Grub, qui n'est ni l-un, ni l'autre.. ou les 2 : j'utilise Grub avec merveille pour mon double boot :)

    • [^] # Re: Gravissime

      Posté par . Évalué à 4. Dernière modification le 18/12/15 à 14:00.

      "C'est sur que sur certain OS ou le reboot est considéré comme un remède il y a plus de risque"

      C'était vrai du temps de Windows 98 (typiquement, les ressources Win16 non libérés par un programme Windows 16 bits -> au bout d'un moment il faut rebooter car y'en a plus. Mais du temps de Windows 9X, les logiciels Win16 c'était déjà dépassé). Faut se mettre à jour.

      Aujourd'hui, mettre à jour le pilote graphique sous Windows (depuis Seven) ne requiert pas le moindre reboot. Alors que sous Linux, il faut à minima redémarrer Xorg, et là autant tout rebooter. ;-)

      Et que dire du plantage du pilote graphique : Ecran noir sous Windows pendant une demi seconde, Xorg figé sous Linux. LOUL. :p

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Gravissime

        Posté par . Évalué à 1.

        minima redémarrer Xorg relancer ! c'est un logiciel comme un autre :)

        • [^] # Re: Gravissime

          Posté par . Évalué à 4.

          Le kernel aussi, a ce compte la.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Gravissime

        Posté par . Évalué à 2.

        je voudrais pas dire de bétise mais il me semble que c'est justement le boulot de KMS de supprimer ces comportements.
        par contre tous les pilotes ne sont pas développés pour KMS, en particulier les pilots proprio nvidia

      • [^] # Re: Gravissime

        Posté par . Évalué à 2.

        C'est toujours vrai … désolé
        Alors cela s'est bien amélioré, il faut quand même le dire mais … nombre de fois ou Outlook / Office (toutes versions confondues) et plein d'autres produits merdoie lamentablement et de manière bizarre
        ce à quoi je répond … reboot on en parle après … et que l'on en parle plus
        Bon c'est sur les versions clients ok …

        mais c'est pareil sur les serveurs … un produit mal écrit, ou du réseau pas franchement stable et tu peut être sur d'avoir des trous dans la mémoire
        Chose que Linux gèrent beaucoup mieux

        je peu comparer car le même produit peut tourner sous Windows ou Linux et yapafoto Linux est de loin beaucoup plus stable

        • [^] # Re: Gravissime

          Posté par (page perso) . Évalué à 3.

          ce à quoi je répond … reboot on en parle après … et que l'on en parle plus

          tu peux aussi leur dire de changer d'ordinateur, ce n'est pas pour autant que c'est une solution pertinente.

          • [^] # Re: Gravissime

            Posté par . Évalué à 1.

            Mais ça marche …

            Je sais c'est facile, mais bon mon boulot à la base c'est Administrateur Système UNIX / DBA Oracle
            mais l'utilisateur michu-lambda ne fait pas la différence et nous submerge de questions sur cet OS que l'on peut qualifier de merdique.

            Même IBM le sous entend

            mais bon patience, encore un peu et tout le monde sera sous Android ou IOS :)

            • [^] # Re: Gravissime

              Posté par . Évalué à -2.

              Ah je vois que le service presse (ou plutot "mauvaise presse") de M$ est toujours actif :)

        • [^] # Re: Gravissime

          Posté par . Évalué à -3.

          Alors cela s'est bien amélioré, il faut quand même le dire mais … nombre de fois ou Outlook / Office (toutes versions confondues) et plein d'autres produits merdoie lamentablement et de manière bizarre ce à quoi je répond … reboot on en parle après … et que l'on en parle plus

          Tout ce que cela signifie est que tu es incompétent pour administrer ces systèmes, et rien d'autre.

          mais c'est pareil sur les serveurs … un produit mal écrit, ou du réseau pas franchement stable et tu peut être sur d'avoir des trous dans la mémoire

          Non vraiment, arrètes de t'enfoncer, ce que tu écrit est totalement ridicule et faux.

          • [^] # Re: Gravissime

            Posté par (page perso) . Évalué à 6.

            Si tu avais une fois dans ta vie géré un parc un peu important de machines, tu saurais que oui, Office plantouille parfois et c'est (parfois) résolu en redémarrant le système. Et pas qu'Office. Mais aussi Exchange (souvent), et bêtement les processus systèmes (il y a 2 jours par exemple : impossible de faire un VSS sur un serveur. Rebooter a résolu le problème).

            En fait l'immense majorité des informaticiens le sait. Cela dit c'est bien plus rare ces dernières années. Mais toi tu es au dessus du lot. Tu sais gérer ces parcs beaucoup mieux que les autres.
            Et surtout, magie, tu sais faire en sorte que les logiciels ne cafouillent pas. Tu peux facilement devenir milliardaire avec ce don, pourquoi tu ne le mets pas en œuvre, hum ? Parce que c'est du flan ?

            • [^] # Re: Gravissime

              Posté par . Évalué à 7. Dernière modification le 20/12/15 à 21:03.

              Si tu avais une fois dans ta vie géré un parc un peu important de machines, tu saurais que oui, Office plantouille parfois et c'est (parfois) résolu en redémarrant le système. Et pas qu'Office. Mais aussi Exchange (souvent), et bêtement les processus systèmes

              Tu me fais rire ! Non c'est vrai, les bugs dans les produits Microsoft et spécifiquement Windows, moi je ne connais pas, il n'y a que toi et tes potes admins qui connaissent. Parce qu'au fond, toutes ces années que j'ai passé à Microsoft à corriger les bugs rapportés dans Windows en fait ça ne m'a rien appris du tout…

              Le truc out tu as tout raté est que :
              a) Oui redémarrer résoud le problème. Certainement. Je te dirais même que racheter une nouvelle machine, faire une réinstallation de l'OS et des softs résoudrait le problème aussi!

              b) En fait, redémarrer ou réinstaller l'OS ça résoudrait aussi à peu près tous les problèmes sous Linux aussi, et la plupart des autres OS. C'est juste une méthode totalement inefficace (perte de service, …) comparé à la possibilité de lire les logs, utiliser les diffèrents outils d'analyse disponible, … pour trouver quel est le vrai problème et dés lors pouvoir le résoudre sans redémarrer le système.

              c) La grande différence entre les 2 OS est que toi et Christophe êtes tout simplement incompétent pour résoudre les problèmes sous Windows, et plutôt qu'honnètement reconnaitre que vous ne savez tout simplement pas comment analyser et résoudre des problèmes sous cet OS comme vous le savez sous Linux, vous rejetez la faute sur l'OS.

              En fait l'immense majorité des informaticiens le sait. Cela dit c'est bien plus rare ces dernières années. Mais toi tu es au dessus du lot. Tu sais gérer ces parcs beaucoup mieux que les autres.

              Non, l'immense majorité des informaticiens sait que Windows, comme Linux, est un soft, que c'est une suite d'instructions qui s'éxecutent, que ce n'est pas de la magie noire, et que pour comprendre comment cet OS fonctionne et comment le remettre sur pattes quand il pétarde sans redémarrer il faut s'informer, lire des bouquins qui décrivent cet OS, etc… bref exactement comme avec Linux.

              Et surtout, magie, tu sais faire en sorte que les logiciels ne cafouillent pas. Tu peux facilement devenir milliardaire avec ce don, pourquoi tu ne le mets pas en œuvre, hum ? Parce que c'est du flan ?

              Non, parce que soit tu ne sais pas lire soit tu fais exprès et déforme mes propos. Je n'ai jamais dit qu'il n'y avait jamais de bugs et problèmes sous Windows. J'ai tout simplement dit que dans 99% des cas il n'y a pas besoin de redémarrer Windows pour régler le problème et qu'utiliser la méthode du redémarrage est une preuve d'incompétence.

          • [^] # Re: Gravissime

            Posté par . Évalué à 0.

            Salut pbpg

            Content de savoir que tu es toujours la …
            Et en pleine forme on dirait …

            Passes de bonnes fêtes …

        • [^] # Re: Gravissime

          Posté par . Évalué à 1.

          ce à quoi je répond … reboot on en parle après … et que l'on en parle plus

          Effectivement, une fois que tu leur a dit d'aller se faire foutre, ils vont pas revenir te voir, et se demerde tout seul vu que visiblement t'as pas envie d'aider.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Gravissime

            Posté par . Évalué à 3.

            Effectivement, une fois que tu leur a dit d'aller se faire foutre, ils vont pas revenir te voir, et se demerde tout seul vu que visiblement t'as pas envie d'aider.

            Déjà il faudrait que l'utilisateur lambda-michu s’achète un cerveau et le maintiennent à jour.

            Ensuite c'est pas parce qu'on est Administrateur Système que l'on connaît tout les systèmes, les questions sur Outlook, Excel, World ne font pas partie de notre domaine de compétence.

            Quand quelqu'un vient avec une question sur Unix Linux / Oracle pas de problème j'ai des réponses
            mais pas de questions (eh oui ça juste tourne tout seul)

            Mais c'est vrai que Microsoft lutte contre le chomage :)

            Pour un parc Windows le Ratio Admin système / employés idéal est de 1 pour 70 ( en moyenne c'est 242)
            Pour un parc MAC : 1 pour 5400

            Source

            Donc pour vous débarrasser des admin systèmes … acheter du MAC :)

      • [^] # Re: Gravissime

        Posté par (page perso) . Évalué à 6.

        Aujourd'hui, mettre à jour le pilote graphique sous Windows (depuis Seven) ne requiert pas le moindre reboot.

        J'apprécie beaucoup Windows (aucune ironie de ma part), mais je dois admettre que ce n'est pas tout à fait vrai ! Avec une carte Nvidia et une mise à jour du pilote graphique, j'ai du redémarrer Windows 10 car j'avais perdu un écran sur les deux.

        Bon, j'admet, cela ne m'est arrivé qu'une seule fois (alors que j'ai déjà eu plusieurs mise à jour du pilote graphique). Mais c'est pour dire que cela arrive encore de temps en temps :)

      • [^] # Re: Gravissime

        Posté par (page perso) . Évalué à 8.

        mettre à jour le pilote graphique sous Windows (depuis Seven) ne requiert pas le moindre reboot

        Par contre, changer le nom d'une machine Windows nécessite un redémarrage.
        Installer un scanner Xerox avec ses logiciels associés, pareil (idem pour les multifonctions Brother).
        Et il y a une tonne d'autres cas. À noter que la plupart de ces cas sont dus aux mauvais logiciels plutôt qu'au système d'exploitation.

        • [^] # Re: Gravissime

          Posté par . Évalué à 7.

          Et il y a une tonne d'autres cas. À noter que la plupart de ces cas sont dus aux mauvais logiciels plutôt qu'au système d'exploitation.

          Pourtant le Windows 10 familial ici est paramétré pour installer automatiquement pendant la nuit les mises à jour poussées par Microsoft et régulièrement le matin je le retrouve rebooté.

          • [^] # Re: Gravissime

            Posté par (page perso) . Évalué à 4.

            Tu écris qu'avec Machin tu ne chois pas à quel moment tu rebootes ton ordinateur? Tes sessions sont perdues?

            • [^] # Re: Gravissime

              Posté par (page perso) . Évalué à 3.

              C'est sûrement désactivable (j'espère), mais je me suis fait avoir avec l'ordinateur du boulot en ayant voulu laisser un traitement se faire la nuit.

              • [^] # Re: Gravissime

                Posté par (page perso) . Évalué à 2.

                Vu combien c'est pénible pour les utilisateurs, et n'avoir jamais lu de solutions à ce sujet, je ne crois pas.

                Une des solutions est d'utiliser Linux, c'est vrai, mais pour beaucoup d'utilisateurs c'est un trop gros changement.

                • [^] # Re: Gravissime

                  Posté par . Évalué à 0.

                  'deactivate automatic restart updates' sur Google ne me donne "que" 385'000 résultats, et les premiers résultats donnent la bonne marche à suivre.

                  Si tu n'as jamais vu de solution, c'est que tu n'as pas cherché.

                  • [^] # Re: Gravissime

                    Posté par (page perso) . Évalué à 4.

                    Oui, je n'ai jamais cherché, j'utilise Linux, et il n'y a pas ce défaut.

                    Je viens de lire quelques pages, par curiosité.
                    Franchement, on parle de redemarages, mais la config se fait dans démarrage… et encore, c'est un peu complexe pour y arriver. Bravo l'ergonomie (c'est une blague).

                    • [^] # Re: Gravissime

                      Posté par (page perso) . Évalué à 5.

                      Oui, je n'ai jamais cherché, j'utilise Linux, et il n'y a pas ce défaut.

                      Dans ce cas là, je ne vois pois pourquoi tu dis qu'à ton avis ça n'existe pas. Ton message précédent laissait sous-entendre que tu avais cherché sans trouver de solution.

                    • [^] # Re: Gravissime

                      Posté par (page perso) . Évalué à 3.

                      J'ai pourtant régulièrement des demandes de redémarrage pour finir les mises à jour sous Ubuntu. Certes, il ne redémarre pas tout seul, mais ça doit être facile à faire.

                  • [^] # Re: Gravissime

                    Posté par (page perso) . Évalué à 3.

                    Je viens de regarder et je suis assez perplexe. Une solution qui m'a l'air bien est d'activer l'option « Pas de redémarrage automatique avec des utilisateurs connectés pour les installations planifiées de mises à jour automatiques » dans gpedit.msc.

                    Cependant, la description de l'option dit que si la stratégie « Configuration du service Mises à jour automatiques » est désactivée, cette stratégie n’a aucun effet. Cette stratégie est en effet désactivée sur mon poste, mais Windows update dit que la mise à jour automatique est activée… Que va-t-il donc se produire si je l'active car cela semble pris en charge par ailleurs. On dirait une vieillerie pré-Windows 7 qui n'aurait pas été nettoyée, du coup, je ne sais pas si ça va marcher.

                    L'autre option que j'ai vu est de désactiver les mises-à-jour auto, mais je veux des mises-à-jour auto. Ce que je ne veux pas, c'est le redémarrage auto.

                    • [^] # Re: Gravissime

                      Posté par (page perso) . Évalué à 2. Dernière modification le 21/12/15 à 17:43.

                      PBPG va probablement te recommander de défragmenter ton cerveau.

                      • [^] # Re: Gravissime

                        Posté par . Évalué à 3.

                        La différence entre lui et toi et que lui pose des questions quand il ne sait pas quelque chose, alors que toi tu affirmes des choses sur un sujet dont tu n'as même pas pris la peine de t'informer.

                    • [^] # Re: Gravissime

                      Posté par . Évalué à 1.

                      Ce que tu dois faire est décrit ici :

                      http://www.laptopmag.com/articles/disable-automatic-restart-windows

                      N'oublie pas de redémarrer le service Windows Update.

                      • [^] # Re: Gravissime

                        Posté par (page perso) . Évalué à 1. Dernière modification le 21/12/15 à 21:37.

                        Ahah, merci pour l'astuce. Si je m'attendais à ce que l'on résolve mes problèmes Windows ici… ;-)

                        Après, c'était pas le peine de t'embêter à trouver un lien, j'avoue que je n'ai pas cherché plus que ça, j'ai juste regardé un peu les premiers résultats google après vos échanges.

                      • [^] # Re: Gravissime

                        Posté par (page perso) . Évalué à 1.

                        Et ça te semble une solution simple, sans risque?

                        Il est bien précisé (de mémoire, j'ai rien pour vérifier) que l'opération est dangereuse pour le système.

                        Peut être même qu'il faut les droits administrateurs d'ailleurs, ce serait préférable. Mais vu que la plupart des utilisateurs sont dans ce mode…

                        Franchement, ces différentes opérations sont complexes pour la plupart des utilisateurs.

                        A+

                        • [^] # Re: Gravissime

                          Posté par . Évalué à -2.

                          Peut être même qu'il faut les droits administrateurs d'ailleurs, ce serait préférable. Mais vu que la plupart des utilisateurs sont dans ce mode…

                          Euh non, c'est faux depuis Vista. Donc faux depuis bientôt 10 ans.

                          Depuis Vista, même les administrateurs sont constamment en mode utilisateur, sauf pour les opérations d'administration approuvées (soit via un prompt UAC, soit silencieusement si le niveau d'alerte UAC est bas ou désactivé).

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Re: Gravissime

                            Posté par . Évalué à 4.

                            Oui, mais non, ce n'est pas si simple.
                            Il existe plein de façons pour une cochonnerie de bypasser l'UAC, et un clic malheureux est de toute façon possible (Windows 7 a rendu le truc plus tolérable, genre quand tu bricoles dans program files, il ne te demande pas systématiquement de valider un popup UAC, par exemple si tu crées un répertoire et que tu le renommes ensuite. De mémoire vistouille était relou la dessus).

                            Donc du coup, les best practices, ca reste quand même de considérer qu'un gars qui a les droits admin est admin et qu'il vaut mieux avoir un compte normal normal et un compte admin considéré admin admin par personne. (pis des comptes nominatifs, des GPO pour l'audit et les logs, une forêt d'admin, … et on va s'arrêter là /o\).

                        • [^] # Re: Gravissime

                          Posté par . Évalué à 3. Dernière modification le 22/12/15 à 21:34.

                          C'est un long article pour expliquer qu'il faut créer une clef dans la BDR qui s'appelle HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoRebootWithLoggedOnUsers de type DWORD à 1. Ce n'est pas la mort, pas spécialement dangereux si tu ne fais pas n'imp (genre la roulette russe à supprimer des clefs au hasard) mais pas nécessairement à la portée de tout le monde.
                          L'article ne dit pas que c'est dangereux.

                          Mais tu aurais pu vérifier ça en un clic.

      • [^] # Re: Gravissime

        Posté par . Évalué à 1.

        Et après des mises à jour ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.