Tecnología, Internet y juegos
21 meneos
142 clics

Proponen modernizar el proceso de arranque de Linux

Los cambios propuestos se reducen a la creación de una única imagen universal UKI (Unified Kernel Image) que combina la imagen del kernel de Linux, el controlador para cargar el kernel desde UEFI (UEFI boot stub) y el entorno del sistema initrd cargado en memoria, utilizado para inicialización inicial en la etapa antes de montar el FS. En lugar de una imagen de disco RAM initrd, todo el sistema se puede empaquetar en el UKI, lo que permite la creación de entornos de sistema totalmente verificados que se cargan en la RAM.

| etiquetas: modernizar , proceso , arranque , linux
  1. No se como se llevaría esto con las imágenes initramfs personalizadas que usamos algunos, o como se montaría una alternativa para hacer lo que ahora hacemos así.

    Por cierto que ya existe otra forma de proteger el initrd que es metiéndolo en una partición cifrada y abriendo esa partición desde Grub.
  2. #1 ¿Lee las especificaciones? Las tienes al final del artículo
  3. #1 No creo que se pueda desde UEFI. Antes, con MBR se podia poner el OpenBSD con todo el disco cifrado.

    Ahora en UEFI debes poner un cargador EFI en la particion FAT32 correspondiente.

    www.openbsd.org/faq/faq14.html

    En "If you use GPT for UEFI booting, do:" se ve. Crea una particion /dev/sd0a con todo el disco de tipo RAID, lo cifra y ahi ya crea los slices ("particiones") en Linux. Que no son "particiones", si no subdivisiones de una particion OpenBSD para GPT hecha con disklabel. En MBR funciona igual.
  4. Desde las Costas de la Ignorancia, yo estoy más que satisfecho...  media
  5. #2 Ya las estaba leyendo, y solo dice esto:

    [TPM PCR 13 shall contain measurements of additional extension images for the initrd, to enable a modularized initrd – not covered by this document]

    Y tirando de ese hilo, tampoco dice gran cosa.
  6. #3 Se puede más o menos, pero el cargador UEFI siempre está visible. También es el apaño que se usa para discos externos arrancables, que además del binario EFI para Grub también llevan un Boot portable.

    El resto del disco se puede cifrar completo, pero el soporte en Grub para LUKS2 está un poco en pañales. Así que de momento hay algunas limitaciones.
  7. #7 Como digo en OpenBSD está el loader EFI y luego puedes tener tu particion GPT (OpenBSD a6 en gptdisk/fdisk) cifrada completa como softraid que el cargador la descifra, arranca y monta.

    Linux antaño era mucho mas inseguro por ello, era casi trivial saltarse la protección de arranque.
  8. #9 Como ya he dicho, en OpenBSD va a así y funciona de lujo, con el resto de la particion a6 como softraid y dentro cifrado todo.

    Y de forma mucho más simple, en Linux con LUKS, cryptsetup y LVM queria morirme.
  9. #11 Tras usar OpenBSD para cifrar discos, Linux tiene la misma usabilidad que intentar grabar películas con un VHS en los 90.
  10. O sea: para solucionar el problema de que el initramfs no es verificable por secure boot (razon por la vual se usaban firmas gpg en grub y demas), vamos a meterlo todo en una sola imagen.
    Desde mi punto de vista, esto solo va a servir para aquellos que se instalan linux y quieren depender solo de las actualizaciones que le de la distribucion que se hayan metido. Cualquier individuo/empresa que este interesado en esto ya habra buscado sistemas con TPM, y dado que desde el kernel 5.10 los auxiliares como initramfs ya se pueden medir en el PCR 13, lo que Poettering viene a proponer no soluciona/mejora nada.
  11. #5 a gente como tu, tal como explico en #13, esto no le sirve para nada. Si quieres verificar tu initram, a dia de hoy y con kernels nuevos, tienes que fijarte en el PCR 13 (o firmar initramfs con gpg y validarlo con grub, pero eso te ata a grub). Eso tiene un problema cuando haces una actualizacion si tienes un secreto en el TPM que depende de ese registro (y del 4): tu secreto esta protegido por un estado que no va a darse en el siguiente reset, y despues de leer ese secreto ya has extendido los registros para evitar que se pueda leer otra vez hasta el siguiente arranque. La unica manera de solucionar eso, pero tiene algunos flecos, es haciendo un replay del log de eventos en el TPM y extendiendo los registros con los hashes correspondientes, de manera que desde un estado verificado puedas calcular los hashes de las politicas de cifrado del sistema en el siguiente arranque. Hay gente de tpm-tools haciendo cosas en ese sentido pero esta todo un poco verde.
  12. #14 Yo iba por otro lado. Los que metemos cosas raras en el initrd ahora lo hacemos de manera automática. Escribes triggers personalizados en el árbol de initramfs-tools (o de dracut, para el caso), añades los archivos que necesitas y las actualizaciones simplemente funcionantm. Con este sistema sería un dolor de cabeza automatizar los parcheos.
  13. #15 justamente, por eso no sirve para gente como nosotros. En nuestro caso, solo podemos tratar de ayudar a los de tpm-tools para poder calcular el estado futuro del PCR 13 a partir del initramfs que acabamos de generar, y usar el TPM como verificador.
  14. ¿Y esto funcionaría en sistemas sin UEFI? Como Coreboot, Libreboot, U-boot, y los distintos arranques sin bios UEFI en sistemas de la arquitectura ARM.
  15. #4 Increible comparatica. Y si todo en linux es mejor que windows, ¿cómo es que no lo usa todo el mundo?
    No me digas más, tu también crees que este es el año de linux en el escritorio...
  16. No sé muy bien qué significa, pero sin duda acerca a Linux a su año en el escritorio.
  17. #16 En los BSD y sobre todo OpenBSD todo está hecho como un bloque.
  18. #20 www.google.com/search?client=opera&q=comparatica&sourceid=oper

    Todo aspirante a troll, merece algún que otro hueso :troll:
comentarios cerrados

menéame