Instalación manual de Kubuntu 20.04 con LUKS y ZFS

Recientemente he estado experimentando con las versiones 20.04 de Ubuntu y Kubuntu y con la versión actual de Tumbleweed, la distribución rolling release de OpenSUSE. Algunos resultados:

  • Kubuntu y OpenSUSE utilizan KDE, mi entorno preferido de escritorio. Ubuntu emplea Gnome, entorno que suelo probar de vez en cuando y cada vez me parece peor (para mi gusto y mis necesidades).

  • Ubuntu y Kubuntu soportan ambos ZFS de forma nativa. Desde que utilicé ZFS en Solaris en 2005, no quiero usar nada más. Los otros sistemas de ficheros son de juguete.

    Además, mi máquina actual emplea ZFS sobre Linux y lo exprimo de forma exhaustiva: snapshots diarios, replicación, copias de seguridad rápidas, clones... No, no quiero usar otra cosa.

  • Kubuntu tiene un soporte de tres años para los paquetes de software propios, mientras que Ubuntu, su base, ofrece cinco años de soporte.

    Esto ya lo he sufrido en mi Sistema Operativo actual, Kubuntu 16.04. Afortunadamente, la base Ubuntu de Kubuntu sí tiene cinco años de soporte.

  • El instalador de Ubuntu incluye un instalador ZFS experimental. El instalador de Kubuntu no.

  • Si haces una instalación ZFS de Ubuntu, no tienes la opción de cifrado. El cifrado solo está disponible para Sistemas de ficheros más tradicionales. Y esto a pesar de que las versiones recientes de ZFS tienen cifrado nativo y que también se podría usar LUKS (que es mi solución hasta el momento).

Descarté OpenSUSE rápidamente porque no tiene un soporte evidente de ZFS, aunque en casa hay otro ordenador con Tumbleweed y estamos contentos con la experiencia. Además, no quiero que todos los ordenadores de casa utilicen la misma rolling release, porque una actualización problemática puede ser una catástrofe.

Mi decisión ha sido la siguiente:

  • Utilizar ZFS con cifrado LUKS.

  • Utilizar Kubuntu, a pesar de tener un soporte más corto. He estado probando Gnome durante una semana y no puedo con él, prefiero mantener mi entorno KDE.

    Es cierto que KDE es un entorno mucho más minoritario y que, con frecuencia, te encuentras con problemas de compatibilidad con software que no se preocupa de hacer las cosas bien, pero es algo que tengo asumido y que, en la mayor parte de los casos, puedo resolver.

El problema es que lo que yo quiero no existe. Me lo tengo que montar yo por mi cuenta.

¿Por qué LUKS y no cifrado nativo ZFS?

Aunque las versiones modernas de ZFS incluyen cifrado nativo, lo cierto es que no me acaba de convencer.

Cosas a favor:

  • Cada dataset puede tener una política de cifrado diferente y claves distintas.

  • No es necesario cifrar todo el pool, se pueden cifrar datasets seleccionados.

  • El cifrado forma parte integral de ZFS, son comandos nuevos de la herramienta de toda la vida, todo perfectamente integrado.

  • Puedo mover un pool ZFS cifrado a otras máquinas con capacidad ZFS, aunque no sean Linux y no sepan interpretar LUKS.

  • ZFS guarda varias copias de los metadatos en el pool. Usando cifrado nativo solo es necesario cifrar una vez y almacenar esa versión cifrada en diferentes lugares. LUKS cifraría cada bloque grabado de forma independiente.

  • Es posible hacer ciertas tareas, como un "zfs send" a una copia de seguridad, aunque no se tenga acceso a la clave de cifrado. El servidor de destino puede recibir esos datos y actualizar el pool sin tener tampoco la clave. No necesita ser de confianza. Esta característica me parece extremadamente interesante.

  • Aunque parece un poco absurdo, se podría usar cifrado nativo ZFS sobre una partición LUKS. Una utilidad evidente sería proteger datos que no usamos de forma habitual, por ejemplo, un monedero BitCoin.

    LUKS protege el disco duro si nos roban el portátil, pero si se nos cuela un cracker mientras lo estamos utilizando, los datos están todos en claro ahí. Tener algún dataset ZFS cifrado de forma nativa puede resultar útil, aunque parezca redundante (el rendimiento sufrirá, ya que el acceso a ese dataset requiere dos operaciones de cifrado o descifrado).

Cosas en contra:

  • Tengo mucha experiencia con LUKS y lo utilizo en infinidad de entornos. Mantener entornos homogéneos ayuda a evitar errores y a reducir la carga mental.

  • Tengo instalaciones ZFS antiguas que no tienen soporte de cifrado nativo y empleo LUKS con ellas. Ver punto anterior.

  • LUKS es una herramienta antigua bien soportada por cualquier distribución de Linux. Útil ante catástrofes.

  • ZFS permite guardar hasta tres copias de un fichero, si es crítico. Si un dataset ZFS activa el cifrado, solo se pueden guardar un máximo de dos copias. Esto no debería ser un problema en la práctica si el Zpool tiene redundancia adicional.

  • El cifrado ZFS no lo oculta todo:

    • Se cifran:

      • Los ficheros y sus metadatos (incluyendo el nombre y los permisos).
      • El listado de directorios.
      • Todos los datos contenidos en un ZVOL.
      • Los mapas FUID.
      • Los datos anteriores que se encuentren en el ZIL.
      • Los datos anteriores que se encuentren en el L2ARC.

    • No se cifra:

      • Los nombre de los datasets y de los snapshots. Esta información puede ser sensible.

      • Las propiedades de los datasets.

      • La distribución física del pool: discos que los componen, sus números de serie, composición de cada VDEV, etc.

      • La propia estructura ZFS en disco. Se podrían hacer alteraciones maliciosas.

      • Las tablas de deduplicación.

        Es raro que un entorno ZFS emplee deduplicación porque suele resultar muy costoso en recursos, aunque en el mundo SSD el coste/beneficio está cambiando.

        En cualquier caso no cifrar esta información filtra la identidad de bloques equivalentes.

      • La historia del pool.

  • La combinación de cifrado y compresión en ZFS puede abrir la puerta a ataques como CRIME. Esto suele tener poca importancia en la práctica, pero puede haber casos en los que haya que tenerlo en cuenta.

  • Que haya datos no cifrados en disco al usar cifrado ZFS nativo permite operar con el pool aunque no se disponga de la clave de acceso. Por ejemplo, se pueden crear y destruir datasets o ver cuánto espacio se está utilizando y dónde.

    Más detalles en ZFS encryption what is on disk ?, Encryption at Rest in ZFS (transparencias) y Encryption at Rest in ZFS (vídeo).

Formateo de disco, creación de LUKS y ZFS, e instalación del sistema operativo

Para lo que sigue, usaré la excelente guía Installing UEFI ZFS Root on Ubuntu 20.04. Sí, mi nueva máquina es UEFI, que $DEITY nos pille confesados.

No voy a repetir los pasos aquí para no plagiar el contenido, solo detallaré mis propias modificaciones:

  • A la hora de instalar el sistema, en vez de instalar ubuntu-desktop-minimal, instalamos kde-full.

  • Durante la instalación se nos pedirá elegir entre dos Desktop Managers: GDM3 y SDDM. Aunque se pueden usar los dos y no voy a compararlos, KDE ha elegido SDDM, así que seguiré su recomendación.

    Esta decisión se puede cambiar a posteriori.

  • De momento no voy a crear una partición de SWAP, ya que tengo 16GB de RAM complementada por una configuración ZRAM.

    De nuevo se trata de una decisión que se puede cambiar a posteriori.

    En este momento usar un ZVOL ZFS para SWAP puede ocasionar cuelgues esporádicos, aunque yo llevo usándolo años con gran presión de memoria y los bloqueos ocurren muy de cuando en vez y, cuando necesitas tirar de SWAP, pues hay que tirar de SWAP...

    Más información:

    Este es un problema solucionado en Solaris hace años.

    Nota

    Otra posibilidad es crear una partición adicional cifrada para el SWAP, pero solo se podría usar para eso, este portátil tiene una SSD de pequeño tamaño y nado en RAM. Para un uso puntual, puedo crear una dataset ZFS de uso temporal y luego recuperar su espacio al terminar.

  • Además de crear un dataset ZFS para /home/, creo otro para /home/jcea/. Esta máquina tiene más usuarios y cada uno tendrá su propio dataset. Hay que tener cuidado con ponerle los permisos apropiados.

  • Esta máquina estará configurada en inglés americano (bien), pero también con el teclado en inglés americano (mal). Cambiamos el idioma del teclado a español de España desde una consola, con el comando dpkg-reconfigure keyboard-configuration. Ahí salen algunas opciones interesantes que tal vez valga la pena investigar en el futuro, como qué hace la tecla AltGr o si queremos una tecla Compose y cuál debe ser.

  • El Splash al arrancar y apagar el equipo pone Ubuntu 20.04. Podemos ver qué temas hay para elegir tecleando el siguiente comando en un terminal: apt list plymouth-theme*. Puedes crear tus propios temas, pero de momento me conformaré con hacer apt install plymouth-theme-kubuntu-logo.

  • Quiero que el idioma del software y de los mensajes de error sea inglés, pero que use el sistema métrico, el formato de fecha y hora español, etc. En las versiones recientes de KDE eso se puede hacer fácilmente indicando que el idioma del usuario es inglés y luego personalizando media docena de controles para que se use el formato de España (fecha y hora, unidad monetaria, ordenación alfabética, números y unidades de medida).

  • La tipografía de la consola es bonita pero muy pequeña. La cambio con el comando dpkg-reconfigure console-setup. Lo cierto es que hay poco donde elegir, pero la consola solo se utiliza si ocurre una catástrofe. El resultado final es legible aunque feo.

  • La instalación manual del sistema operativo que hemos hecho de ZFS no utilizará zsys, lo cual me parece perfecto porque está muy verde y yo llevo años gestionando mi ZFS de forma manual y feliz de ello (snapshots diarios, por ejemplo, y puedo hacer rollback del sistema operativo independientemente de mi usuario o a la inversa).

    Ya veremos qué hago en la actualización de 2022.