INstall grub sur system chiffré

Support Debian
1

Bonjour,
J’ai une machine virtuelle Virtualbox avec EFI activé installée de la façon suivante:

  • Un seul disque
    • Deux partitions
      • sda1 => /boot/efi
      • sda2 => luks

La partition sda2_cryp contient un volume group LVM avec les volumes montés sur les répertoires suivants:

  • /boot
  • /
  • /home
  • /var
  • /var/log
  • /var/log/audit
  • /var/tmp
  • /tmp
  • swap

Lors de l’installation, l’installer n’est pas capable d’installer grub, donc je l’ai fait manuelle via le mode rescue:
un fois monté tous les répertoires ci-dessus:
grub-install
update-grub

j’obtiens bien les fichiers voulus dans /boot/efi et dans /boot
Pourtant le démarrage ne fonctionne pas.

Les fichiers grub:
/etc/default/grub:
grub.txt (1,9 Ko)

/boot/grub/grub.cfg :
grub.cfg.txt (244 Octets)

/boot/efi/EFI/debian/grub.cfg:
boot_grub.cfg.txt (6,7 Ko)

AU reboot, je tombe directement sur le shell EFI.

Le seul message d’erreur que j’ai, c’(est celui que les variables EFI ne sont pas prisent en copte sur ma machine.
Pourtant, l’installer boot en UEFI, la machine est bien configuré en EFI. Pas de sécure boot,

J’ai testé la même installation mais sans le chiffrement du disque, et il marche très bien.>

J’en perd mon latin, et ça fait déjà au moins une 20aine de tests que je fait dessus.

2

A quel moment ?
efivarfs était-il monté dans /target lors de l’exécution de grub-install ?
Sinon, as-tu installé une copie de GRUB dans le chemin de support amovible (–force-extra-removable --no-nvram) ?

PS : quel intérêt d’avoir /boot dans un LV séparé ?

3

Quand je suis en mode rescue avec la commande grub-install ou bien efibootmgr -v

j’ai monté efivars avec

mount -t efivarfs none /sys/firmware/efi/efivars

puis

grub-install --force-extra-removable --no-nvram

efibootmgr -v me donne:

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0003,0005,0006,0002
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N…YM…R,Y.
Boot0002* UEFI VBOX HARDDISK VBba62e428-eeaef6f3 PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N…YM…R,Y.
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* debian HD(1,GPT,8b53b753-0338-4386-a42c-8d5a343b9601,0x800,0x68800)/File(\EFI\debian\shimx64.efi)
Boot0005 EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0006* UEFI ORCL-VBOX-NVME-VER12 VB1234-56789 1 PciRoot(0x0)/Pci(0xe,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)N…YM…R,Y.

Quand j’ai redémarré, je suis revenu au shell efi pour entrer mon mot de passe de la partition chiffrée.

image
image1091×217 9.53 KB

Et ensuite je me retrouve sur le shell grub directement dans lequel je ne vois que les partition de base (/boot/efi et la partition chiffrée).

image
image1079×260 8.06 KB

image
image1088×289 8.71 KB

Un vieux reste, et sait-on si je n’ai pas prévu assez de place. Ceci dit je crois que l’installer en mode preseed génère u ne erreur comme quoi la partition /boot n’existe pas. A cause de ça je l’ai laissé et comme ça ne gène en rien.
Ceci dit, il me semble que le seul moyen d’avoir une installation LVM over LUKS pour laquelle l’installation de grub fonctionne c’est justement en ayant une partition /boot indépendante, malheureusement hors LVM.

4

Et je ne peux plus boot sur une ISO maintenant. Donc soit j’arrive à boot avec le shell grub, soit je refais un nouveau disque sur la VM.

car impossible de déchiffrer ma partition, pourtant le mot de passe est très simple vu que c’est un test.
Mais il le refuse, je ne sais pas pourquoi:

insmod cryptodisk
insmod luks
insmod lvm
insmod ext2
cryptomount -a
5

Ça ne sert à rien si ensuite tu exécutes grub-install avec --no-nvram.

Pas clair. Ce n’est pas le shell EFI qui demande la passphrase du volume chiffré, c’est GRUB.
Si je comprends bien, c’est l’ouverture du volume chiffré par GRUB (cryptomount) qui ne marche pas. Est-ce que tu as créé le volume chiffré avec des options supportées par GRUB ? Le format par défaut est LUKS2, qui n"était initialement pas supporté par GRUB. Si je me souviens bien (et j’ai la flemme de vérifier), le support de LUKS2 a été ajouté dans GRUB 2.06 (à moins que ce soit en version 2.12), mais l’algorithme PBKDF par défaut est argon2i qui n’est pas encore supporté par GRUB. Il faudrait donc essayer d’enregistrer la passphrase dans un nouveau keyslot en forçant l’algorithme pbkdf2.

Je ne vois pas le rapport. Plus on segmente, plus on augmente le risque de manquer d’espace dans un segment.

Pas hors LVM mais hors du volume chiffré. GRUB et l’installateur supportent parfaitement /boot dans un volume logique non chiffré.

Je ne vois pas le rapport avec ton installation chiffrée. C’est le BIOS/UEFI qui boote sur tel ou tel support, et il se fiche éperdument que le disque soit chiffré.

6

J’avais oublié cette histoire de pbkdf2. Pourtant je le savais, mais j’avais mis de coté le sujet depuis si longtemps que je l’avais oublié.
D’ailleurs je dois entrer le mot de passe deux fois:

  • Une fois pour le lancement de grub
  • Une fois pour le lancement du système

C’est problématique car dans le cas du premier le clavier est en qwerty…

7

GRUB a besoin de la passphrase pour accéder à /boot/grub et charger le noyau et l’initramfs. Ensuite, le noyau prend la main, oublie tout ce que GRUB a fait et l’initramfs a besoin de la passphrase pour accéder à la racine (en attendant un hypothétique mécanisme permettant à GRUB de transmettre la passphrase au noyau, comme plymouth le fait avec systemd). On peut éviter que l’initramfs redemande la passphrase en enregistrant celle-ci (en clair) dans l’initramfs à partir d’un fichier spécifié dans /etc/crypttab. Comme l’initramfs est dans le volume chiffré, la passphrase est protégée quand le système ne tourne pas. Par contre avec les permissions par défaut le contenu de l’initramfs est lisible par tous les utilisateurs quand le système tourne. Restreindre les permissions sur /boot et le fichier de clé ne protège pas contre un attaquant qui aurait réussi à acquérir les privilèges root.

Par défaut GRUB utilise la disposition clavier du BIOS/UEFI, qui est généralement QWERTY-US, mais certains BIOS/UEFI permettent de définir la disposition du clavier (rare, je ne l’ai vu qu’une seule fois sur un PC portable HP). GRUB permet de générer et charger un fichier de disposition clavier mais la dernière fois que j’ai essayé ce n’était pas très fiable : cela nécessite de basculer du pilote console standard au pilote at_keyboard ou usb_keyboard qui ne fonctionne pas avec tous les ordinateurs, et certains caractères n’étaient pas disponibles (je ne me souviens plus si c’étaient les touches mortes ou la touche AltGr qui ne fonctionnait pas). D’autre part dans ton cas ça impose d’incorporer les modules nécessaires et le fichier de disposition clavier dans la core image de GRUB ou à la limite dans la partition EFI puisque le système est chiffré.

8

C’est tout à fait ça.

Je confirme. J’ai réussi à faire en sorte que grub soit en fr en utilisant un fichier layout dans grub.
Après pour la clef il est surement possible d’utiliser une clef USB pour la passkey. Mais je sais que ce n’est pas simple non plus, j’ai une nitrokey. Les pilotes à mettre en place permettent de gérer la clef en utilisatrion normale; mais je ne sais pas du tout si l’initramfs peut le faire aussi.
Il va falloir que je creuse ça.

Sinon ca a fini par marcher une fois modifié le PBKDF.

Lors de l’installation j’uitilise un keyfile, et la commande

cryptsetup luksChangeKey --pbkdf pbkdf2 --key-file keyfile

Le tout avec keyfile-size, --new-keyfile-offset etc…

9

Comment ?

Tu parles d’une clé USB de stockage (flash) ou d’une clé crypto genre yubikey ?

Et que devient ce keyfile ensuite ? Est-il copié dans le système cible pour être utilisé dans crypttab ?

10

Sur la première c’est faisable, sur un clef genre yubikey ou nitrokey c’est moins sur.

Non, comme l’installation est automatique (preseed simple-cdd), le fichier est sur l’iso d’installation. Lors du postinst il est utilisé pour modifier le PBKDF uniquement.
Mais rien n’est laissé sur la machine.
Après, lors du boot, c’est à toi de donner la passphrase. A moins d’utiliser une clef par exemple. Mais ça, je n’ai pas encore testé.

Il faut justement que je retrouve car j’ai perdu la méthode. J’ai bien le layout en français, mais il ne le prend pas en charge car il me manque un paramètre dans le grub.cfg ou le /etc/default/grub.