Il y a peu de temps, un bogue avec l'installation chiffrée LVM dans Kali Linux 1.0.4 a été signalé dans notre outil de suivi des bogues. Ce bogue était une priorité élevée dans notre TODO car les installations cryptées sont une fonctionnalité importante dans notre industrie, nous voulions donc éliminer ce bogue dès que possible. Cet article décrira le processus de débogage, d'identification et de correction de ce bogue dans Kali, et finalement dans Debian également.
Le bug lui-même était bizarre; l'installation de Kali avec l'option "LVM Encrypted" entraînerait un échec du démarrage une fois l'installation terminée :
La solution de contournement suggérée dans le rapport de bogue indiquait que le fichier /etc/crypttab le fichier était vide. En remontant manuellement la partition chiffrée, en la repeuplant avec les paramètres requis, puis en mettant à jour initramfs, la machine redémarrerait avec succès dans la partition chiffrée. Très certainement ennuyeux et loin d'être pratique.
Maintenant que le problème était bien défini, la solution semblait simple. Quelque chose n'allait probablement pas avec la façon dont /etc/crypttab est mis à jour pendant le processus d'installation. Notre prochaine étape consistait à enquêter sur les scripts responsables de cette mise à jour et à voir s'il y avait des bogues dans le processus de mise à jour des fichiers. Mais comment localiseriez-vous le script exact responsable de cette mise à jour et comment pourrions-nous déterminer dans quel package il se trouve ?
À notre secours vient DebianInstaller. En utilisant cet ensemble de scripts, nous avons extrait toute l'arborescence source de DebianInstaller. Cela nous permettrait de rechercher les scripts qui affectent /etc/crypttab avec beaucoup plus de facilité.
[email protected]:~# svn co svn://anonscm.debian.org/svn/d-i/trunk debian-installer
[email protected]:~# cd debian-installer
[email protected]:~/debian-installer# scripts/git-setup
[email protected]:~/debian-installer# mr -p checkout
Une fois tous les référentiels extraits, nous pourrions simplement grep pour tous les fichiers faisant référence à /etc/crypttab fichier comme suit :
[email protected]:~/debian-installer# grep -r '/etc/crypttab' * |grep -v ^manual
...
packages/partman-crypto/finish.d/crypto_config:# dm-crypt: creates /etc/crypttab entries
packages/partman-crypto/finish.d/crypto_config: echo "$target $source $keyfile $opts" >> /target/etc/crypttab
...
[email protected]:~/debian-installer#
On voit plus haut que c'est le "crypto_config ” script qui écrit dans /etc/crypttab , qui se trouve dans le partman-crypto paquet.
Idéalement, nous aimerions déboguer ce script et voir où se situe le problème, mais comment feriez-vous cela dans un support d'installation en direct ? La réponse est relativement simple - nous n'avions qu'à ouvrir une invite de commande pendant le processus d'installation. L'astuce consiste à invoquer notre shell de débogage (en appuyant sur CTRL + ALT + F2) pendant la bonne étape de l'installation - dans notre cas, nous devions interrompre le programme d'installation avant le crypto_config le script a été exécuté mais après le partman-crypto udeb a été installé, donc le début du processus de partitionnement serait un bon endroit. Nous avons procédé à la modification du fichier /lib/partman/finish.d/55_crypto_config et ajouté "set -x ” au début du script :
Nous avons ensuite laissé le programme d'installation faire son travail et juste avant la fin de l'installation, nous avons jeté un coup d'œil à /var/log/syslog dans une autre coque. À notre grande surprise, nous avons vu que le fichier /etc/crypttab le fichier *était* mis à jour, contrairement à nos croyances initiales, comme on peut le voir dans le syslog de l'installation. WTH .
Aug 28 21:57:42 main-menu[954]: (process:9810): crypttab_add_entry
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/sda5
Aug 28 21:57:42 main-menu[954]: (process:9810): /var/lib/partman/devices/=dev=sda/256901120-160041009151
Aug 28 21:57:42 main-menu[954]: (process:9810): /dev/mapper/sda5_crypt
...
Aug 28 21:57:42 main-menu[954]: (process:9810): echo
Aug 28 21:57:42 main-menu[954]: (process:9810): sda5_crypt UUID=6250dbca-648b-4848-9132-cfa900ab5874 none luks
C'est là que nous avons commencé à nous gratter la tête. Si le problème n'était pas dans l'écriture de ce fichier (comme prévu), alors pourquoi y avait-il un /etc/crypttab vide fichier après l'installation ? Peut-être que le problème n'était pas dans partman-crypto après tout, mais dans la façon dont live-build génère nos ISO ? Nous avons testé notre théorie en utilisant une mini installation ISO de Kali (non construite via live-build) et avons remarqué que les installations cryptées LVM fonctionnaient correctement lors de l'utilisation de ce support d'installation.
Nous savons que le live-installer utilise tar pour copier tout le système de fichiers live dans un /target monté répertoire et il suppose que les systèmes de fichiers sont vides, ce qui est généralement vrai puisqu'ils viennent d'être créés par partman. Cela signifie que tout fichier préexistant peut être écrasé s'il se trouve également dans l'image en direct, ce qui arrivait à /etc/crypttab dans ce cas.
Un examen plus approfondi a révélé que le problème était dans live-installer , par lequel il écrase le /etc/crypttab généré . Le live-installer a déjà certaines dispositions pour ne pas écraser /etc/fstab , il suffit donc de généraliser cette règle et d'inclure le /etc/crypttab fichier également :
$ diff --git a/debian/live-installer.postinst b/debian/live-installer.postinst
index 9a39d8d..bc40b84 100644 (file)
--- a/debian/live-installer.postinst
+++ b/debian/live-installer.postinst
@@ -8,6 +8,8 @@ db_capb backup
# Architecture and OS detection
ARCH=`udpkg --print-architecture`
OS=`udpkg --print-os`
+# Files that must not be overwritten by copy of live system
+FILES_TO_PRESERVE="/etc/fstab /etc/crypttab"
NEWLINE="
"
@@ -34,11 +36,12 @@ install_live_system () {
# symlinks there.
rmdir /target/var/lock /target/var/run 2>/dev/null || true
- # Backup pre-existing /etc/fstab as it will be overwritten by the
- # copy of the live system
- if [ -e /target/etc/fstab ] && [ ! -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab /target/etc/fstab.live-installer
- fi
+ # Backup files that should not be overwritten by the copy
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target$f ] && [ ! -e /target/${f}.live-installer ]; then
+ mv /target$f /target${f}.live-installer
+ fi
+ done
for place in $PLACES; do
[ ! -e $place ] && continue
@@ -83,10 +86,12 @@ install_live_system () {
eval ${SUPPORT}_teardown
done
- # Restore the fstab file created by d-i
- if [ -e /target/etc/fstab.live-installer ]; then
- mv /target/etc/fstab.live-installer /target/etc/fstab
- fi
+ # Restore important configuration files
+ for f in $FILES_TO_PRESERVE; do
+ if [ -e /target${f}.live-installer ]; then
+ mv /target${f}.live-installer /target$f
+ fi
+ done
if [ ${PLACE_FOUND} -eq 0 ]; then
error "Could not find any live images"
Le correctif ci-dessus a résolu le problème pour nous, permettant aux installations chiffrées de LVM de se terminer et de démarrer avec succès. Comme pour tous les bogues Debian que nous rencontrons, nous renvoyons des correctifs à Debian pour améliorer la distribution sur laquelle nous nous appuyons. Un correctif pour ce bogue du programme d'installation sera publié dans notre prochaine version intermédiaire (1.0.5) la semaine prochaine. Les personnes générant leurs propres images ISO via live-build recevra automatiquement le colis fixe.