gratifiant > linux.debian.user.french

G2PC (27/12/2019, 21h20)
Protéger le Grub par mot de passe, ça c'est fait. Par contre, la console
du grub, pour la saisie du mot de passe, est en qwerty.
Mon clavier est un clavier USB.

J'ai tenté deux méthodes pour obtenir une console en français, mais,
dans les deux cas, le clavier freeze :


J'en suis resté à cette synthèse :

Recherches complémentaires

Le mappage clavier n?est prévu que pour at_keyboard et pas pour usb_keyboard.
Il est bien précisé :
" If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout..."
Source :
Source :

Recherches complémentaires : grub-kbdcomp grub-mklayout azerty

Cette proposition ne correspond pas à mon attente, qui est de pouvoir saisir le mot de passe du Grub avec un clavier USB et non pas de rentrer dans la console du Grub pour y travailler en Azerty.
Grub azerty 2018 :

Cette proposition ne correspond pas à mon attente, qui est de pouvoir saisir le mot de passe du Grub avec un clavier USB et non pas de rentrer dans la console du Grub pour y travailler en Azerty.
Pour passer le clavier en azerty, depuis un terminal en Qwerty, utiliser la commande setxkbmap fr
Depuis un clavier Qwerty, saisir cette commande ainsi : setxkb,qp fr

Peut être que quelqu'un a une alternative fonctionnelle ?
Haricophile (03/01/2020, 18h10)
Le vendredi 27 décembre 2019 à 20:15 +0100, G2PC a écrit :
> Protéger le Grub par mot de passe, ça c'est fait. Par contre, la
> console du grub, pour la saisie du mot de passe, est en qwerty.
> Mon clavier est un clavier USB.


En sachant que c'est une protection très relative. Si on veut vraiment
protéger le système contre quelqu'un qui a accès à la machine, il faut
chiffrer le disque.
Pascal Hambourg (03/01/2020, 21h10)
Le 03/01/2020 à 16:59, Haricophile a écrit :
> Le vendredi 27 décembre 2019 à 20:15 +0100, G2PC a écrit :
>> Protéger le Grub par mot de passe, ça c'est fait. Par contre, la
>> console du grub, pour la saisie du mot de passe, est en qwerty.


Si le but est seulement de taper un mot de passe en AZERTY, il me semble
que le plus simple est de définir comme mot de passe l'équivalent en
QWERTY de ce qu'on veut taper en AZERTY. Cela exclut les caractères
spéciaux à taper avec AltGr ou une touche morte, mais il en reste encore
pas mal.

> En sachant que c'est une protection très relative. Si on veut vraiment
> protéger le système contre quelqu'un qui a accès à la machine, il faut
> chiffrer le disque.


Ce n'est pas suffisant. Le chiffrement seul protège contre la
divulgation des données en cas de perte ou de vol, mais pas contre une
intervention illicite non détectée sur la partie du système qui doit
inévitablement rester non chiffrée. Ne pas oublier qu'une installation
standard de Debian avec chiffrement laisse l'intégralité de /boot en
clair, ce qui inclut le chargeur d'amorçage, l'image du noyau et
l'initramfs. GRUB et le noyau peuvent être protégés par le secure boot
UEFI, mais pas l'initramfs ni la configuration de GRUB.
Pascal Hambourg (04/01/2020, 12h10)
Le 04/01/2020 à 02:50, G2PC a écrit :
> Pour ma part, j'ai comme un doute pour le secure boot UEFI.


Un doute à propos de quoi exactement concernant le secure boot ?

> J'ai installé Debian, Windows, et, Mint, en dual Boot.
> Pour cela, j'ai bien du désactiver le secure boot UEFI depuis le BIOS.


Pourtant en principe ces trois OS sont compatibles avec le secure boot
(Debian depuis la version 10).

> Dès lors le chargeur d'amorçage, l'image du noyau et l'initramfs ne sont
> pas protégés ?


Non puisque le firmware ne va pas vérifier l'intégrité du chargeur
d'amorçage qui ne va pas vérifier l'intégrité de l'image du noyau et
ainsi de suite.

> Quels sont les conséquences ? Le chiffrement du disque pourrait alors
> être rendu inopérant ?


Un attaquant qui a un accès physique à la machine pourrait modifier
l'initramfs pour intercepter et enregistrer la phrase de passe de
chiffrement, attendre qu'un utilisateur légitime tape la phrase de
passe, puis la récupérer et déchiffrer le disque.

Mais une telle modification est détectable en introduisant dans la
partie chiffrée du système (inaccessible à l'attaquant tant qu'il n'a
pas récupéré la passphrase) une vérification de l'intégrité des fichiers
de démarrage. Pour contrer cette protection, l'attaquant peut introduire
dans le noyau (image principale ou module inclus dans l'initramfs) un
rootkit qui masque les fichiers modifiés et présente les fichiers
originels à la place.

Le secure boot n'empêcherait pas la modification des fichiers de
démarrage mais empêcherait de démarrer avec un noyau compromis masquant
les modifications. Certes l'initramfs compromis pourrait aussi
désactiver la détection une fois le disque déchiffré avant de passer la
main au système principal, mais cela suppose que l'attaquant a une
connaissance a priori du mécanisme de cette détection, donc accès d'une
façon ou d'une autre au système déchiffré ou à ses spécifications.
Discussions similaires