o que é o arranque seguro do UEFI?

UEFI Secure boot é um mecanismo de verificação para garantir que o código lançado pelo firmware é confiável.

O uso seguro e adequado do Boot seguro UEFI requer que cada binário carregado no boot seja validado contra chaves conhecidas, localizadas em firmware, que denote fornecedores confiáveis e fontes para os binários, ou binários específicos confiáveis que podem ser identificados através de hashing criptográfico.

A maioria do hardware x86 vem da fábrica pré-carregada com as chaves Microsoft. Isto significa que geralmente podemos confiar no firmware desses sistemas para confiar em binários que são assinados pela Microsoft, e a comunidade Linux depende fortemente desta suposição para o arranque seguro para funcionar. Este é o mesmo processo usado por Red Hat e SUSE, por exemplo.

muitas arquiteturas ARM e outras também suportam o Boot seguro UEFI, mas pode não ser Chaves de pré-carregamento em firmware. Nestas arquiteturas, pode ser necessário voltar a assinar imagens de arranque com um certificado que é carregado em firmware pelo proprietário do hardware. plano de execução inicial: plano de execução.

arquiteturas suportadas

• amd64: um binário shim assinado pela Microsoft e um binário grub assinado pela Canonical são fornecidos no arquivo principal Ubuntu como shim-assinado ou grub-efi-amd64-assinado.

• arm64: a partir de 20.04 (‘focal’), uma binária shim assinada pela Microsoft e binária grub assinada pela Canonical são fornecidos no arquivo principal Ubuntu como shim-signed ou grub-efi-arm64-signed. Há um bug GRUB sob investigação que precisa ser resolvido antes que este trabalho termine.

Testing UEFI Secure Boot

Se estiver interessado em testar o Secure Boot no seu sistema, consulte o how-to here: UEFI/SecureBoot / Testing.

Como UEFI Secure Boot funciona no Ubuntu

No Ubuntu, todos os pré-construído binários pretende ser carregado como parte do processo de boot, com exceção da imagem do initrd, são assinados Canônico UEFI certificado, que é implicitamente confiável para ser incorporado no calço carregador próprio, assinado pela Microsoft.

nas arquitecturas ou sistemas em que os certificados de assinatura pré-carregados da Microsoft não estão disponíveis ou são carregados em firmware, os utilizadores podem substituir as assinaturas existentes no shim ou grub e carregá-las como quiserem, verificando contra os seus próprios certificados importados no firmware do sistema.

Como o sistema boots, firmware carrega o binário shim conforme especificado em variáveis de inicialização de firmware. Ubuntu instala seu próprio BootEntry na hora de instalação e pode atualizá-lo a qualquer momento que o bootloader GRUB é atualizado. Uma vez que o binário shim é assinado pela Microsoft; é validado e aceito pelo firmware ao verificar contra certificados já presentes no firmware. Uma vez que o binário shim incorpora um certificado canônico, bem como seu próprio banco de dados de confiança, outros elementos do ambiente de boot podem, além de serem assinados por um dos certificados aceitáveis pré-carregados em firmware, ser assinados pela chave UEFI da Canonical.

a próxima coisa carregada por shim é a imagem da segunda fase. Isto pode ser uma de duas coisas: ou GRUB, se o sistema está inicializando normalmente; ou MokManager, se a gestão de chaves for necessária, como configurado por variáveis de firmware (normalmente alterado quando o sistema estava em execução anteriormente).

se inicializar normalmente; o binário GRUB (grub*.efi) é carregado e a sua validação é tentada contra todas as fontes de confiança anteriormente conhecidas. O binário GRUB para Ubuntu é assinado pela chave canônica UEFI, então ele é validado com sucesso e o processo de boot continua.

se inicializar para prosseguir com tarefas de gestão de chaves, o binário do MokManager (mm*.efi) está carregada. Este binário é explicitamente confiado por shim por ser assinado por uma chave efêmera que só existe enquanto o binário shim está sendo construído. Isto significa que apenas o binário MokManager construído com um binário shim particular será permitido executar e limita a possibilidade de compromisso a partir do uso de ferramentas comprometidas. O MokManager permite a qualquer utilizador presente na consola do sistema registar as chaves, remover as chaves de confiança, registar os traços binários e comutar a validação segura do arranque ao nível do shim, mas a maioria das tarefas exigem que seja introduzida uma senha previamente definida para confirmar que o utilizador na consola é, de facto, a pessoa que solicitou alterações. Tais senhas só sobrevivem em uma única corrida de shim / MokManager; e são limpas assim que o processo é concluído ou cancelado. Uma vez que a gestão de chaves é concluída, o sistema é reiniciado e não simplesmente continuar com o arranque, uma vez que as alterações de gestão de chaves podem ser necessárias para completar com sucesso o arranque.

Uma vez que o sistema continua inicializando para GRUB; o processo GRUB carrega qualquer configuração necessária (normalmente carregando a configuração da ESP (partição do sistema EFI), apontando para outro arquivo de configuração na partição raiz ou inicialização), que irá apontar para a imagem do kernel para carregar.

aplicações EFI até este ponto com acesso total ao firmware do sistema, incluindo o acesso a variáveis de firmware de confiança em mudança, o kernel a carregar também deve ser validado com base de dados trust. Kernels oficiais do Ubuntu sendo assinados pela chave canônica UEFI, eles são validados com sucesso, e o controle é entregue ao kernel. As imagens Initrd não estão validadas.

no caso de kernels não oficiais, ou kernels construídos pelos utilizadores, devem ser tomadas medidas adicionais se os utilizadores desejarem carregar esses kernels, mantendo ao mesmo tempo todas as capacidades do Arranque Seguro UEFI. Todos os kernels devem ser assinados para ser permitido carregar pelo GRUB quando o UEFI Secure Boot estiver ativado, de modo que o usuário precisará prosseguir com sua própria assinatura. Alternativamente, os usuários podem querer desativar a validação no shim enquanto inicializam com o arranque seguro ativado em um kernel oficial, usando ‘sudo mokutil –disable-validation’, fornecendo uma senha quando solicitado, e reinicializando; ou para desativar o arranque seguro no firmware completamente.

até este ponto, qualquer falha em validar uma imagem para carregar é recebida com um erro crítico que pára o processo de arranque. O sistema não vai continuar inicializando, e pode reiniciar automaticamente após um período de tempo dado que outras variáveis de inicialização podem conter caminhos de inicialização que são válidos e confiáveis.

uma vez carregado, os kernels validados Irão desactivar os Serviços de arranque do firmware, reduzindo assim os privilégios e mudando eficazmente para o modo de utilizador; onde o acesso às variáveis de confiança é limitado apenas à leitura. Dadas as amplas permissões oferecidas aos módulos do kernel, qualquer módulo não incorporado no kernel também terá de ser validado ao carregar. Módulos construídos e enviados pela Canonical com os kernels oficiais são assinados pela chave canônica UEFI e, como tal, são confiáveis. Módulos personalizados irão exigir que o usuário tome as medidas necessárias para assinar os módulos antes que eles os carreguem é permitido pelo kernel. Isto pode ser conseguido usando o comando ‘kmodsign’.

módulos sem sinal são simplesmente recusados pelo kernel. Qualquer tentativa de inseri-los com insmod ou modprobe falhará com uma mensagem de erro.

dado que muitos utilizadores necessitam de módulos de terceiros para que os seus sistemas funcionem correctamente ou para que alguns dispositivos funcionem; e que esses módulos de terceiros requerem a construção local no sistema para ser instalado no kernel em execução, Ubuntu fornece ferramentas para automatizar e simplificar o processo de assinatura. como posso fazer a Assinatura não automatizada de motoristas?

alguns projetos podem exigir o uso de drivers personalizados do kernel que não são configurados de tal forma que para trabalhar com DKMS. Nestes casos, as pessoas devem fazer uso das ferramentas incluídas no Pacote Shim-signed: o script update-secureboot-policy está disponível para gerar um novo MOK (se nenhum módulo DKMS-built já tenha despoletado gerando um).

Use o seguinte comando para registar uma chave existente na shim:

sudo update-secureboot-policy --enroll-key

Se não existir MOK, o programa irá sair com uma mensagem para esse efeito. Se a chave já estiver matriculada, o script sairá, sem fazer nada. Se a chave existe, mas não foi mostrada para ser incluída, o Usuário será solicitado para uma senha para Usar Após o reboot, de modo que a chave pode ser matriculada.

pode-se gerar um novo MOK usando o seguinte comando:

sudo update-secureboot-policy --new-key

e então matricular a chave recém-gerada em shim com o comando anteriormente mencionado para essa tarefa. os módulos do Kernel

podem então ser assinados com o comando kmodsign (veja UEFI/SecureBoot/Signing) como parte do seu processo de compilação.

implicações de segurança na gestão de chaves do dono da máquina

o MOK gerado no momento da instalação ou na atualização é específico da máquina, e apenas permitido pelo kernel ou shim para assinar módulos do núcleo, pelo uso de uma chave específica OID (1.3.6.1.4.1.2312.16.1.2) denotando as limitações do MOK.

As versões recentes de shim incluem lógica para seguir as limitações das chaves de assinatura de módulos. Estas chaves poderão ser inscritas no firmware na base de dados de confiança do shim, mas serão ignoradas quando o shim ou o GRUB validarem imagens para carregar em firmware. A função verificação () do Shim só validará com sucesso as imagens assinadas por teclas que não incluem apenas a “assinatura do módulo” (1.3.6.1.4.1.2312.16.1.2). Os kernels do Ubuntu usam o banco de dados global trust (que inclui tanto o shim como o firmware) e aceitam qualquer uma das chaves incluídas como chaves de assinatura ao carregar módulos do kernel.

dadas as limitações impostas ao MOK gerado automaticamente e o fato de que os usuários com acesso superusuário ao sistema e acesso à consola do sistema para introduzir a senha necessária quando as chaves de inscrição já têm acesso de alto nível ao sistema; a chave Mok gerada é mantida no sistema de arquivos como arquivos regulares pertencentes ao root com permissões de leitura somente. Isto é considerado suficiente para limitar o acesso ao MOK para a Assinatura por usuários maliciosos ou scripts, especialmente dado que não existe MOK no sistema, a menos que ele exija drivers de terceiros. Isso limita a possibilidade de compromisso do uso indevido de uma chave Mok gerada para a assinatura de um módulo de kernel malicioso. Isto é equivalente ao compromisso das aplicações userland que já seria possível com o acesso superusuário ao sistema, e garantir que isso está fora do escopo do Boot seguro UEFI. sistemas anteriores podem ter tido validação segura de inicialização desactivada em shim. Como parte do processo de atualização, esses sistemas serão migrados para re-habilitar a validação segura de inicialização em shim e matricular uma nova chave MOK, quando aplicável.

MOK geração e assinatura de processo

A geração de chaves e assinatura de processo é ligeiramente diferente dependendo se estamos a lidar com uma nova instalação ou uma atualização do sistema de execução anteriormente Ubuntu; estes dois casos são claramente marcados abaixo.

em todos os casos, se o sistema não estiver inicializando no modo UEFI, nenhum módulo especial de assinatura de passos ou geração de chaves irá acontecer.

Se o arranque seguro estiver desactivado, a geração MOK e o registo continuam a acontecer, dado que o utilizador poderá mais tarde activar o arranque seguro. Se for esse o caso, o seu sistema deve funcionar correctamente.

o utilizador instala o Ubuntu num novo sistema

o utilizador passa pelo instalador. Logo no início, quando a preparar para instalar, e somente se, o sistema requer módulos de terceiros para funcionar, o usuário é solicitado para uma senha de sistema que é claramente marcada como sendo necessária, após a instalação estar completa, e enquanto o sistema está sendo instalado, um novo MOK é gerado automaticamente, sem mais a interação do usuário.

drivers de terceiros ou módulos de kernel necessários pelo sistema serão automaticamente construídos quando o pacote for instalado, e o processo de compilação inclui um passo de assinatura. O passo de assinatura usa automaticamente o MOK gerado anteriormente para assinar o módulo, de modo que ele pode ser imediatamente carregado uma vez que o sistema é reiniciado e o MOK é incluído no banco de dados de confiança do sistema.

Uma vez que a instalação está completa e o sistema é reiniciado, no primeiro arranque o Usuário é apresentado com o programa MokManager (parte do carregador de shim instalado), como um conjunto de painéis de modo de texto que todo o Usuário para registrar o MOK gerado. O usuário seleciona “matricular MOK”, é mostrado uma impressão digital do certificado para se inscrever, e é solicitado a confirmar a inscrição. Uma vez confirmado, o novo MOK será inserido em firmware e o Usuário será convidado a reiniciar o sistema.

Quando o sistema reiniciar, os motoristas de terceiros assinados pelo MOK apenas matriculados serão carregados conforme necessário.

o usuário atualiza um sistema Ubuntu ativado pelo UEFI para uma nova versão onde o sistema requer drivers de terceiros

na atualização, os pacotes com assinatura shim e shim são atualizados. As tarefas pós-instalação do pacote assinado pelo shim passam a gerar um novo MOK, e pede ao usuário uma senha que é claramente mencionada como sendo necessária uma vez que o processo de atualização seja concluído e o sistema reiniciado.

durante a atualização, os pacotes do kernel e módulos de terceiros são atualizados. Módulos de terceiros são reconstruídos para os novos kernels e seu processo pós-construção prossegue para assiná-los automaticamente com o MOK.

Após a actualização, recomenda-se ao utilizador que reinicie o seu sistema.

no reboot, o Usuário é apresentado com o programa MokManager (parte do carregador de shim instalado), como um conjunto de painéis de modo de texto que todo o Usuário para registrar o MOK gerado. O usuário seleciona “matricular MOK”, é mostrado uma impressão digital do certificado para se inscrever, e é solicitado a confirmar a inscrição. O usuário também é apresentado com uma prompt para re-ativar a validação de Boot seguro (no caso em que ele foi encontrado para ser desativado); e MokManager novamente requer confirmação do Usuário. Uma vez que todos os passos são confirmados, a validação shim é re-ativado, o novo MOK será inserido em firmware e o Usuário será convidado a reiniciar o sistema.

Quando o sistema reiniciar, os motoristas de terceiros assinados pelo MOK apenas matriculados serão carregados conforme necessário.

em todos os casos, uma vez que o sistema está rodando com o Boot seguro UEFI ativado e uma versão recente do shim; a instalação de qualquer novo módulo DKMS (driver de terceiros) irá prosseguir para assinar o módulo construído com o MOK. Isto irá acontecer sem interacção com o utilizador se existir uma chave Mok válida no sistema e parece já estar incluída.

Se não existir MOK ou o MOK existente não for incluído, uma nova chave será criada automaticamente imediatamente antes da assinatura e o utilizador será solicitado a matricular a chave, fornecendo uma senha que será necessária após a reinicialização.