Habilitando a Inicialização Segura no Slackware

Em hardware baseado na Interface de Firmware Extensível Unificada (UEFI), um sistema pode operar no modo de Inicialização Segura. No modo de Inicialização Segura, somente os binários EFI (ou seja, gerenciadores de inicialização, carregadores de inicialização) que são confiáveis ​​pelo proprietário da plataforma, seja explicitamente ou por meio de uma cadeia de confiança, podem ser executados durante a inicialização. Isso impede que binários EFI e sistemas operacionais não autorizados sejam executados em seu sistema, o que pode melhorar a segurança.

Este artigo vai te ensinar:

Certifique-se de que consegue encontrar e manipular as configurações de Inicialização Segura (Secure Boot) no firmware UEFI do seu sistema. Dessa forma, se cometer um erro, basta desativar a Inicialização Segura para ter um sistema inicializável novamente.
Após alterar suas chaves de Inicialização Segura, assinar seus binários EFI e testar se a Inicialização Segura está funcionando, você deve armazenar suas chaves privadas em um local seguro até que elas sejam necessárias novamente. Qualquer pessoa com acesso às suas chaves privadas pode burlar a proteção oferecida pela Inicialização Segura.

Chaves de inicialização segura e bancos de dados de assinaturas

Dois tipos de chaves de Inicialização Segura são usados ​​para criar relações de confiança:

Existem dois bancos de dados de assinaturas para autorizar binários EFI:

Requisitos

Você precisará dos pacotes efitools e sbsigntools antes de começar. Os Slackbuilds estão disponíveis em http://slackbuilds.org.

Caso você ainda não tenha sua própria chave de plataforma cadastrada no firmware UEFI, este guia pressupõe que você tenha desativado a Inicialização Segura e apagado a PK variável no firmware UEFI.

Cadastro de chaves de inicialização segura e entradas de banco de dados de assinaturas

Geração de Chaves Autoassinadas

Se você não possui um par de chaves de plataforma e um par de chaves de assinatura binária EFI, o método mais fácil para criar esses pares de chaves é gerar chaves autoassinadas. Recomenda-se criar pares de chaves RSA de 2048 bits que utilizem o algoritmo de assinatura sha256RSA. Para gerar chaves autoassinadas com as propriedades recomendadas, execute:

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 cria chaves privadas com a .priv extensão .private e certificados de chave pública com a .pub extensão .public. Você pode ajustar o período de validade da chave e escolher um Nome Comum (CN) diferente para ajudar a distinguir suas chaves.

Não é necessário criar ou usar sua própria Chave de Troca de Chaves, pois ela é destinada ao uso pelos sistemas operacionais. No entanto, as instruções para a Chave de Troca de Chaves foram fornecidas abaixo para que você entenda como cadastrar as Chaves de Troca de Chaves nos sistemas operacionais que as exigem.

Preparando a nova Chave de Plataforma (PK)

Insira a chave pública da plataforma em uma lista de assinaturas EFI:

cert-to-efi-sig-list -g owner_guid PK.pub PK.esl

substituindo owner_guid por um GUID hexadecimal no formato <nome_da_chave> 12345678-1234-1234-123456789abc. O GUID do proprietário deve ser o mesmo para todas as chaves que você possui.

Assine a lista de assinaturas EFI. No modo de configuração (Inicialização Segura desativada), a metade privada da chave inserida deve assinar a lista de assinaturas. No modo de usuário (Inicialização Segura ativada), a chave privada da chave da plataforma atual deve assinar a lista de assinaturas.

sign-efi-sig-list -k PK.priv -c PK.pub PK PK.esl PK.signed

Preparando KEK, db ou dbx

Um procedimento semelhante se aplica à preparação de uma Chave de Troca de Chaves ou de uma entrada de banco de dados de assinaturas. As Chaves de Troca de Chaves devem ser assinadas pela metade privada da Chave da Plataforma:

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

E as entradas do banco de dados de assinaturas devem ser assinadas pela metade privada da Chave da Plataforma ou por qualquer uma das Chaves de Troca de Chaves:

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 que a -a opção foi usada para preparar uma gravação de acréscimo.

Atualizando as Variáveis de Inicialização Segura

Para atualizar as variáveis ​​de Inicialização Segura, você precisa ter privilégios de root. Será necessário carregar o módulo do kernel efivarfs e montar o sistema de arquivos efivarfs previamente, caso isso ainda não tenha sido feito.

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

Para cadastrar a chave da plataforma, execute:

efi-updatevar -f PK.esl.signed PK

Se o sistema estava no modo de configuração, agora estará no modo de usuário.

Para adicionar chaves às variáveis KEK, db ou dbx, execute (conforme apropriado):

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

Você pode verificar se suas chaves foram devidamente cadastradas usando efi-readvar.

Assinatura de binários EFI

Minha recomendação (no momento em que escrevo) é que você use um gerenciador de inicialização com um kernel stub EFI ou inicialize diretamente com um kernel stub EFI. ELILO, efilinux e syslinux (e possivelmente GRUB, mas não tenho certeza) permitem a execução de kernels não assinados (ou pelo menos é o que acontece no meu hardware e máquina virtual), o que anula o propósito da Inicialização Segura. Se você seguir minha recomendação, certifique-se de assinar seu kernel sempre que fizer uma alteração.

Assinando o Binário

Para assinar um binário, execute:

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

Um exemplo de como adicionar uma entrada de kernel stub EFI usando o efibootmgr é:

efibootmgr -c -L SlackSecureBoot -l '\EFI\Slackware\vmlinuz-signed.efi' -u 'root=/dev/sda3'
Se você vir warning: gap in section table este aviso ao assinar um binário EFI (veja abaixo), provavelmente o binário não funcionará no modo Secure Boot. Este aviso aparece para binários EFI compilados com versões anteriores da biblioteca gnu-efi. Se você pretende usar o ELILO, precisará recompilá-lo, pois a versão fornecida com o Slackware não funcionará.
Aviso: lacuna na tabela da seção:
    .texto: 0x00000400 - 0x00017c00,
    .reloc : 0x00017ca1 - 0x000180a1,
Aviso: lacuna na tabela da seção:
    .reloc : 0x00017ca1 - 0x000180a1,
    .data: 0x00018000 - 0x00033000,
Lacunas na tabela de seções podem resultar em somas de verificação diferentes.
Aviso: dados restantes [225792 vs 242346]: lacunas entre as seções PE/COFF?

Desativando a Inicialização Segura

Se você deseja remover todas as chaves de Inicialização Segura e retornar ao modo de Configuração, a maneira mais fácil de fazer isso é assinar um arquivo vazio com sua Chave da Plataforma e gravar o arquivo assinado em todas as variáveis ​​de Inicialização Segura:

touch vazio
sign-efi-sig-list -k PK.priv -c PK.pub PK empty empty.signed
efi-updatevar -f vazio.PK assinado
efi-updatevar -f KEK vazio e assinado
efi-updatevar -f banco de dados vazio e assinado
efi-updatevar -f dbx vazio e assinado

Inicialização dupla/múltipla com Windows

Se o Windows for uma das suas opções de inicialização, você precisará dos certificados KEK e db da Microsoft. Os certificados podem ser encontrados em https://technet.microsoft.com/en-us/library/dn747883.aspx e precisarão ser convertidos do formato DER para o formato PEM.
openssl x509 -in certificate.der -inform DER -out certificate.pem

As instruções fornecidas acima podem então ser usadas para registrar os certificados. O GUID do proprietário que você deve usar para as chaves da Microsoft é 77fa9abd-0359-4d32-bd60-28f4e78f784b.


Fontes

Originalmente escrito por turtleli

Mais informações podem ser encontradas em: