Qualche tempo fa, nel nostro bug tracker è stato segnalato un bug con l'installazione crittografata LVM in Kali Linux 1.0.4. Questo bug era una priorità assoluta nel nostro TODO poiché le installazioni crittografate sono una caratteristica importante nel nostro settore, quindi abbiamo voluto eliminare questo bug il prima possibile. Questo articolo descriverà il processo di debug, identificazione e correzione di questo bug in Kali e, infine, anche in Debian.
Il bug stesso era strano; l'installazione di Kali con l'opzione "LVM Encrypted" comporterebbe un avvio non riuscito una volta completata l'installazione:
La soluzione suggerita nella segnalazione di bug indicava che /etc/crypttab il file era vuoto. Rimontando manualmente la partizione crittografata, ripopolandola con i parametri richiesti e quindi aggiornando initramfs, la macchina si avvierà nuovamente correttamente nella partizione crittografata. Decisamente fastidioso e tutt'altro che pratico.
Ora, con il problema ben definito, la soluzione sembrava semplice. Probabilmente c'era qualcosa che non andava nel modo in cui /etc/crypttab viene aggiornato durante il processo di installazione. Il nostro passo successivo è stato quello di indagare sugli script responsabili di questo aggiornamento e vedere se ci sono bug nel processo di aggiornamento dei file. Ma come individuare lo script esatto responsabile di questo aggiornamento e come potremmo capire in quale pacchetto si trova?
In nostro soccorso arriva DebianInstaller. Usando questo insieme di script, abbiamo controllato l'intero albero dei sorgenti di DebianInstaller. Questo ci permetterebbe di cercare gli script che interessano /etc/crypttab con molta più 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
Una volta che tutti i repository sono stati estratti, potremmo semplicemente cercare con grep tutti i file che fanno riferimento a /etc/crypttab file come segue:
[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#
Vediamo sopra che è il "crypto_config ” script che scrive in /etc/crypttab , che si trova in partman-crypto pacchetto.
Idealmente, vorremmo eseguire il debug di questo script e vedere dove si trova il problema, ma come lo faresti in un supporto di installazione live? La risposta è relativamente semplice:abbiamo semplicemente dovuto aprire un prompt dei comandi durante il processo di installazione. Il trucco è invocare la nostra shell di debug (premendo CTRL+ALT+F2) durante la fase corretta dell'installazione - nel nostro caso dovevamo interrompere l'installer prima di crypto_config lo script è stato eseguito ma dopo partman-crypto udeb è stato installato, quindi l'inizio del processo di partizionamento sarebbe un buon punto. Abbiamo proceduto alla modifica di /lib/partman/finish.d/55_crypto_config e aggiunto "set -x ” all'inizio dello script:
Quindi lasciamo che il programma di installazione faccia il suo lavoro e, poco prima che l'installazione sia completata, abbiamo dato un'occhiata a /var/log/syslog in un altro guscio. Con nostra sorpresa, abbiamo visto che il /etc/crypttab il file *era* in fase di aggiornamento, contrariamente alle nostre convinzioni iniziali, come si può vedere nel syslog dell'installazione. CON .
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
È qui che abbiamo iniziato a grattarci la testa. Se il problema non era nella scrittura di questo file (come ci aspettavamo), allora perché c'era un /etc/crypttab vuoto file dopo l'installazione? Forse il problema non era in partman-crypto dopo tutto, ma in come creare dal vivo genera i nostri ISO? Abbiamo testato questa nostra teoria utilizzando una mini installazione ISO di Kali (non creata tramite live-build) e abbiamo notato che le installazioni crittografate LVM funzionavano correttamente quando si utilizzava quel supporto di installazione.
Sappiamo che il programma di installazione live utilizza tar per copiare l'intero filesystem live in un /target montato directory e presuppone che i filesystem siano vuoti, il che è per lo più vero poiché sono stati appena creati da partman. Ciò significa che qualsiasi file preesistente può essere sovrascritto se si trova anche nell'immagine live, cosa che stava accadendo a /etc/crypttab in questo caso.
Un ulteriore esame ha rivelato che il problema riguardava il programma di installazione live , per cui sovrascrive il /etc/crypttab generato . Il programma di installazione live ha già alcune disposizioni per non sovrascrivere /etc/fstab , quindi si tratta solo di generalizzare quella regola e includere /etc/crypttab anche file:
$ 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"
La patch precedente ha risolto il problema per noi, consentendo il completamento e l'avvio corretto delle installazioni LVM crittografate. Come per qualsiasi bug Debian che incontriamo, inviamo le patch a Debian per migliorare la distribuzione su cui ci basiamo. Una correzione per questo bug del programma di installazione verrà pubblicata nella prossima versione (1.0.5) della prossima settimana. Persone che generano le proprie immagini ISO tramite la costruzione dal vivo riceverà automaticamente il pacco fisso.