Canonical ha introducido en Ubuntu 26.10 un recorte del soporte de GRUB cuando el equipo arranca con Secure Boot activado. El objetivo declarado es reducir la cantidad de código que se ejecuta en las primeras fases del arranque y, con ello, la superficie de ataque potencial sobre la cadena de confianza del sistema.
Qué cambia en el arranque y por qué importa
La compilación firmada de GRUB que se carga bajo Secure Boot dejará de soportar la ruta /boot sobre determinados sistemas de archivos y configuraciones avanzadas. Con Secure Boot activo, Ubuntu 26.10 mantendrá únicamente la capacidad de leer /boot si está en ext4, FAT o ISO9660 (este último para arranques desde CD/DVD), además de squashfs para paquetes snap. En consecuencia, /boot en Btrfs, XFS o ZFS, en volúmenes lógicos LVM, en particiones cifradas con LUKS o en arreglos RAID por software no será accesible para ese GRUB firmado; la única excepción citada es RAID1, que seguirá soportado.
Canonical justifica la medida por razones de seguridad: los parsers de sistemas de archivos y de tablas de particiones que GRUB carga para localizar el kernel han sido históricamente vectores de vulnerabilidades que permiten eludir protecciones de Secure Boot. Reducir el conjunto de código ejecutable en esa etapa temprana acota el riesgo, según la compañía, especialmente ante el aumento en el uso de herramientas de IA para identificar fallos.
Quién se ve afectado y alcance práctico
El cambio solo impacta cuando Secure Boot está habilitado en la UEFI. Si se desactiva Secure Boot, GRUB carga su repertorio completo de módulos y no habrá limitaciones sobre sistemas de archivos ni carga de fondos gráficos o características similares.
En la práctica, la mayoría de instalaciones estándar no deberían verse afectadas: el instalador oficial de Ubuntu suele configurar /boot en particiones compatibles por defecto (ext4 o FAT). Los usuarios que empleen esquemas de particionado personalizados o avanzados —por ejemplo, /boot en Btrfs, ZFS, LVM, dentro de volúmenes cifrados con LUKS o en ciertos RAID software— deberán comprobar su diseño antes de actualizar a Ubuntu 26.10 para evitar que el sistema no arranque con Secure Boot activado.
Qué deben hacer administradores y propietarios de sitios
- Verificar la ubicación y el sistema de archivos de /boot antes de actualizar. Si /boot reside en un formato no compatible con GRUB firmado, planear una migración de /boot a ext4 o una partición FAT que sea accesible al cargador.
- Si dependen de configuraciones avanzadas que requieren Secure Boot y la funcionalidad completa de GRUB, considerar posponer la actualización y permanecer en la versión LTS disponible, que mantiene compatibilidad más amplia, hasta planificar los cambios.
- Como alternativa temporal, desactivar Secure Boot en la UEFI si la política de seguridad lo permite; así GRUB cargará sus módulos completos y permitirá los esquemas de arranque previos. Hay que valorar el impacto en la seguridad antes de optar por esta vía.
- Hacer copias de seguridad y probar el arranque en un entorno de ensayo o máquina virtual antes de aplicar la actualización en sistemas de producción.
Contexto y consideraciones técnicas
GRUB actúa justo después del firmware (UEFI) verificado por Secure Boot, por lo que cualquier vulnerabilidad en su código de lectura de /boot podría comprometer la cadena de confianza. Al simplificar los parsers y reducir los formatos admitidos en la versión firmada, Canonical busca minimizar ese riesgo. Aunque tecnologías como Btrfs, ZFS, LVM o LUKS siguen soportadas por el sistema operativo, deben dejar archivos clave de /boot en un formato que GRUB firmado pueda leer si Secure Boot permanece activado.
La decisión se anunció durante la fase beta de Ubuntu 26.10 y se lanza tras una versión LTS, lo que permite a administradores con necesidades específicas seguir en la versión LTS mientras adaptan sus sistemas. Para la mayoría de usuarios que usan el particionado guiado por defecto, no habrá cambios perceptibles.
Lee también:
- El grupo UAC-0099 renueva su dropper ‘MatchBoil’ para evadir detección en campañas contra organizaciones ucranianas
- Secuestradores comprometieron tres ccTLD y obtuvieron certificados HTTPS no autorizados para dominios de Google y otros
Fuente: MuyLinux
