Journal Installation personnalisée de Debian avec LUKS v2, volumes Btrfs, systemd-boot et Secure Boot

33
18
sept.
2024

Sommaire

Cher journal,

Je me suis amusé en début d’été à réinstaller ma machine avec Debian Bookworm et j’ai pris quelques notes pour en faire un article sur mon blog. Nous voilà déjà à la fin de l’été et j’ai publié l’article que je vous ai retranscrit ici directement ci-dessous.

Finalement, cet article que j’avais imaginé petit a pris bien plus de mon temps que prévu :)

Installation personnalisée de Debian avec disque chiffré par LUKS v2, volumes Btrfs, systemd-boot et Secure Boot

Introduction

Dans cet article, je vais vous présenter comment j’ai fait pour installer Debian Bookworm de manière chiffrée avec les outils de sécurité les plus récents.

Pour chiffrer une installation, l’installateur de Debian crée actuellement un conteneur LUKS v1 et installe l’outil GRUB 2 pour démarrer le système.

L’installateur ne peut ni passer à la version 2 de LUKS ni utiliser l’algorithme de dérivation de clé Argon2id, car il doit d’abord attendre que GRUB 2 réimplémente lui-même ces deux spécifications.

L’intérêt d’Argon2id est qu’il protège la clé de déchiffrement du disque de manière à résister à la puissance des cartes graphiques. Quant à la version 2 de LUKS, son intérêt est qu’il permet justement d’utiliser Argon2id.

Heureusement, Debian peut être installée manuellement (sans utiliser d’installateur) depuis un autre Linux grâce au système debootstrap. Ainsi, à la manière de la distribution Arch Linux, l’installation peut être totalement personnalisée.

Pour pouvoir utiliser LUKS v2 et Argon2id, j’ai choisi d’utiliser systemd-boot pour démarrer mon système à la place du traditionnel GRUB 2.

systemd-boot ne doit ni implémenter LUKS v2, ni Argon2id, parce qu’il se contente d’exécuter le noyau Linux au format initramfs1. Le déchiffrement du disque sera géré directement par ce Linux qui a déjà son implémentation de tous les algorithmes nécessaires.2

Pour que ce système fonctionne, il faut installer systemd-boot et les noyaux Linux directement dans la partition système ESP (sans chiffrement). Cette partition est celle utilisée par le firmware de l’ordinateur pour démarrer le système d’exploitation de votre choix. Elle est définie par le standard UEFI (standard qui définit une interface entre le firmware de la machine et le système d’exploitation).

La partition ESP ne peut pas être chiffrée, car elle doit être lisible par le firmware de la machine. D’un côté, c’est un avantage, car c’est grâce à ça que systemd-boot peut démarrer le noyau Linux facilement, mais d’un autre côté, c’est un désavantage, car il n’est plus possible de garantir que le contenu de la partition n’a pas été altéré par un logiciel ou un acteur malveillant.

Bien qu’il ne soit pas possible de chiffrer le contenu de la partition ESP, il est possible de demander au système d’exploitation de signer numériquement le contenu qu’il installe dans cette partition. Ensuite, il faut que le système d’exploitation partage avec le firmware sa clé publique pour que le firmware puisse valider l’authenticité du contenu. Si le firmware détecte que le contenu de la partition ESP a été altéré (la signature est invalide), il doit refuser de démarrer le système d’exploitation.

Le standard UEFI a déjà pensé à ce système de sécurisation du contenu de la partition ESP et l’a nommé Secure Boot. Si le démarreur a été altéré, le seul moyen de démarrer le système d’exploitation est de désactiver Secure Boot dans les paramétrages de la machine. Il est donc important de définir un mot de passe d’accès aux paramétrages de l’UEFI lors de l’installation de la machine (si non, toute personne qui a accès à la machine peut installer un logiciel malveillant dans la partition ESP et désactiver Secure Boot).3

En résumer, dans cet article je vais vous montrer comment j’ai installé Debian Bookworm avec tous ces outils (LUKS v2, Argon2id, systemd-boot, Secure Boot). Les étapes que j’ai suivies sont dans l’ordre :

  1. démarrer une image autonome (live) de Debian (avec Secure Boot désactivé)
  2. préparer le disque et les partitions
  3. installer le système de base avec debootstrap
  4. entrer dans ce système de base
  5. installer systemd-boot comme système de démarrage
  6. configurer et activer Secure Boot

Démarrer une image autonome de Debian avec Secure Boot désactivé

Depuis la page Obtenir Debian, je télécharge l’« image autonome GNOME ». Ensuite, je vérifie l’authenticité de l’image téléchargée et je peux l’installer sur une clé USB avec l’outil Disques de GNOME.

Maintenant que la clé est prête, je peux la brancher à la machine. Je démarre l’ordinateur en entrant d’abord dans son outil de paramétrage du UEFI. Il faut y faire les changements suivant :

  • autoriser le démarrage sur clé USB
  • configurer un mot de passe pour accéder à cette interface de configuration
  • modifier la configuration de Secure Boot pour le passer en « Setup Mode » Dans l’UEFI de ma machine, cette option s’appelle « Secure Boot ⭢ Reset to Setup Mode » et sa documentation explique bien que « la Platform Key sera supprimée, Secure Boot sera désactivé et passé en Setup Mode ».

Enfin, je redémarre la machine et je lui fais démarrer Debian depuis la clé USB.

Préparer les partitions sur le disque

Organisation du disque dur

Avec le système de démarrage UEFI et les partitions au format Btrfs, il est devenu possible de faire une organisation plutôt simple du disque dur.

En effet, UEFI nécessite d’utiliser une table de partition de type GPT ce qui implique plus de souplesse dans la gestion du disque :

  • l’espace qui contient les démarreurs de système d’exploitation est lui-même une partition dont la taille peut être choisie
  • selon les implémentations, il est possible de créer beaucoup plus de partitions (le système précédent, MBR, était limité à 4 partitions seulement)
  • les identifiants uniques GUID sont utilisés pour désigner les partitions de manière univoque

Btrfs quant à lui permet de créer des sous-volumes logiques qui permettent d’organiser les données dans le disque sans avoir besoin de créer des partitions avec des tailles arbitraires difficiles à changer par la suite.

J’ai décidé de ne pas avoir de partition de type swap, parce que je ne l’utiliserai pas le système d’hibernation de la machine. Je ferais plus tard un fichier de type swap pour les cas où la mémoire vive ne suffit vraiment plus pendant le fonctionnement.

Le schéma de mon disque est finalement le suivant :

┌       ┬                                   ┬           ┐
│  ESP  │              Debian               │  Windows  │
│       │  Btrfs dans un conteneur LUKS v2  │           │
└       ┴                                   ┴           ┘

La partition ESP contiendra l’outil systemd-boot, les images Linux au format initramfs et le démarreur de Windows.

La partie Debian est une partition Btrfs installée dans un conteneur de chiffrement LUKS v2.

La partie Windows sera un espace libre qui sera rempli automatiquement par l’installateur de Windows (au final 2 partitions).

Créer la partition ESP pour démarrer le système

L’image autonome GNOME de Debian Bookworm est fournie avec le logiciel Disques, je l’utilise pour préparer plus facilement la machine avec une interface graphique.

D’abord, je sélectionne le disque de ma machine et je lui crée une nouvelle table de partition de type GPT (attention, cette opération écrase toutes les données du disque : si des données existent déjà, faites une sauvegarde avant !).

Pour la première partition, je crée la partition ESP avec le type « Compatible avec tous les systèmes et périphériques (FAT) » et assez large (10 Gio), parce que systemd-boot nécessite d’installer les images initramfs dans cette partition. Par exemple, maintenant, je n’ai qu’un seul noyau installé et il y a déjà une centaine de Mio d’utilisé (principalement 75 Mio pour un noyau et 27 Mio pour Windows).

Après la création de cette partition, il faut la sélectionner dans Disques, cliquer sur la roue dentée en dessous et choisir le menu contextuel « Edit Partition ». Dans le dialogue qui s’ouvre, il faut alors changer le « Type » et choisir la valeur « Système EFI » pour que le firmware UEFI sache que cette partition contient les démarreurs des systèmes d’exploitations.

Créer la partition chiffrée pour Debian

Pour créer la partition de Debian avec Disques, il faut choisir la taille désirée, le type « Autre » et l’option « Pas de système de fichiers » sur la seconde partie de l’écran de configuration.

Pour le choix de la taille de la partition, j’ai personnellement laissé environ 70 Gio à la fin du disque pour pouvoir installer Windows plus tard.

Je sais que Disques permet aussi de créer facilement une partition Btrfs chiffrée par un conteneur LUKS, mais il ne sait créer que des conteneurs LUKS v1 et non pas v2.

Pour créer le conteneur LUKS v2, la commande sudo cryptsetup luksFormat /dev/sda2 de Debian Bookworm suit déjà par défaut les recommandations actuelles (l’identifiant /dev/sda2 est à adapter avec la valeur affichée par Disques).

Ensuite, il faut monter le conteneur avec la commande sudo cryptsetup open /dev/disk/by-uuid/${UUID} luks-debian ce qui prépare le périphérique /dev/mapper/luks-debian.

Pour retrouver facilement le bon identifiant UUID à utiliser, j’utilise la commande lsblk -f ou le logiciel Disques.

Il reste à créer la partition Btrfs sur ce périphérique avec sudo mkfs.btrfs /dev/mapper/luks-debian et la monter sur /mnt avec sudo mount /dev/mapper/luks-debian /mnt.

Créer les sous volumes Btrfs

Pour les sous-volumes, je suis les besoins de l’outil de sauvegarde Timeshift qui utilise @ pour la partition racine et @home pour la partition de données utilisateurs.

$ sudo btrfs subvol create /mnt/@
$ sudo btrfs subvol create /mnt/@home

Monter les volumes et les partitions

Avant d’entrer dans le chroot, il faut remonter les partitions pour être prêt à faire l’installation concrète de Debian aux bons endroits :

$ sudo umount /mnt
$ sudo mount /dev/mapper/luks-debian -o compress=zstd,subvol=@ /mnt
$ sudo mkdir -p /mnt/home
$ sudo mount /dev/mapper/luks-debian -o compress=zstd,subvol=@home /mnt/home
$ sudo mkdir -p /mnt/boot/efi
$ sudo mount /dev/disks/by-uuid/${ESP_UUID} /mnt/boot/efi

Installer le système de base

Pour débuter l’installation, je suis à peu près le manuel Debian pour Installer Debian GNU/Linux à partir d’un système Unix/Linux.

Comme l’image autonome utilisée est elle-même une distribution Debian, j’installe debootstrap simplement avec apt :

$ sudo apt update
$ sudo apt install debootstrap

Ensuite, je débute l’installation minimale :

$ sudo debootstrap --arch amd64 bookworm /mnt http://ftp.ch.debian.org/debian

Avant d’entrer dans le contexte de l’installation (chroot), je copie l’état actuel des points de montage qui ciblent le dossier /mnt du système autonome dans le fichier fstab du chroot (ce fichier a été créé par debootstrap) :

$ grep /mnt /etc/mtab | sudo tee -a /mnt/etc/fstab

Pour la partie « Créer les fichiers des périphériques » du manuel d’installation, j’utilise la commande suivante (trouvée sur le wiki de Debian: GRUB EFI Reinstall) pour partager les montages de l’image autonome avec le conteneur chroot :

$ for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount -o bind $i /mnt$i; done

Maintenant, je peux entrer concrètement dans le système installé avec la commande chroot :

$ LANG=C.UTF-8 sudo chroot /mnt /bin/bash

D’abord, je modifie le fichier /etc/fstab avec les entrées nécessaires pour monter la partition ESP et les sous-volumes Btrfs.

Comme j’ai prérempli le fichier avec les lignes du système autonome au-dessus, il faut remplacer les cibles de montages /mnt, /mnt/home et /mnt/boot/efi par /, /home et /boot/efi respectivement.

Par exemple, sur mon ordinateur le fichier contient :

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# file system    mount point   type    options                  dump pass
/dev/nvme0n1p1 /boot/efi vfat rw 0 0
/dev/mapper/luks-debian / btrfs rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=256,subvol=/@ 0 0
/dev/mapper/luks-debian /home btrfs rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/@home 0 0

Pour confirmer que le fichier est correct, le plus simple est de forcer un montage de toutes les partitions :

$ mount -a

Comme le manuel d’installation le propose, je configure le fuseau horaire avec :

$ dpkg-reconfigure tzdata

Ensuite, j’ajoute un serveur DNS de Quad9 temporairement pour continuer l’installation avec un réseau fonctionnel :

$ echo "nameserver 9.9.9.10" > /etc/resolv.conf

Je profite aussi de donner un nom à mon ordinateur :

$ echo togepi > /etc/hostname

Je modifie les listes de source des paquets Debian pour ajouter le dépôt non-free-firmware (mon matériel a besoin de firmwares privateurs pour démarrer correctement) :

$ editor /etc/apt/sources.list

et ajouter non-free-firmware à côté de main.

Comme proposé par le manuel, j’installe les locales pour avoir la locale fr_CH.UTF8 disponible sur ma machine :

$ apt update
$ apt install locales
$ dpkg-reconfigure locales

Enfin, j’installe comme conseillé console-setup et l’image du noyau Linux :

$ sudo apt install console-setup linux-image-amd64

Préparation des fichiers de configuration avant d’installer systemd-boot

Au lieu d’installer GRUB comme dans le manuel d’installation de Debian, j’installe systemd-boot en suivant les conseils du blog Md at debian.org.

Je commence par créer les fichiers de configuration avant d’installer systemd-boot pour que, au moment de son installation, tout se configure directement comme nécessaire.

Le premier fichier à configurer est /etc/kernel/cmdline qui contiendra les options de démarrage de Linux. Ces options expliquent à l’image Linux initramfs comment démarrer le noyau Linux complet.

Mon fichier contient une ligne comme celle-ci :

cryptdevice=UUID=${UUID}:luks-debian root=/dev/mapper/luks-debian rootflags=subvol=@ quiet splash

Quelques explications :

  • cryptdevice=UUID=${UUID}:luks-debian Cette option permet de faire le lien entre la partition désignée par la valeur ${UUID} (à remplacer par l’identifiant du conteneur LUKS) et son alias luks-debian (sa valeur peut être différente, mais elle doit se retrouver dans les fichiers /etc/fstab et /etc/crypttab). Cette option sera utilisée par le module cryptsetup pour demander la phrase de passe pour déchiffrer le système (selon les détails retrouvés dans le fichier /etc/crypttab, voir plus bas)
  • root=/dev/mapper/luks-debian Cette option annonce où se situe la source de la racine du système de fichier « / » pour démarrer le noyau Linux complet (avec l’utilisation de l’alias de l’option précédente).
  • rootflags=subvol=@ Cette option précise d’utiliser le volume Btrfs @ comme point de montage pour la racine du système de fichier « / ».
  • quiet Cette option permet de réduire la quantité de messages affichés au démarrage. Dans un premier temps, il vaut mieux l’omettre pour pouvoir voir les messages d’erreur. Elle peut être ajoutée dans un second temps, quand le démarrage aura réussi une première fois.
  • splash Cette option permet de remplacer le texte de démarrage par une animation graphique proposée par la distribution (via le logiciel Plymouth) à la place des messages de démarrage. Pour les mêmes raisons que l’option quiet, il vaut mieux l’activer dans un second temps.

Le second fichier à configurer est /etc/crypttab pour que l’image initramfs et le module cryptsetup sachent comment déchiffrer le conteneur LUKS. Par exemple, le contenu de mon fichier est :

# <target name> <source device> <key file> <options>

luks-debian UUID=${UUID} none cipher=aes-xts-plain64,size=512,hash=sha256

Il faut de nouveau remplacer ${UUID} par l’identifiant du conteneur LUKS et luks-debian par l’alias choisi.

Ce fichier répète le lien entre la partition et l’alias, mais il précise surtout qu’il n’y a pas de fichiers contenant une clé de déchiffrement et quels sont les algorithmes à utiliser pour pouvoir déchiffrer les données.

Pour retrouver les bonnes options, j’ai utilisé la commande cryptsetup pour afficher les informations du conteneur LUKS (il faut installer le paquet cryptsetup d’abord si vous exécutez cette commande dans le chroot) :

$ cryptsetup luksDump /dev/disk/by-uuid/${UUID}

Installation des outils personnels et de ceux nécessaires pour l’image initramfs

L’environnement Debian dans le chroot est bien configuré, mais il est encore très minimal. Je lui ajoute les outils standards de Debian :

$ tasksel install standard

Je profite pour installer un environnement de bureaux (personnellement j’apprécie GNOME) :

$ tasksel install gnome-desktop

Quelques outils spécifiques au matériel de ma machine :

$ tasksel install laptop # mon ordinateur est un portable
$ apt install amd64-microcode firmware-amd-graphics # mon ordinateur utilise du matériel AMD
$ apt install firmware-misc-nonfree # mon ordinateur a une carte wifi MediaTek

Enfin, il est important d’installer dans le chroot et dans l’image initramfs le module cryptsetup qui permet de gérer les conteneurs LUKS. Sans cet outil, il est impossible de déchiffrer les partitions.

$ apt install cryptsetup cryptsetup-initramfs

Avec cette commande Debian reconstruit l’image initramfs avec tous les outils nécessaires pour déverrouiller le disque au démarrage. Il ne reste donc plus qu’à installer le démarreur systemd-boot.

Installation de systemd-boot

Depuis la version 12 (alias Bookworm) de Debian, il suffit d’exécuter :

$ apt install systemd-boot

Ensuite, la configuration de cet outil se fait directement dans la partition ESP en modifiant le fichier /boot/efi/loader/loader.conf.

Configuration de Secure Boot

Pour configurer Secure Boot j’ai également suivi les conseils du même article du blog Md at debian.org.

L’utilisation de l’outil sbctl permet de configurer Secure Boot sans installer GRUB, mais, comme cet outil ne se trouve pour l’instant pas dans Debian, il faut le télécharger et l’installer à la main.

Je documente ici comment je l’ai fait, mais si c’était à refaire, je pense que j’essaierais d’installer quand même l’outil shim prévu par Debian même s’il installe GRUB en trop. Je ne sais pas si ça peut fonctionner, c’est à essayer.

sbctl est un outil crée en go, il est donc possible de récupérer le binaire pré-compilé et distribué par le projet. J’utilise une version amd64 de Linux, j’ai donc procédé ainsi pour l’ajouter à mon système4 :

$ sudo apt install curl # je n’avais pas encore installé curl
$ curl -L -O 'https://github.com/Foxboron/sbctl/releases/download/0.14/sbctl-0.14-linux-amd64.tar.gz'
$ tar xf sbctl-0.14-linux-amd64.tar.gz
$ sudo mv sbctl/sbctl /usr/local/sbin/
$ sudo sbctl status
Installed:      ✘ sbctl is not installed
Setup Mode: ✘ Enabled
Secure Boot:    ✘ Disabled
Vendor Keys:    none

La sortie de la dernière commande explique que Secure Boot est bien en mode configuration (Setup Mode: Enabled) et qu’il est désactivé. Si ce n’est pas le cas, il faut redémarrer dans l’UEFI et activer la gestion des clés.

Je crée ma clé personnelle (propriétaire) pour la machine, elle sera à ajouter comme clé de confiance dans l’UEFI :

$ sbctl create-keys
Created Owner UUID e15b9fe0-6bdd-421d-8f4f-f582257a8f14
Creating secure boot keys...✔
Secure boot keys created!
$ sbctl status
Installed:      ✔ sbctl is installed
Owner GUID: e15b9fe0-6bdd-421d-8f4f-f582257a8f14
Setup Mode: ✘ Enabled
Secure Boot:    ✘ Disabled
Vendor Keys:    none

Pour ajouter cette nouvelle clé dans l’UEFI, j’ai choisi d’utiliser l’option --microsoft pour ajouter aussi les clés de Microsoft, car je vais installer Windows également sur le disque :

$ sbctl enroll-keys --microsoft
Enrolling keys to EFI variables...
With vendor keys from microsoft...✔
Enrolled keys to the EFI variables!
root@debian:/# sbctl status
Installed:      ✔ sbctl is installed
Owner GUID: e15b9fe0-6bdd-421d-8f4f-f582257a8f14
Setup Mode: ✔ Disabled
Secure Boot:    ✘ Disabled
Vendor Keys:    microsoft

La configuration des clés est terminée dans l’UEFI. Il faut maintenant utiliser les clés pour signer les fichiers de démarrage actuellement installés :

$ for file in /boot/efi/*/*/linux /boot/efi/EFI/*/*.efi; do sbctl sign -s $file; done
✔ Signed /boot/efi/9ee8db2eeacf4118a2d7f194bfbc3e43/6.1.0-25-amd64/linux
✔ Signed /boot/efi/EFI/systemd/systemd-bootx64.efi

Pour le faire à chaque mise à jour de noyau, il faut ajouter le script 91-sbctl.install (il faut faire attention à récupérer le même numéro de version que le binaire sbctl) dans le dossier /etc/kernel/install.d et le rendre exécutable (chmod +x 91-sbctl.install).

J’ai eu besoin de personnaliser ce script pour utiliser le chemin complet de l’installation du binaire /usr/local/sbin/sbctl à la place de juste sbctl pour m’assurer que le script fonctionne avec tous les environnements utilisateurs (notamment _apt). Pour faire ça, j’ai ajouté en début de script une ligne qui crée l’alias nécessaire :

#!/bin/sh
#  This file is part of sbctl.

# Adrien: set full path for sbctl so it works within apt user environment
alias sbctl=/usr/local/sbin/sbctl

# reste du script

Enfin pour s’assurer que le script est bien exécuté lors de la mise à jour du noyau, je force la mise à jour des images initramfs :

$ sudo update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-6.1.0-25-amd64
Updating kernel version 6.1.0-25-amd64 in systemd-boot...
sbctl: Signing kernel /boot/efi/9ee8db2eeacf4118a2d7f194bfbc3e43/6.1.0-25-amd64/linux
$ sudo sbctl list-files
/boot/efi/9ee8db2eeacf4118a2d7f194bfbc3e43/6.1.0-25-amd64/linux
Signed:     ✔ Signed

/boot/efi/EFI/systemd/systemd-bootx64.efi
Signed:     ✔ Signed

Quand des mises à jour de systemd-boot sont proposées par Debian, il faut également signer le fichier que le paquet installe dans /boot/efi.

Je ne sais pas comment faire pour déclencher automatiquement une ligne de commande lors de la mise à jour d’un paquet. Par contre, avec systemd, il est assez facile de demander au système de surveiller les modifications sur un fichier et d’exécuter un service à ce moment-là.

J’ai créé le service /etc/systemd/system/systemd-boot-sign.service avec la commande pour signer le binaire de systemd-boot :

[Unit]
Description=Sign the systemd-boot binary in ESP partition

[Service]
ExecStart=/usr/local/sbin/sbctl sign -s /boot/efi/EFI/systemd/systemd-bootx64.efi

Pour déclencher ce service automatiquement, j’ai créé l’unité /etc/systemd/system/systemd-boot-sign.path avec :

[Unit]
Description=On update of systemd-boot binary in ESP partition, sign it

[Path]
PathModified=/boot/efi/EFI/systemd/systemd-bootx64.efi

[Install]
WantedBy=default.target

Enfin, il faut demander à systemd d’activer et démarrer cette dernière unité :

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now systemd-boot-sign.path

Conclusion

La démarche était longue, mais le résultat est vraiment bien: ma machine démarre de manière sécurisée une Debian stable installée par mes soins avec Secure Boot et une interface graphique pour entrer la phrase de déchiffrement.

J’ai écrit cet article depuis l’historique des commandes entrées dans mon terminal pendant l’installation de ma machine. Il est probable que j’ai oublié certains détails, mais l’essentiel devrait être là.


  1. Le noyau Linux au format « initramfs » (ou « image initramfs ») contient une petite copie du noyau Linux à charger en mémoire vive pour démarrer le noyau complet et la distribution. 

  2. Le fonctionnement de GRUB est bien plus complexe, car il n’installe pas les noyaux Linux dans la partition de démarrage. Ceci est dû à sa compatibilité avec les anciennes tables de partition de type bios qui ne disposait que d’un espace très réduit pour les démarreurs (l’espace MBR en début de disque). 

  3. Il faut bien faire attention que l’application de Secure Boot est seulement de permettre au firmware de n’exécuter que les systèmes d’exploitations choisis par le propriétaire de la machine. Par exemple, si quelqu’un s’empare du disque dur et le démarre sur une autre machine, Linux va démarrer sans remarquer qu’il n’est plus dans la machine prévue et il va permettre à l’attaquant d’essayer de déchiffrer le disque dur. Dans ce cas, Secure Boot est inutile, car il ne sécurise que le démarrage que pour une machine.
    Si l’on voulait que Linux refuse de démarrer quand le matériel change, il faudrait appliquer un système de vérification du démarrage : chaque composant logiciel doit vérifier que l’état du système est celui attendu et mettre à jour l’état actuel pour indiquer qu’il s’est bien exécuté. Le principe est de créer une chaîne de confiance qui nécessite une puce TPM pour sauver l’état de la chaîne entre chaque démarrage.
    C’est une présentation sommaire de ce que j’ai compris en lisant l’article Roots of Trust are difficult de Matthew Garrett qui présente le système de vérification de démarrage prévu par le Trusted Computing Group et pointe les difficultés pour le mettre en place. 

  4. J’ai fait cette installation en juillet 2024, la version la plus récente de sbctl était celle documentée dans cet article (0.14). Pendant les relectures, j’ai essayé d’utiliser la version 0.15.4 pour refaire les procédures dans une machine virtuelle, mais ce bug m’a empêché d’utiliser la version 0.15.4 de sbctl, j’ai donc préféré garder les références à la version 0.14 pour cet article. 

  • # Erreur de transcription

    Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

    Le problème du sommaire avec un point vide vient à cause d'une erreur de transcription du HTML vers le Markdown de LinuxFr.

    Si un membre de la modération peut remplacer:

    Le second fichier à configurer est _/etc/crypttab_ pour que l’image _initramfs_ et le module _cryptsetup_ sachent comment déchiffrer le conteneur LUKS. Par exemple, le contenu de mon fichier est :
    
    > # <target name> <source device> <key file> <options>
    >
    > luks-debian UUID=${UUID} none cipher=aes-xts-plain64,size=512,hash=sha256

    par l'utilisation d'un bloque de code à la place d'un bloque de citation autour du contenu du fichier:

    Le second fichier à configurer est /etc/crypttab pour que l’image initramfs et le module cryptsetup sachent comment déchiffrer le conteneur LUKS. Par exemple, le contenu de mon fichier est :

    # <target name> <source device> <key file> <options>
    
    luks-debian UUID=${UUID} none cipher=aes-xts-plain64,size=512,hash=sha256
    

    Ca serait apprécié :)

  • # Image Initramfs ? UKI ?

    Posté par  . Évalué à 2 (+2/-0).

    Merci pour l'article, ce que tu appelles "image initramfs" c'est un UKI (Universal Kernel Image) contenant le noyau, l'initramfs et la ligne de commande du noyau ?

    • [^] # Re: Image Initramfs ? UKI ?

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Hello,

      Si je comprend bien la définition d'UKI, le démarrage de la machine passerait directement du firmware UEFI au fichier UKI sans passer par l'intermédiaire de GRUB ou systemd-boot.

      Dans cet article, j'utilise la méthode à l'ancienne où on a un chargeur de noyau, systemd-boot, qui démarre une image temporaire de Linux qui inclue juste ce qu'il faut pour démarrer la distribution. Dans le cas du chiffrement, il est nécessaire de compléter cette image avec le paquet cryptsetup-initramfs.

      Debian a une page qui explique l'initramfs: https://wiki.debian.org/initramfs

      • [^] # Re: Image Initramfs ? UKI ?

        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

        Il y a un article qui vient d'être publié qui explique comment utiliser les images UKI avec Debian et systemd-boot. Il faudra que j'essaie dans ma VM, ça pourrait être intéressant.

        • [^] # Re: Image Initramfs ? UKI ?

          Posté par  . Évalué à 1 (+1/-0).

          Avec l'utilisation d'un couple noyau et image initramfs avec Grub ou systemd-boot, tu ne t'assures de l'intégrité de ton démarrage que sur le noyau. L'initramfs n'étant pas signé, celui-ci peut être modifié.
          Avec une image UKI tu signes l'image complète (noyau, initramfs et cmdline). Ça fonctionne très bien avec systemd-boot car il sait nativement exécuter un binaire UEFI.

          • [^] # Re: Image Initramfs ? UKI ?

            Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

            L'initramfs n'étant pas signé, celui-ci peut être modifié.

            Avec grub, l'initramfs peut être stocké dans une partition chiffrée et il n'a dans ce cas pas besoin d'être signé puisqu'il est déjà chiffré.

            Avec systemd-boot, il faut placer le initramfs dans la partition ESP qui ne peut pas être chiffrée.

            Dans l'article, je présente comment signer automatiquement les fichiers initramfs avec le fichier 99-sbctl pour sécuriser le démarrage.

            Avec une image UKI tu signes l'image complète (noyau, initramfs et cmdline)

            J'avais compris que UKI remplace le couple "initramfs et noyau". Ce n'est pas ça ?

            Avec la solution de l'article, le fichier cmdline n'est pas chiffré. C'est donc un bon argument pour essayer UKI, merci d'avoir pointé cette idee :)

            • [^] # Re: Image Initramfs ? UKI ?

              Posté par  . Évalué à 2 (+2/-0).

              Dans l'article, je présente comment signer automatiquement les fichiers initramfs avec le fichier 99-sbctl pour sécuriser le démarrage.
              C'est le point qui m'a fait me poser la question si l'outil ne faisait pas un UKI (Noyau + initramfs + EFI Stub) pour le signer.
              Est-ce que tu disposes des lignes linux et initrd dans ton fichier de configuration systemd-boot ou d'une seule ligne linux ?

              J'avais compris que UKI remplace le couple "initramfs et noyau". Ce n'est pas ça ?
              L'UKI peut contenir beaucoup de chose :
              - Noyau
              - Initramfs
              - Cmdline
              - SplashImage
              - DTB (majoritairement pour ARM/Risc-V)
              - Metadonnées OS-Release
              - EFIStub (pour être compatible UEFI)
              Mais en effet la grosse plus-value est de pouvoir s'assurer de l'intégrité de l'initramfs et de la cmdline en plus de celle du noyau.

              • [^] # Re: Image Initramfs ? UKI ?

                Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

                Dans l'article, je présente comment signer automatiquement les fichiers initramfs avec le fichier 99-sbctl pour sécuriser le démarrage.
                C'est le point qui m'a fait me poser la question si l'outil ne faisait pas un UKI (Noyau + initramfs + EFI Stub) pour le signer.
                Est-ce que tu disposes des lignes linux et initrd dans ton fichier de configuration systemd-boot ou d'une seule ligne linux ?

                Oui, j'ai bien les linux, initrd et les fichiers ".conf" qui contiennent les options de démarrage définies dans /etc/kernel/cmdline:

                $ find /boot/efi | grep -v Microsoft
                /boot/efi
                /boot/efi/EFI
                /boot/efi/EFI/systemd
                /boot/efi/EFI/systemd/systemd-bootx64.efi
                /boot/efi/EFI/BOOT
                /boot/efi/EFI/BOOT/BOOTX64.EFI
                /boot/efi/EFI/Linux
                /boot/efi/loader
                /boot/efi/loader/entries
                /boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.1.0-22-amd64.conf
                /boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.9.7+bpo-amd64.conf
                /boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.9.10+bpo-amd64.conf
                /boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.10.6+bpo-amd64.conf
                /boot/efi/loader/loader.conf
                /boot/efi/loader/random-seed
                /boot/efi/loader/entries.srel
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.10+bpo-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.10+bpo-amd64/linux
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.10+bpo-amd64/initrd.img-6.9.10+bpo-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.1.0-22-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.1.0-22-amd64/linux
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.1.0-22-amd64/initrd.img-6.1.0-22-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.7+bpo-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.7+bpo-amd64/linux
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.7+bpo-amd64/initrd.img-6.9.7+bpo-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/linux
                /boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/initrd.img-6.10.6+bpo-amd64
                /boot/efi/System Volume Information
                $ cat /boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.10.6+bpo-amd64.conf
                # Boot Loader Specification type#1 entry
                # File created by /usr/lib/kernel/install.d/90-loaderentry.install (systemd 254.16-1~bpo12+1)
                title      Debian GNU/Linux 12 (bookworm)
                version    6.10.6+bpo-amd64
                machine-id 9af3221b56764a7bb3cd7feeb31bbde9
                sort-key   debian
                options    cryptdevice=UUID=516d25d7-053c-424e-9822-35c15ee60dd1:Debian root=/dev/mapper/Debian rootflags=subvol=@ quiet splash systemd.machine_id=9af3221b56764a7bb3cd7feeb31bbde9
                linux      /9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/linux
                initrd     /9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/initrd.img-6.10.6+bpo-amd64

                J'avais compris que UKI remplace le couple "initramfs et noyau". Ce n'est pas ça ?

                L'UKI peut contenir beaucoup de chose :
                - Noyau
                - Initramfs
                - Cmdline
                - SplashImage
                - DTB (majoritairement pour ARM/Risc-V)
                - Metadonnées OS-Release
                - EFIStub (pour être compatible UEFI)
                Mais en effet la grosse plus-value est de pouvoir s'assurer de l'intégrité de l'initramfs et de la cmdline en plus de celle du noyau.

                Ah oui, c'est pas mal tout ça, il faudra que j'essaie de le mettre en place en suivant l'article de copyninja. Il a d'ailleurs écrit un deuxième article pour activer Secure Boot avec l'utilisation d'UKI en utilisant sbsign à la place de sbctl (sbsign est déjà empaqueté par Debian, c'est à essayer).

      • [^] # Re: Image Initramfs ? UKI ?

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        non, un UKI peut-être booter directement par le firmware UEFI ou par un bootloader. C'est ce qui est écrit dans le wiki.

        or automatically sourced by boot loaders with little or no configuration

  • # Thanks!

    Posté par  (site web personnel) . Évalué à 3 (+2/-0).

    Merci bcp pour cette mine d'information ! Je bookmark la page pour pouvoir la retrouver et suivre le process dans certaines de mes prochaines installations.

  • # bravo et merci

    Posté par  . Évalué à 4 (+2/-0).

    C'est un excellent tutoriel que voilà, détaillé et avec les explications techniques qu'il faut (ni trop, ni pas assez).
    Bien que ne pense pas personnellement franchir le pas, j'ai lu le journal avec beaucoup d'intérêt et je crois même avoir à peu près tout compris ;)

    "Si tous les cons volaient, il ferait nuit" F. Dard

  • # Systemd boot

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Je garde ce journal sous le coude pour la prochaine installation Debian, merci !

  • # Installeur debian

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 20 septembre 2024 à 07:35.

    L'installeur Debian est génial, il est très souple et fait pour être utilisé dans des contextes très différents. Malheureusement j'ai l'impression que le revers de la médaille c'est qu'il met du temps à intégrer certaines nouveautés et qu'il est pas opiniated du coup les installations les plus à l'état de l'art ne sont pas disponibles. Tu parles de timeshift, j'ai pas regardé dans le détail mais avoir un mécanisme qui crée des snapshot lors des mises à jour et propose au démarrage de revenir sur une version précédente en cas de problème n'est toujours pas trivial alors que ça me paraît une super fonctionnalité

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Support de LUKS v2 dans Grub

    Posté par  . Évalué à 3 (+3/-0).

    Pour info, le support de LUKS v2 pour venir assez prochainement dans Grub. Comme on peut le voir dans le ticket https://savannah.gnu.org/bugs/?55093, le support dépend de la mise à jour de libgrypt dans Grub, et j'ai l'impression que ça bouge chez Grub : https://lists.gnu.org/archive/html/grub-devel/2024-09/msg00112.html.

    Arch Linux supporte indirectement (grâce à un package dans AUR) LUKS v2 via une version patchée de Grub https://aur.archlinux.org/packages/grub-improved-luks2-git, mais ça passe par une ré-implémentation d'Argon2 en dehors de la lib libgcrypt, ce qui ne plait pas à upstream (et ça se comprend).

  • # clé sécu+systemd-cryptenroll

    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

    C'est en gros mon setup … mais sous archlinux. Je dirais qu'il y a moins de complication

    J'utiliser la méthode shim pour booter en SecureBoot.

    Auparavant je bootais avec dévérouillage auto de la partion LUKS2, avec le fichier clé sur une clé USB, dans le gap post-MBR. Il fallait booter avec la clé insérée évidemment.

    J'utilise maintenant ma SoloKey (clé de sécu) pour dévérouiller la partition LUKS2 après avoir configurer le tout avec systemd-cryptenroll.

    J'avais fait un tuto sur l'insistance de qqn sur une room matrix.
    Je le reposte là: https://bpa.st/32GA

    Il ne demande qu'à être sauver pour la postérité…

    A noter que sbctl a été créer par Foxboron, dev archlinux ;-)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.