[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

¡Esta es una revisión vieja del documento!


Traduccion en progreso Ak3.devel

Habilitando el arranque seguro en Slackware

En el hardware basado en la Interfaz de firmware extensible unificada (UEFI), un sistema puede operar en modo de arranque seguro. En el modo de arranque seguro, solo los binarios EFI (es decir, los gestores de arranque, los cargadores de arranque) en los que el propietario de la plataforma confía, ya sea explícitamente o mediante una cadena de confianza, pueden ejecutarse en el momento del arranque. Esto evita que los binarios y sistemas operativos no autorizados de EFI se ejecuten en su sistema, lo que puede mejorar la seguridad.

Este artículo te enseñará:

  • Acerca de las claves de arranque seguro y las bases de datos de firmas
  • Cómo registrar claves de arranque seguro mientras se inicia en Slackware
  • Cómo firmar archivos binarios de EFI para su uso en el modo de arranque seguro.
Asegúrese de que puede encontrar y manipular la configuración de arranque seguro con el firmware UEFI de su sistema. De esa manera, si comete un error, simplemente puede desactivar el Arranque seguro para tener nuevamente un sistema de arranque.
Una vez que haya cambiado sus claves de arranque seguro, haya firmado sus binarios de EFI y haya probado que el arranque seguro está funcionando, debe almacenar sus claves privadas en un lugar seguro hasta que las claves sean requeridas nuevamente. Cualquier persona con acceso a sus claves privadas puede pasar por alto la protección que ofrece el arranque seguro.

Claves de arranque seguro y bases de datos de firmas

Se utilizan dos tipos de claves de arranque seguro para crear relaciones de confianza:

  • Clave de la plataforma: esto establece la relación de confianza entre el propietario de la plataforma y el firmware de la plataforma. El firmware UEFI solo puede almacenar una clave de plataforma. La clave pública se almacena en la variable de arranque seguro PK . Esta clave permite al propietario de la plataforma manipular todas las claves de arranque seguro y las bases de datos de firmas.
  • Key Exchange Key: establece la relación de confianza entre el sistema operativo y el firmware de la plataforma. El firmware UEFI puede almacenar múltiples claves de intercambio de claves. Las claves públicas se almacenan en la variable de arranque seguro “KEK”. Key Exchange Keys solo permite que el sistema operativo manipule las bases de datos de firmas.

Hay dos bases de datos de firmas para autorizar binarios de EFI:

  • Base de datos de firmas prohibidas: almacena hashes y claves de firma públicas de binarios EFI prohibidos. Esto utiliza la variable de arranque seguro dbx . Los binarios EFI con hashes presentes en esta base de datos o firmas que pueden autenticarse con una clave de firma almacenada en la base de datos tienen prohibido cargarse.
  • Base de datos de firmas autorizada: almacena hashes y claves de firma públicas de binarios de EFI de confianza. Esto utiliza la variable de arranque seguro db . Los binarios EFI con hashes presentes en esta base de datos o firmas que pueden autenticarse usando una clave de firma almacenada en la base de datos pueden ejecutarse si no hay coincidencias con ninguna entrada en la base de datos de firmas prohibidas.

Requisitos

Necesitarás el paquete efitools and sbsigntools antes de que empieces. En Slackbuilds están disponibled http://slackbuilds.org.

Si aún no tiene su propia clave de plataforma inscrita en el firmware UEFI, el howto asume que tiene desactivado el arranque seguro y que ha borrado la variable PK en el firmware UEFI.

Inscripción de claves de inicio seguro y entradas de base de datos de firmas

Si no tiene un par de claves de plataforma existentes y un par de claves de firma binaria EFI, el método más sencillo para crear los pares de claves sería crear claves autofirmadas. Se recomienda crear pares de claves RSA de 2048 bits que usen el algoritmo de firma sha256RSA. Para generar claves autofirmadas con las propiedades recomendadas, ejecute:

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Platform Key Common Name/" \
        -keyout PK.priv -out PK.pub -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=EFI Binary Signing Key Common Name/" \
        -keyout db.priv -out db.pub -days 3650 -nodes -sha256

que crea claves privadas con la extensión .priv y certificados de clave pública con la extensión .pub . Es posible que desee ajustar el período de validez de la clave y elegir un Nombre común (CN) diferente para ayudar a distinguir sus claves.

No es necesario crear o usar su propia clave de intercambio de clave, ya que está destinada a ser utilizada por los sistemas operativos. Sin embargo, a continuación se proporcionan las instrucciones de Key Exchange Key para que sepa cómo inscribir las Key Exchange Keys para los sistemas operativos que lo requieren.

To prepare a new Platform Key for writing to the PK variable:

  1. Insert the public Platform Key into an EFI signature list:
    cert-to-efi-sig-list -g owner_guid PK.pub PK.esl 

    replacing owner_guid with a hexadecimal GUID in the format 12345678-1234-1234-123456789abc. The owner GUID should be the same for all keys that you own. If an operating system cannot add a signature to a signature database due to a lack of resources, it may remove a signature with an owner GUID associated with the operating system.

  2. Sign the EFI signature list. In Setup mode (Secure Boot off) the private half of the inserted key should sign the signature list. In User mode (Secure Boot on) the private key of the current Platform key should sign the signature list:
    sign-efi-sig-list -k PK.priv -c PK.pub PK PK.esl PK.signed

A similar procedure applies for preparing a Key Exchange Key or a signature database entry for writing to the KEK, db, or dbx variables. Key Exchange Keys must be signed by the private half of the Platform Key:

cert-to-efi-sig-list -g owner_guid KEK.pub KEK.esl
sign-efi-sig-list -a -k PK.priv -c PK.pub KEK KEK.esl KEK.signed

And signature database entries must be signed by the private half of the Platform Key or any of the Key Exchange Keys:

cert-to-efi-sig-list -g owner_guid db.pub db.esl
sign-efi-sig-list -a -k PK.priv -c PK.pub db db.esl db.signed

Note that the -a option was used to prepare for an append write.

To update the Secure Boot variables you must have root privileges. You will need to load the efivarfs kernel module and mount the efivarfs filesystem beforehand if it has not been taken care of already:

modprobe efivarfs
mount -t efivarfs efivarfs /sys/firmware/efi/efivars

To enroll the Platform Key, run:

efi-updatevar -f PK.esl.signed PK

If the system was in Setup mode it will now be in User mode.

To add keys to the KEK, db or dbx variables, run (as appropriate):

efi-updatevar -a -f KEK.signed KEK
efi-updatevar -a -f db.signed db
efi-updatevar -a -f dbx.signed dbx

You can check that your keys have been properly enrolled using efi-readvar.

Signing EFI Binaries

My recommendation (at the time of writing) is that you either use a boot manager with an EFI stub kernel, or directly boot an EFI stub kernel. ELILO, efilinux and syslinux (and possibly GRUB but I do not know for sure) will allow unsigned kernels to run (or at least it does on my hardware and VM), which defeats the purpose of Secure Boot. If you do follow my recommendation, make sure you sign your kernel every time you change it.

You will need to sign all EFI binaries, up to, and including your bootloader and/or EFI stub kernel. To sign an binary, run:

sbsign --key db.priv --cert db.pub --output signed_binary.efi binary.efi

An example of how to add an EFI stub kernel entry using efibootmgr is:

efibootmgr -c -L SlackSecureBoot -l '\EFI\Slackware\vmlinuz-signed.efi' -u 'root=/dev/sda3'
If you see warning: gap in section table when signing an EFI binary (see below), the binary will probably not work in Secure Boot mode. This warning appears for EFI binaries built against earlier gnu-efi library versions. If you plan to use ELILO you will need to recompile it yourself, the version shipped with Slackware will not work.
warning: gap in section table:
    .text   : 0x00000400 - 0x00017c00,
    .reloc  : 0x00017ca1 - 0x000180a1,
warning: gap in section table:
    .reloc  : 0x00017ca1 - 0x000180a1,
    .data   : 0x00018000 - 0x00033000,
gaps in the section table may result in different checksums
warning: data remaining[225792 vs 242346]: gaps between PE/COFF sections?

Disabling Secure Boot

If you want to remove all Secure Boot keys and revert to Setup mode, the easiest way to do so is to sign an empty file with your Platform Key and write the signed file to all the Secure Boot variables:

touch empty
sign-efi-sig-list -k PK.priv -c PK.pub PK empty empty.signed
efi-updatevar -f empty.signed PK
efi-updatevar -f empty.signed KEK
efi-updatevar -f empty.signed db
efi-updatevar -f empty.signed dbx

Dual/Multi-booting with Windows

If Windows is one of your boot options, you will need the Microsoft KEK and db certificates. The certificates can be found at https://technet.microsoft.com/en-us/library/dn747883.aspx and will need to be converted from DER format to PEM format:

openssl x509 -in certificate.der -inform DER -out certificate.pem

The instructions that were provided above can then be used to enroll the certificates. The owner GUID you should use for Microsoft keys is 77fa9abd-0359-4d32-bd60-28f4e78f784b.

Sources

 es:howtos:security:enabling_secure_boot ()