Como o Secure Boot realmente funciona?

Question

Estou jogando com o GRUB2, o SecureBoot e o Kernel Signing, e acho que encontrei um possível bug na minha inicialização segura, mas quero verificar primeiro minha compreensão desses processos.

Sei que, quando a Inicialização Segura está habilitada, somente binários assinados com uma Chave carregada no firmware podem ser iniciados, portanto, todos os gerenciadores de inicialização precisam ser assinados. Em um caso típico, são o shim e o GRUB.

O Shim deve almoçar o MoakManager se a inicialização falhar ou você tiver algumas chaves para importar ou excluir e, se estiver tudo certo, ele deverá iniciar o GRUB, que é o gerenciador de inicialização real.

O problema é que acabei de gerar uma versão personalizada do GRUB com grub-mkstandalone que assinei com uma nova chave criada com o OpenSSl; uma chave que ainda não importei no firmware, e o shim conseguiu iniciá-la sem nenhum relatório do Secure Boot.

Eu verifiquei as chaves com mokutil --list-enrolled e ele relatou apenas o certificado canônico.

Então, para recapitular:

Na minha partição EFI, tenho:

• shimx64.efi assinado pela Canonical, gerado com o grub-install
• meu GRUB personalizado, gerado com o grub-mkstandalone, assinado com minha própria chave, que ainda não importei, denominado grubx64.efi .

Na inicialização, o SHIM poderia almoçar o GRUB e o GRUB poderia inicializar o Ubuntu com sucesso.

Se alguma Inicialização Segura verificar apenas o sinal do primeiro carregador de inicialização e os outros carregadores forem responsáveis por verificar a si mesmos e os módulos que eles pré-carregam e os usuários eventualmente carregam, a preocupação de segurança é muito grande.

Vou fazer mais alguns testes, mas talvez eu deva abrir um ticket de bug.

Alguma idéia?

    

Answer 1

Acredito que sua compreensão esteja correta, exceto que shimx64.efi é entregue em formato binário por meio de um pacote, não gerado localmente por meio de grub-install . ( grub-install é provável que instale shimx64.efi para o ESP, no entanto.) Ah, e é o MokManager, não o MoakManager.

Antes de enviar um relatório de bug, você deve refazer seus passos e ter 100% de certeza de que está inicializando através do seu GRUB compilado localmente. É fácil acidentalmente colocar um binário no local errado ou deixar de executar efibootmgr para ajustar a ordem de inicialização, por exemplo. (Você não descreveu como está instalando seu personalizado grubx64.efi - você está sobrescrevendo o binário padrão do Ubuntu ou colocando o novo em outro lugar e registrando-o [e uma cópia do Shim] via efibootmgr ?) Você pode querer para executar sudo efibootmgr -v para ver seus detalhes de inicialização. Preste atenção nas linhas BootOrder e BootCurrent - o primeiro informa a ordem em que as opções de inicialização serão tentadas e a última mostra a opção que foi usada para inicializar o computador. Você precisará fazer referência cruzada aos números com as várias Boot#### linhas que descrevem cada opção de inicialização. Se você instalou seu próprio GRUB separado do GRUB do Ubuntu, é possível que o firmware o tenha ignorado por causa de um erro de inicialização segura e, em seguida, recue no Ubuntu Shim / GRUB, o que explicaria o que você está vendo.

Outra possibilidade é que o Secure Boot não está realmente habilitado no seu computador. Você pode verificar essa possibilidade da seguinte forma:

$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 
0000000 0016 0000 0001              
0000005

Neste exemplo, a primeira linha de saída ( 0000000 0016 0000 0001 ) termina em 1 . Isso indica que a inicialização segura está ativa. Se ele terminar em 0 , o Secure Boot será desativado no seu computador.

Outra possibilidade é que você possa ter instalado de alguma forma sua chave local na própria lista db do firmware. Esta é uma tarefa difícil, portanto, é improvável que você tenha feito isso acidentalmente e sem perceber. (Veja minha página sobre o assunto para detalhes sobre como configurar isso.) Eu mencionei isso possibilidade principalmente por uma questão de completude; não me parece tão provável a menos que você esteja omitindo a menção de uma tentativa anterior de dominar o Secure Boot dessa maneira.

Se você estiver vendo um bug, ele pode estar no Shim ou no seu firmware.

Mais uma ressalva é que estou familiarizado apenas com as ferramentas específicas do GRUB, como grub-mkstandalone . Como eu mantenho o rEFInd, eu prefiro usá-lo, então meu conhecimento das ferramentas do GRUB não é tão profundo quanto poderia ser. Assim, posso estar perdendo alguns detalhes críticos porque é específico do GRUB.