Hace un tiempo, se informó un error con la instalación encriptada LVM en Kali Linux 1.0.4 en nuestro rastreador de errores. Este error era de alta prioridad en nuestra TODO, ya que las instalaciones cifradas son una característica importante en nuestra industria, por lo que queríamos solucionar este error lo antes posible. Este artículo describirá el proceso de depuración, identificación y corrección de este error en Kali y, en última instancia, también en Debian.
El error en sí era extraño; instalar Kali con la opción "LVM Encrypted" daría como resultado un arranque fallido una vez que se haya realizado la instalación:
La solución sugerida en el informe de errores indicaba que /etc/crypttab el archivo estaba vacío. Al volver a montar manualmente la partición cifrada, volver a llenarla con los parámetros requeridos y luego actualizar initramfs, la máquina se reiniciará correctamente en la partición cifrada nuevamente. Definitivamente molesto y lejos de ser práctico.
Ahora bien, con el problema bien definido, la solución parecía sencilla. Probablemente algo estaba mal con la forma /etc/crypttab se actualiza durante el proceso de instalación. Nuestro próximo paso fue investigar los scripts responsables de esta actualización y ver si hay errores en el proceso de actualización de archivos. Pero, ¿cómo ubicaría el script exacto responsable de esta actualización y cómo podríamos averiguar en qué paquete se encuentra?
A nuestro rescate viene DebianInstaller. Usando este conjunto de scripts, verificamos todo el árbol fuente de DebianInstaller. Esto nos permitiría buscar los scripts que afectan a /etc/crypttab con mucha mayor facilidad.
[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 vez que todos los repositorios hayan sido revisados, podríamos simplemente buscar cualquier archivo que haga referencia a /etc/crypttab archivo de la siguiente manera:
[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#
Vemos arriba que es el "crypto_config ” script que escribe en /etc/crypttab , que se encuentra en el partman-crypto paquete.
Idealmente, nos gustaría depurar este script y ver dónde está el problema, pero ¿cómo haría esto en un medio de instalación en vivo? La respuesta es relativamente simple:solo tuvimos que abrir un símbolo del sistema durante el proceso de instalación. El truco es invocar nuestro shell de depuración (presionando CTRL+ALT+F2) durante la etapa correcta de la instalación; en nuestro caso, necesitábamos interrumpir el instalador antes de crypto_config se ejecutó el script pero después de partman-crypto Se instaló udeb, por lo que el comienzo del proceso de partición sería un buen lugar. Procedemos a editar el /lib/partman/finish.d/55_crypto_config y agregó "establecer -x ” al comienzo del guión:
Luego dejamos que el instalador haga lo suyo y justo antes de que se complete la instalación, echamos un vistazo a /var/log/syslog en otra concha. Para nuestra sorpresa, vimos que /etc/crypttab El archivo *estaba* siendo actualizado, contrariamente a nuestras creencias iniciales, como se puede ver en el syslog de la instalación. 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
Aquí es donde empezamos a rascarnos la cabeza. Si el problema no estaba en la escritura de este archivo (como esperábamos), ¿por qué había un /etc/crypttab vacío? archivo después de la instalación? Quizás el problema no estaba en partman-crypto después de todo, sino en cómo construir en vivo genera nuestras ISOs? Probamos esta teoría nuestra mediante el uso de una miniinstalación ISO de Kali (no creada a través de una compilación en vivo) y notamos que las instalaciones cifradas con LVM funcionaban bien cuando se usaba ese medio de instalación.
Sabemos que el instalador en vivo usa tar para copiar todo el sistema de archivos en vivo en un /target montado directorio y asume que los sistemas de archivos están vacíos, lo cual es mayormente cierto ya que fueron creados por partman. Esto significa que cualquier archivo preexistente se puede sobrescribir si también está en la imagen en vivo, lo que le estaba sucediendo a /etc/crypttab en este caso.
Un examen más detenido reveló que el problema estaba en live-installer , por lo que sobrescribe el /etc/crypttab generado . El instalador en vivo ya tiene algunas disposiciones para no sobrescribir /etc/fstab , por lo que solo es cuestión de generalizar esa regla e incluir el /etc/crypttab archivo también:
$ 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"
El parche anterior solucionó el problema para nosotros, lo que permitió que las instalaciones de LVM encriptadas se completaran y arrancaran correctamente. Al igual que con cualquier error de Debian que encontremos, enviamos parches a Debian para mejorar la distribución sobre la que construimos. Una solución para este error del instalador saldrá en nuestro próximo lanzamiento puntual (1.0.5) la próxima semana. Personas que generan sus propias imágenes ISO a través de construcción en vivo recibirá automáticamente el paquete fijo.