Installation Debian RAID1+LUKS+LVM

Tags: #<Tag:0x00007f74fa930780> #<Tag:0x00007f74fa9302d0> #<Tag:0x00007f74fa930028> #<Tag:0x00007f74d9b5fe28>

Bonjour,

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.

EDIT2: c’est fait ici.

Ce fil peut service pour les remarques quand à l’article de 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.

Ca y est!!! j’ai réussi à faire une installation RAID1+LUKS+LVM, avec /boot/efi dans un array raid et la partition chiffrée dans un autre.

C’est impossible en laissant complètement faire l’installateur:

  • il faut faire le RAID en console (à cause du metadata=1.0 pour raid1 /boot/efi
  • il faut changer le raid1 chiffrement en pbkdf2 aulieu de l’argon2i par defaut non modifiable de l’installateur
  • il faut installer grub-efi à la main en chroot

Ne me reste plus qu’à reproduire cette installation, et faire un tutoriel ensuite :smiley:

~# lsblk -f
NAME                       FSTYPE            FSVER            LABEL                  UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sr0                        iso9660           Joliet Extension Debian 12.11.0 amd64 n 2025-05-17-09-55-45-00                                
nvme0n1                                                                                                                                    
├─nvme0n1p1                linux_raid_member 1.0              dsrvtest04:0           dff35475-6e2e-2fae-d423-84b5651deca4                  
│ └─md0                    vfat              FAT32                                   765D-D9B9                               587,1M     2% /boot/efi
└─nvme0n1p2                linux_raid_member 1.2              dsrvtest04:1           398f3be0-3389-b7c3-5c60-a1caf810058d                  
  └─md1                    crypto_LUKS       2                                       1f51efbc-73d1-4014-a45e-1849d8268485                  
    └─md1_crypt            LVM2_member       LVM2 001                                FVfYlN-0oqz-1eue-Dyt6-5GmD-0UmX-B9c7UD                
      ├─vg01-swap          swap              1                                       db3c32a2-6a50-4b0a-98f4-da76b8fd1de4                  [SWAP]
      ├─vg01-boot          ext4              1.0              BOOT                   5744e2c2-5ca5-49e9-b164-d93fb351e6df    374,6M    24% /boot
      ├─vg01-root          ext4              1.0              ROOT                   5f97d1b9-a7fc-4799-9c83-23f66fb73a1a        7G    43% /
      ├─vg01-home          ext4              1.0              HOME                   3726460a-db98-4715-95ed-8404a6e267c3      4,2G     0% /home
      ├─vg01-var           ext4              1.0              VAR                    6826ee8c-c0bf-40eb-b7d6-552d8e303330      8,2G     4% /var
      ├─vg01-var_log       ext4              1.0              VARLOG                 829fe9db-26a4-41c9-8aa9-900571890b0c      4,2G     1% /var/log
      ├─vg01-var_log_audit ext4              1.0              VARLOGAUDIT            e3934a2c-2dd4-400e-ab3e-ff7109ffa3b4      4,3G     0% /var/log/audit
      ├─vg01-var_tmp       ext4              1.0              VARTMP                 547188cf-688d-4e69-adc5-b993d52de28e      1,7G     0% /var/tmp
      └─vg01-tmp           ext4              1.0              TMP                    1e490c97-23f2-410a-8223-fb25c412fa4f      1,7G     0% /tmp
nvme0n2                                                                                                                                    
├─nvme0n2p1                linux_raid_member 1.0              dsrvtest04:0           dff35475-6e2e-2fae-d423-84b5651deca4                  
│ └─md0                    vfat              FAT32                                   765D-D9B9                               587,1M     2% /boot/efi
└─nvme0n2p2                linux_raid_member 1.2              dsrvtest04:1           398f3be0-3389-b7c3-5c60-a1caf810058d                  
  └─md1                    crypto_LUKS       2                                       1f51efbc-73d1-4014-a45e-1849d8268485                  
    └─md1_crypt            LVM2_member       LVM2 001                                FVfYlN-0oqz-1eue-Dyt6-5GmD-0UmX-B9c7UD                
      ├─vg01-swap          swap              1                                       db3c32a2-6a50-4b0a-98f4-da76b8fd1de4                  [SWAP]
      ├─vg01-boot          ext4              1.0              BOOT                   5744e2c2-5ca5-49e9-b164-d93fb351e6df    374,6M    24% /boot
      ├─vg01-root          ext4              1.0              ROOT                   5f97d1b9-a7fc-4799-9c83-23f66fb73a1a        7G    43% /
      ├─vg01-home          ext4              1.0              HOME                   3726460a-db98-4715-95ed-8404a6e267c3      4,2G     0% /home
      ├─vg01-var           ext4              1.0              VAR                    6826ee8c-c0bf-40eb-b7d6-552d8e303330      8,2G     4% /var
      ├─vg01-var_log       ext4              1.0              VARLOG                 829fe9db-26a4-41c9-8aa9-900571890b0c      4,2G     1% /var/log
      ├─vg01-var_log_audit ext4              1.0              VARLOGAUDIT            e3934a2c-2dd4-400e-ab3e-ff7109ffa3b4      4,3G     0% /var/log/audit
      ├─vg01-var_tmp       ext4              1.0              VARTMP                 547188cf-688d-4e69-adc5-b993d52de28e      1,7G     0% /var/tmp
      └─vg01-tmp           ext4              1.0              TMP                    1e490c97-23f2-410a-8223-fb25c412fa4f      1,7G     0% /tmp

AH, et en Secure Boot en plus

Allez voir ici pour le tutoriel: Tutoriel installation Debian avec netinst RAID1+LUKS+LVM

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 :slight_smile:

1 J'aime

J’ai réussi à faire un déchiffrement automatique avec TPM2.

systemd-cryptenroll /dev/mdXX --tpm2-device=auto --tpm2-pcrs=7+14

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).