Après moult efforts et tests, j’en suis venu à la conclusion que l’installateur Debian, en manuel ou en preseed, n’est pas capable d’installer correctement une configuration RAID1 qui comprenne une partition LVM (et ses volumes logiques dont /boot) et une partition EFI /boot/efi.
la difficulté consiste à ne faire le RAID1 de /boot/efi qu’avec des métadonnées en version 1.0.
Le seul moyen est de le faire en manuel à partie d’une installation système normalle sur le disque 2 avec partition /boot/efi et LVM.
Puis sur le disque 1 de répercuter le partitionnement (en utilisant sfdisk pour dump la configuration dans un fichier, la modifier pour le disque 1 et partitionner) sur le disque 1.
Ensuite de créer le RAID1 sur le disque 1 en considérant les partition du disque 2 comme missing.
Copier le contenu des partitions du disque 2 vers le disque 1 (avec dd par exemple).
Ajouter ensuite les partition du disque 2 dans le RAID1.
La synchro se fera toute seule.
Ensuite il ne reste plus qu’à refaire l’installation de grub -efi par sécurité.
Puis
EDIT: j’ai enfin réussi à installer en preseed une machine en RAID1.
Après plus de 300 essais d’installation sur une VM tout de même j’ai trouvé le bond mix entre le preseed partitioning le late_command, et la partie boot loader.
j’ai du pour ça aller jusque dans les codes sources des différents partman pour y arriver.
Le temps de tout mettre au propre pour vous donner ça dans Trucs et Astuces.
Par contre, oubliez de faire du RAID+LUKS+LVM, l’installateur Debian en est incapable de façon correcte, et même en preseed c’est impossible sans usine à gaz.
Cependant, l’installation d’un système sur disque chiffré n’est pas suffisant.
Déchiffrer les disques en saisissant deux fois (par disque) la clef de déchiffrement n’est pas pratique (sans compter que lors de la demande en UEFI, il faut utiliser un clavier QWERTY!). L’"utilisation d’un device TPM2 serait complètement justifiée.
Cependant, si on considère cet article, Bypassing disk encryption on systems with automatic TPM2 unlock | oddlama's blog, il est assez facile de déterminer la clef stockée dans un device TPM2.
Utiliser une clef FIDO2 serait une solution, mais pas très pratique, et surtout, elle ne permet pas un redémarrage automatique ou à distance.
D’autant que la clef peut être perdue ou volée.
Reste qu’il y a quelques moyens pour garantir une certaine sécurité avec TPM2 (liste probablement non exhaustive mais déjà pas mal):
Votre noyau et initramfs sont tous deux signés et vérifiés (UKI ou MOK), ou vous utilisez PCR 9 avec un shim qui corrige les images au moment du démarrage. ATTENTION: UKI c’est à partir de Debian 13 Trixie, systemd-ukify n’existe pas avant.
Vous avez saisi une clé LUKS dans le TPM2 sur au moins PCR 7 (+9 si nécessaire).
Si vous décryptez plusieurs périphériques dans l’initrd, leur ordre de déchiffrement est déterministe.
Après déchiffrement - et avant que tout exécutable utilisateur soit appelé - l’initramfs vérifie l’identité de tous les disques chiffrés, de préférence en mesurant une dérivée de la clé de volume dans PCR 15 pour chaque disque.
Le shell d’urgence de votre initrd (s’il y en a un) est protégé par mot de passe.
Votre chargeur de démarrage ne vous permet pas de modifier la ligne de commande du noyau, ou vous avez inclus un PCR utilisé dans l’enrôlement des clés LUKS qui dépend de la ligne de commande du noyau.
Avec Secure Boot, vous n’utilisez pas les certificats et clefs fournies (Debian ou Microsoft), car elles sont facilement utilisables par d’"autres. Cela signifie que vous devez avoir vos propres clefs dans la base Secure Boot et signer vous mêmes vos modules, noyaux et bootloaders. Ça implique aussi une partition /boot/efi nettement plus grosse qu’habituellement.
Ne me reste plus qu’à explorer tous ces points un par un
Je parlais précédemment du PCR 15 mais en fait c’est plutôt le 14 qu’il faut que je teste. pour le 15, il faut que relise plus clairement le document trouvé sur internet pour comprendre pourquoi il parle du PCR 15.
┌────┬────────────────────────────────────────────────────────────────────┐
│PCR │ Explanation │
├────┼────────────────────────────────────────────────────────────────────┤
│0 │ Core system firmware executable code; changes on firmware updates │
├────┼────────────────────────────────────────────────────────────────────┤
│1 │ Core system firmware data/host platform configuration; typically │
│ │ contains serial and model numbers, changes on basic │
│ │ hardware/CPU/RAM replacements │
├────┼────────────────────────────────────────────────────────────────────┤
│2 │ Extended or pluggable executable code; includes option ROMs on │
│ │ pluggable hardware │
├────┼────────────────────────────────────────────────────────────────────┤
│3 │ Extended or pluggable firmware data; includes information about │
│ │ pluggable hardware │
├────┼────────────────────────────────────────────────────────────────────┤
│4 │ Boot loader and additional drivers; changes on boot loader │
│ │ updates. The shim project will measure the PE binary it chain │
│ │ loads into this PCR. If the Linux kernel is invoked as UEFI PE │
│ │ binary, it is measured here, too. sd-stub(7) measures system │
│ │ extension images read from the ESP here too (see systemd- │
│ │ sysext(8)). │
├────┼────────────────────────────────────────────────────────────────────┤
│5 │ GPT/Partition table; changes when the partitions are added, │
│ │ modified or removed │
├────┼────────────────────────────────────────────────────────────────────┤
│6 │ Power state events; changes on system suspend/sleep │
├────┼────────────────────────────────────────────────────────────────────┤
│7 │ Secure boot state; changes when UEFI SecureBoot mode is │
│ │ enabled/disabled, or firmware certificates (PK, KEK, db, dbx, ...) │
│ │ changes. The shim project will measure most of its (non-MOK) │
│ │ certificates and SBAT data into this PCR. │
├────┼────────────────────────────────────────────────────────────────────┤
│9 │ The Linux kernel measures all initrds it receives into this PCR. │
├────┼────────────────────────────────────────────────────────────────────┤
│10 │ The IMA project measures its runtime state into this PCR. │
├────┼────────────────────────────────────────────────────────────────────┤
│11 │ systemd-stub(7) measures the ELF kernel image, embedded initrd and │
│ │ other payload of the PE image it is placed in into this PCR. │
│ │ Unlike PCR 4 (where the same data should be measured into), this │
│ │ PCR value should be easy to pre-calculate, as this only contains │
│ │ static parts of the PE binary. Use this PCR to bind TPM policies │
│ │ to a specific kernel image, possibly with an embedded initrd. │
│ │ systemd-pcrphase.service(8) measures boot phase strings into this │
│ │ PCR at various milestones of the boot process. │
├────┼────────────────────────────────────────────────────────────────────┤
│12 │ systemd-boot(7) measures any specified kernel command line into │
│ │ this PCR. systemd-stub(7) measures any manually specified kernel │
│ │ command line (i.e. a kernel command line that overrides the one │
│ │ embedded in the unified PE image) and loaded credentials into this │
│ │ PCR. (Note that if systemd-boot and systemd-stub are used in │
│ │ combination the command line might be measured twice!) │
├────┼────────────────────────────────────────────────────────────────────┤
│13 │ systemd-stub(7) measures any systemd-sysext(8) images it loads and │
│ │ passed to the booted kernel into this PCR. │
├────┼────────────────────────────────────────────────────────────────────┤
│14 │ The shim project measures its "MOK" certificates and hashes into │
│ │ this PCR. │
└────┴────────────────────────────────────────────────────────────────────┘
Mais dans tous les cas, il faut toujours entrer la passphrase au niveau de EUFI et en clavier QWERTY.
Je pense que seul l’UKI permettra de se passer de cette partie. Ou alors il faut recréer le shimx64.efi avec le bon keymap, et le chiffrer pour soit en accord avec les clef du Secure Boot.
Sachant, sauf erreur de ma part, que les PCR 0 à 7 sont tous résumé dans le PCR 7.
Pour le PCR 9, il faut refaire le systemd-cryptenroll à chaque fois que le grub est modifié (i.e.: en utilisant update-grub).
A ajouter dans la liste, intégrer un UEFI multipath au lieu d’une partition RAID. Car l’UEFI en RAID n’est pas bien pris en charge (ce qui implique une installation de grub avec l’option --no-nvram).
Je souhaite explorer cette méthode d’installation sans le RAID et sur un disque déjà occupé en partie par Windows, et je voulais savoir si l’approche suivante était donc valide :
sauter les étapes Création des partitions sur les disques et Création des grappes RAID1
aller directement à la section Suite du partitionnement et choisir l’espace libre sur le disque pour faire la partition chiffrée
Est-ce que j’oublie quelque chose dans les étapes « en moins » ?
oui. En fait dans truc et astuce tu as un tuto pour une installation complète d’une debian 12 (mais c’est pareil pour la 13 si ce n’est que tu as l’option systemd-boot à la fin en plus, au choix avec grub).
