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 claudex . É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 Jarvis . É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 claudex . É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 bubar🦥 (Mastodon) . É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 Prosper . Évalué à 5.
En entreprise, certainement.
# Pfiou
Posté par passant·e . É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…
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Pfiou
Posté par nonas . Évalué à 10.
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 passant·e . Évalué à 4.
Une phalange et il sera excusé
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Pfiou
Posté par ʭ ☯ . É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 X345 . É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 Thomas Debesse (site web personnel) . É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 Sébastien Le Ray . É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 claudex . Évalué à 2.
On peut avoir accès à GRUB sans accès physique.
« 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: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par ʭ ☯ . Évalué à 3.
Il va falloir donner un cas d'accès distant à GRUB2 là…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
kvm ip, port série (accessible par une machine en réseau ou un machin ipmi, en réseau aussi), etc.
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 claudex . Évalué à 7.
Et plus simplement, le boitier dans une armoire fermée avec uniquement le clavier et l'écran qui sont accessibles.
« 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: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par ohm . Évalué à 5.
Clavier et écran sont pour moi dans la catégorie accès physique.
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par reno . Évalué à 2.
Certes mais il y a différents niveaux d'accès physique..
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par claudex . Évalué à 3.
Il faut définir accès physique alors, pour moi, on parlait d'accès physique au boîtier (pour pouvoir démonter le disque dur par exemple).
« 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par -=[ silmaril ]=- (site web personnel) . É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 Thomas Debesse (site web personnel) . Évalué à 2.
Euh, le kernel et l’initrd sont dans le volume chiffré chez moi, ainsi que
/boot/grub(et donc les 258.modqui sont dans/boot/grub/i386-pc/, ainsi que le fichiergrub.cfgqui 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 :À 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.cfget charger les fichiers demandés pour amorcer le système GNU/Linux ou autre chose.Si tu pars du principe que
/bootest 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 Thomas Debesse (site web personnel) . Évalué à 6.
Pour info, voici à quoi ressemble un "rescue shell" avec un disque entièrement chiffré (incluant GRUB excepté cette invite-là) :
Le “rescue shell” permet rien d’autre tant qu'on ne déchiffre pas un disque :
On peut seulement charger les modules suivants après avoir déchiffré le disque :
C’est après ce
cryptomountré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.cfgn’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, à partcryptomount,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 :
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 -=[ silmaril ]=- (site web personnel) . É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 Thomas Debesse (site web personnel) . Évalué à 6.
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).
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 variableGRUB_ENABLE_CRYPTODISKest placée ànpar 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
/bootséparée pendant six ans, et que cela fait au moins deux ans que j’inclus/bootet 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
/bootsé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’aptse 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/bootdans 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 khivapia . É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 Thomas Debesse (site web personnel) . Évalué à 9. Dernière modification le 21 décembre 2015 à 11:13.
Ubuntu, mais ça marche aussi sous Debian (même méthode).
Je n’ai jamais touché de ma vie à TrueCrypt. J’utilise donc le système LUKS.
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.
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/,/homeetswap. Après ça je formate mes volumes, je debootstrap sur /, puis chroot dessus pour créer le/etc/fstabet 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
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par Parleur . Évalué à 5.
Je veux, je veux, je veux. :-)
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par Parleur . Évalué à 3.
En fait, je viens de réussir à faire ça avec mes petits doigts boudinés et, surtout, ce tuto : http://missinglink.xyz/security/
Par contre, dans mes rêves, j'aimerai pouvoir modifier les options pour que le GRUB de Libreboot gère ça dès le début, plutôt qu'il ne me charge le GRUB du système entre deux.
[^] # Re: Il y a des gens qui comptent sur le mot de passe de Grub ?
Posté par Parleur . Évalué à 1. Dernière modification le 21 décembre 2015 à 15:26.
Et, au passage, configurer Libreboot pour qu'il soit en BÉPO par défaut, aussi, tu sais faire ? <3
# Gravissime
Posté par Christophe B. (site web personnel) . É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 Thomas Debesse (site web personnel) . Évalué à 3.
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 gUI (Mastodon) . Évalué à 4. Dernière modification le 18 décembre 2015 à 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 :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Gravissime
Posté par Sufflope (site web personnel) . Évalué à 6.
Et encore t'as pas vu le traitement de l'information sur des sites professionels (au cas où l'italique n'est pas assez explicite, je vais rajouter : lol) comme ZDNet. Ca s'est transformé en quelque chose comme un bug dans Linux donne accès aux informations cryptées (véridique).
[^] # Re: Gravissime
Posté par n0wic . Évalué à -7.
Aller sortons les dossier c'est la fin de l'année.
Linux n'est pas secure c'est bien connu :
http://www.tux-planet.fr/grosse-faille-de-securite-dans-le-serveur-daffichage-xorg-1-11/
[^] # Re: Gravissime
Posté par xcomcmdr . Évalué à 4. Dernière modification le 18 décembre 2015 à 14:00.
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 Anonyme . Évalué à 1.
minima redémarrer Xorgrelancer ! c'est un logiciel comme un autre :)[^] # Re: Gravissime
Posté par groumly . Évalué à 4.
Le kernel aussi, a ce compte la.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Gravissime
Posté par Seb . É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 Christophe B. (site web personnel) . É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 Juke (site web personnel) . Évalué à 3.
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 Christophe B. (site web personnel) . É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 Christophe B. (site web personnel) . Évalué à -2.
Ah je vois que le service presse (ou plutot "mauvaise presse") de M$ est toujours actif :)
[^] # Re: Gravissime
Posté par pasBill pasGates . Évalué à -3.
Tout ce que cela signifie est que tu es incompétent pour administrer ces systèmes, et rien d'autre.
Non vraiment, arrètes de t'enfoncer, ce que tu écrit est totalement ridicule et faux.
[^] # Re: Gravissime
Posté par Kerro . É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 pasBill pasGates . Évalué à 7. Dernière modification le 20 décembre 2015 à 21:03.
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.
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.
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 Christophe B. (site web personnel) . É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 groumly . Évalué à 1.
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 Christophe B. (site web personnel) . Évalué à 3.
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 :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Gravissime
Posté par Kerro . Évalué à 8.
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 dyno partouzeur du centre . Évalué à 7.
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 GG (site web personnel) . Évalué à 4.
Tu écris qu'avec Machin tu ne chois pas à quel moment tu rebootes ton ordinateur? Tes sessions sont perdues?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Gravissime
Posté par Dr BG . É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 GG (site web personnel) . É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.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Gravissime
Posté par pasBill pasGates . É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 GG (site web personnel) . É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).
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Gravissime
Posté par Dr BG . Évalué à 5.
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 flan (site web personnel) . É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 Dr BG . É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 GG (site web personnel) . Évalué à 2. Dernière modification le 21 décembre 2015 à 17:43.
PBPG va probablement te recommander de défragmenter ton cerveau.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Gravissime
Posté par pasBill pasGates . É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 pasBill pasGates . É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 Dr BG . Évalué à 1. Dernière modification le 21 décembre 2015 à 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 GG (site web personnel) . É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+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Gravissime
Posté par xcomcmdr . Évalué à -2.
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 oinkoink_daotter . É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 oinkoink_daotter . Évalué à 3. Dernière modification le 22 décembre 2015 à 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 woprandi . Évalué à 1.
Et après des mises à jour ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.