Archlinux.fr [Forums]

Bonjour,

J'aurais besoin de vos lumières...
Le démarrage de mon ordi s'effectue par Grub, en dual boot avec un autre OS (pour les jeux).
J'ai installé un mot de passe sur Grub pour empêcher le démarrage de l'OS pour les jeux. Donc théoriquement on peut démarrer Arch sans mot de passe et on a besoin du mot de passe pour éditer le menu Grub ou lancer l'autre OS.

Mon problème : mon fils arrive à lancer l'autre OS et à jouer !
Un détail : il est en prépa dans une école d'ingénieur en informatique. D'après ce que j'ai compris il existe une faille dans Grub qui permet de contourner le mot de passe. Je crois comprendre qu'elle a été mise en évidence entre sept et déc 2016. Malheureusement mes recherches n'ont rien donné. Je sais par contre qu'il est possible de corriger cette faille (ça a été fait dans son école), mais je ne sais pas comment...

L'objectif : que mon fils travaille plus et joue moins !

Une petite idée ?

Merci d'avance

Bonjour,
Tu ne vas pas aimer mon début de réponse...
Ceci n'est pas la bonne solution, quand tu as un accès physique au pc tu peux presque tout faire... Oui il y a des solutions qui seront bien plus difficiles à contourner, mais désolé cela ne servira à rien, s'il ne veut pas travailler alors il ne le fera pas, après ce n'est qu'une question d'éducation...

De plus le plus simple est de lui demander comment il fait... Après je te laisse le soin de régler le "problème" à ta manière.

Mais comme c'est toujours mieux de sécurisé son PC quelque soit la raison =>
Pour bloquer le PC tu devras faire ceci (à bien sûr faire dans l'ordre inverse, sinon tu risques de ne plus pouvoir utiliser ton propre PC) :

• Sceller le PC de telle manière qu'il ne puisse être ouvert...
• Configurer le firmware du PC pour ne démarrer que sur Grub et aucun autre device (clé USB, CD, ...)
• Mettre un mot de passe au BIOS
• Verrouiller Grub (apparemment c'est déjà fait)
• Mettre à jour Grub en version 2:2.02-1 puis refaire l'installation de Grub via grub_install en ayant au préalable supprimé toute trace du Grub existant. Car tu es sûrement affecté par ce bug (trouvé en 5s de rechercher) : http://thehackernews.com/2015/12/hack-l ... sword.html
• Être sûr qu'il ne possède aucun droit d'admin ni les moyens pour le devenir...

Bref, pour aider à sécuriser le tout, peux tu donner le mode de boot (UEFI ou legacy/MBR) ? Comment est installé actuellement Grub ? Je te conseil une installation intégrale dans la partition ESP (voir Wiki anglophone).

Merci d'avoir pris la peine de me donner des idées.

- le mieux c'est le boitier avec une clé mais celui-ci n'en a pas...
- pas encore de mot de passe bios, mais de toute façon il passe par le grub
- Grub à jour (j'ai oublié de le préciser) et réinstallé après mise à jour
- pas de droit admin ni rien du tout (il n'a même pas de compte sur cet ordi, donc ne peut se connecter sous Arch)
- faille plus récente que 2015 (cette faille de 2015 est corrigée dans la version grub d'Arch)

Et le meilleur : il ne veut pas me dire comment il fait !!! Sinon ce serait déjà corrigé...

Je crois que l'ordi va changer de pièce. Ce sera peut-être le plus sûr.

Comment es tu certain qu'il passe par Grub ? Comment est installé ton Grub (UEFI avec une partie dans l'ESP et le reste dans /boot, UEFI intégralement dans l'ESP ou, legacy/MBR) ?
Si UEFI quel est le contenu de la partition ESP ?
Es tu vraiment certain d'avoir un Grub à jour ? Dans le menu de Grub, tout en haut, il y a la version d'indiqué, qu'est ce qui est affichée ?
La faille indiquée (il y en a peut être d'autres) a été corrigé dans les dépôt de Arch Linux le 2016-07-29.

benjarobin a écrit : ↑lun. 01 mai 2017, 17:48 Comment es tu certain qu'il passe par Grub ? Comment est installé ton Grub (UEFI avec une partie dans l'ESP et le reste dans /boot, UEFI intégralement dans l'ESP ou, legacy/MBR) ?
Si UEFI quel est le contenu de la partition ESP ?
Es tu vraiment certain d'avoir un Grub à jour ? Dans le menu de Grub, tout en haut, il y a la version d'indiqué, qu'est ce qui est affichée ?
La faille indiquée (il y en a peut être d'autres) a été corrigé dans les dépôt de Arch Linux le 2016-07-29.

+1, d'autant plus si le bug a été corrigé.

Pour info syslinux dispose aussi de ce type de fonctionnalités.
https://wiki.archlinux.fr/Syslinux#S.C3.A9curit.C3.A9

Mais dans tous les cas, si tu ne restreins pas l'accès au bios c'est peine perdue...

- oui il passe par le grub, c'est sûr (il s'en vante et rie car je n'arrive pas à l'empêcher). Un jour je suis arrivé alors qu'il allait se connecter et il était bien sur le grub.
- certes, ce n'est pas bien de ne pas protéger le bios, mais actuellement il ne passe pas par là.
- grub est installé en UEFI comme expliqué ici : https://wiki.archlinux.org/index.php/GRUB#UEFI_systems
donc avec ESP et un répertoire /boot
- grub est à jour d'hier (et réinstallé)

Je reboot pour vérifier la version et je reviens...

Tu peux très bien passer par Grub via une clé USB ou un CD avec Grub dessus.

- bonne version du grub (vérifié au boot et d'après la version des dépôts)
- il était bien sous "mon" grub, sans clé branchée, ni CD
- ma partition ESP, montée sur /boot/efi/EFI/ (j'ai coupé la sortie Microsoft): - allez, je mets aussi un mot de passe au bios, mais cela risque de ne pas changer le problème...
- je crois comprendre qu'il arrive à contourner la demande de mot de passe, mais je ne suis pas certain (en entraînant un plantage ?). Il arriverait peut-être à accéder au shell grub et lancer ce qu'il veut ? Je patauge...

Sachant que la dernière version 2.02 de Grub sur git est le dernier commit, cela voudrait dire qu'il connaît une faille non connue ? Je n'y croit pas du tout !
Qu'elle est la version affichée ? Oui je veux voir la version, photo ou alors une description très très détaillée de la version affichée, merci
Peux tu donner aussi la sortie de : Mais je crains que l'on ne cherche bien trop compliqué... Il ne connaîtrait pas tout simplement le mot de passe de Grub ?
Comment as tu configuré le mot de passe de ton Grub ? Tu n'utilise quand même pas password ? Mais bien password_pbkdf2 ?
L'as tu changé ?

Plus simplement, quel est le contenu de ton grub.cfg

Je viens de lui tirer quelques vers du nez pendant le dîner..
Il vient juste de m'avouer qu'en fait il ne passe pas pas le grub (contrairement à ce qu'il disait jusqu'alors). Grub n'est pas en cause.
Donc il ne connaît une faille encore non connue !

En fait il m'a expliqué qu'il arrivait à lancer une console juste après le bios et juste avant le grub. Il n'est pas lui même très sûr de la nature de la console, console UEFI peut-être.

D'un certain coté ça me rassure sur ma configuration de grub (j’ai tout fait comme dans le wiki avec password_pbkdf2; grub.cfg n'est pas lisible par les utilisateurs, ...)
Je vais pouvoir relancer mes recherches sur le net.

En tout cas merci à toi pour ton aide.
Je ne mets peut-être pas tout de suite en "résolu" mais dès que j'aurais trouvé la solution pour la partager (?).

La solution je te l'avais indiqué dès mon premier message.
Il lance sûrement une console UEFI, rien d'extraordinaire donc... Avec le mot de passe au niveau BIOS il ne pourra plus le faire.

PS: Si tu utilises password_pbkdf2, ce n'est pas grave que ton grub.cfg soit lisible (mais bon c'est vrai c'est mieux qu'il ne le soit pas), c'est le principe d'un bon hash avec salt

Actuellement seul un mot de passe au démarrage de l'ordi, au début du lancement du bios, est efficace.

Après, je sais que dans son école, il a été mis un place un "patch" pour bloquer l'accès à la console UEFI, par contre je ne sais pas du tout comment cela a été fait. Je ne connais pas non plus la méthode pour accéder à la console.

Merci de ton aide +++