Ubuntu Wiki

O que é UEFI Secure Boot?

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

Proper, secure use of UEFI Secure Boot requer que cada binário carregado no boot seja validado contra chaves conhecidas, localizadas no firmware, que denotam fornecedores e fontes confiáveis para os binários, ou binários específicos confiáveis que podem ser identificados através de hashing criptográfico.

A maior parte do hardware x86 vem da fábrica pré-carregado com chaves Microsoft. Isto significa que geralmente podemos confiar no firmware destes sistemas para confiar nos binários que são assinados pela Microsoft, e a comunidade Linux depende muito desta suposição para que o Secure Boot funcione. Este é o mesmo processo usado pela Red Hat e SUSE, por exemplo.

Muitas arquiteturas ARM e outras arquiteturas também suportam o UEFI Secure Boot, mas podem não estar pré-carregando chaves no firmware. Nestas arquiteturas, pode ser necessário reiniciar as imagens de inicialização com um certificado que é carregado no firmware pelo dono do hardware.

Plano de implementação inicial: Plano de Implementaçã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 do Ubuntu como shim-signed ou grub-efi-amd64-signed.

• arm64: A partir de 20.04 (‘focal’), um binário shim assinado pela Microsoft e um binário grub assinado pela Canonical são fornecidos no arquivo principal do 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 aqui: UEFI/SecureBoot/Testing.

Como funciona o arranque seguro UEFI no Ubuntu

No Ubuntu, todos os binários pré-construídos destinados a serem carregados como parte do processo de arranque, com a excepção da imagem initrd, são assinados pelo certificado UEFI da Canonical, que por sua vez é implicitamente confiável ao ser embutido no carregador de calços, ele próprio assinado pela Microsoft.

Em arquiteturas ou sistemas onde os certificados de assinatura pré-carregados da Microsoft não estão disponíveis ou carregados no firmware, os usuários podem substituir as assinaturas existentes no shim ou grub e carregá-las como desejarem, verificando em relação aos seus próprios certificados importados no firmware do sistema.

Como o sistema inicia, o firmware carrega o binário shim como especificado nas variáveis do firmware BootEntry. O Ubuntu instala seu próprio BootEntry no momento da instalação e pode atualizá-lo a qualquer momento que o gerenciador de boot do GRUB for atualizado. Como o binário shim é assinado pela Microsoft; ele é validado e aceito pelo firmware ao verificar contra certificados já presentes no firmware. Como o binário shim incorpora um certificado Canonical, bem como a sua própria base de dados de confiança, outros elementos do ambiente de arranque podem, para além de serem assinados por um dos certificados aceitáveis pré-carregados no firmware, ser assinados pela chave UEFI da Canonical.

A próxima coisa carregada pelo shim é a imagem da segunda fase. Isto pode ser uma de duas coisas: ou GRUB, se o sistema estiver inicializando normalmente; ou MokManager, se o gerenciamento de chaves for necessário, conforme configurado pelas variáveis do firmware (normalmente alterado quando o sistema estava rodando anteriormente).

Se estiver inicializando normalmente; o binário GRUB (grub*.efi) é carregado e sua validação é tentada contra todas as fontes confiáveis previamente conhecidas. O binário GRUB para Ubuntu é assinado pela chave UEFI da Canonical, então ele é validado com sucesso e o processo de inicialização continua.

Se inicializar para prosseguir com tarefas de gerenciamento de chaves, o binário MokManager (mm*.efi) é carregado. Este binário é explicitamente confiável pelo shim ao ser assinado por uma chave efêmera que só existe enquanto o binário shim está sendo construído. Isto significa que somente o binário MokManager construído com um determinado shim binário será permitido rodar e limita a possibilidade de comprometimento do uso de ferramentas comprometidas. O MokManager permite que qualquer usuário presente no console do sistema cadastre chaves, remova chaves confiáveis, cadastre hashes binários e mude a validação do Secure Boot no nível shim, mas a maioria das tarefas requer que uma senha previamente definida seja inserida para confirmar que o usuário no console é de fato a pessoa que solicitou as alterações. Tais senhas só sobrevivem em uma única execução de shim / MokManager; e são apagadas assim que o processo é completado ou cancelado. Uma vez que o gerenciamento de chaves esteja completo, o sistema é reinicializado e não simplesmente continua com o boot, já que as mudanças no gerenciamento de chaves podem ser necessárias para completar o boot com sucesso.

Após o sistema continuar a arrancar para o GRUB; o processo GRUB carrega qualquer configuração necessária (normalmente carregando a configuração do ESP (EFI System Partition), apontando para outro ficheiro de configuração na raiz ou partição de arranque), que o apontará para a imagem do kernel a carregar.

EFI aplicações até este ponto tendo acesso completo ao firmware do sistema, incluindo acesso a variáveis de firmware de confiança, o kernel a carregar também deve ser validado contra o banco de dados de confiança. Kernels Ubuntu oficiais sendo assinados pela chave UEFI da Canonical, eles são validados com sucesso, e o controle é passado para o kernel. As imagens Initrd não são validadas.

No caso de kernels não-oficiais, ou kernels construídos por usuários, passos adicionais precisam ser tomados se os usuários desejarem carregar tais kernels enquanto mantém as capacidades completas do UEFI Secure Boot. Todos os kernels devem ser assinados para poder ser carregados pelo GRUB quando o UEFI Secure Boot estiver habilitado, portanto o usuário deverá proceder com sua própria assinatura. Alternativamente, os usuários podem desejar desativar a validação em shim enquanto inicializam com o Secure Boot habilitado em um kernel oficial usando ‘sudo mokutil –disable-validation’, fornecendo uma senha quando solicitado, e reiniciando; ou para desativar o Secure Boot no firmware por completo.

Até agora, qualquer falha na validação de uma imagem para carregar é encontrada com um erro crítico que pára o processo de boot. O sistema não continuará a arrancar, e pode reiniciar automaticamente após um período de tempo dado que outras variáveis BootEntry podem conter caminhos de arranque que são válidos e confiáveis.

Once loaded, kernels validados irão desabilitar os Serviços de Inicialização do firmware, deixando assim de ter privilégios e mudando efetivamente para o modo usuário; onde o acesso a variáveis confiáveis é limitado a somente leitura. Dadas as amplas permissões permitidas aos módulos do kernel, qualquer módulo não incorporado no kernel também precisará ser validado no momento do carregamento. Os módulos construídos e enviados pela Canonical com os kernels oficiais são assinados pela chave UEFI da Canonical e como tal, são confiáveis. Módulos construídos sob medida exigirão que o usuário tome as medidas necessárias para assinar os módulos antes que eles sejam carregados pelo kernel. Isto pode ser conseguido usando o comando ‘kmodsign’ .

Módulos não assinados são simplesmente recusados pelo kernel. Qualquer tentativa de inseri-los com insmod ou modprobe irá falhar com uma mensagem de erro.

Dado que muitos usuários precisam de módulos de terceiros para que seus sistemas funcionem corretamente ou para que alguns dispositivos funcionem; e que esses módulos de terceiros precisam ser compilados localmente no sistema para serem ajustados ao kernel em execução, o Ubuntu fornece ferramentas para automatizar e simplificar o processo de assinatura.

Como posso fazer assinatura não automática de drivers?

Alguns projetos podem requerer o uso de drivers personalizados do kernel que não são configurados de forma a funcionar com o 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 construído com DKMS já tiver acionado a geração de um).

Utilize o seguinte comando para registrar uma chave existente no shim:

sudo update-secureboot-policy --enroll-key

Se não existir nenhum MOK, o script sairá com uma mensagem para esse efeito. Se a chave já estiver registrada, o script sairá, sem fazer nada. Se a chave existir mas não se mostrar registrada, o usuário será solicitado a usar uma senha após a reinicialização, para que a chave possa ser registrada.

Um pode gerar um novo MOK usando o seguinte comando:

sudo update-secureboot-policy --new-key

E depois inscreva 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.

Aplicações de segurança no gerenciamento de chaves do proprietário da máquina

O MOK gerado no momento da instalação ou na atualização é específico para a máquina, e somente permitido pelo kernel ou shim para assinar módulos do kernel, pelo uso de um OID específico de KeyUsage (1.3.6.1.4.1.2312.16.1.2) denotando as limitações do MOK.

Versões recentes do shim incluem lógica para seguir as limitações das chaves somente de assinatura de módulo. Estas chaves poderão ser inscritas no firmware na base de dados trust do shim, mas serão ignoradas quando o shim ou o GRUB validarem imagens para carregar no firmware. A função verify() do shim só validará com sucesso imagens assinadas por chaves que não incluem o “Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Os kernels Ubuntu utilizam a base de dados global trust (que inclui tanto os shim’s como os firmware) e aceitarão 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 usuários com acesso de super usuário ao sistema e acesso ao console do sistema para inserir a senha necessária ao inscrever chaves já têm acesso de alto nível ao sistema; a chave MOK gerada é mantida no sistema de arquivos como arquivos regulares de propriedade do root com permissões somente de leitura. Isto é considerado suficiente para limitar o acesso ao MOK para assinatura por usuários maliciosos ou scripts, especialmente dado que não existe nenhum MOK no sistema, a menos que ele requeira drivers de terceiros. Isto limita a possibilidade de comprometimento do uso indevido de uma chave MOK gerada para assinar um módulo do kernel malicioso. Isto é equivalente ao comprometimento das aplicações no espaço do usuário, que já seria possível com o acesso do superusuário ao sistema, e assegurar isto está fora do escopo do UEFI Secure Boot.

Sistemas anteriores podem ter tido a validação do Secure Boot desactivada em shim. Como parte do processo de actualização, estes sistemas serão migrados para a reactivação da validação Secure Boot em calço e a inscrição de uma nova chave MOK quando aplicável.

Processo de geração e assinatura de MOK

O processo de geração e assinatura da chave é ligeiramente diferente baseado se estamos a lidar com uma nova instalação ou uma actualização do sistema anteriormente a correr Ubuntu; estes dois casos estão claramente marcados abaixo.

Em todos os casos, se o sistema não estiver inicializando em modo UEFI, nenhum passo especial de assinatura de módulo do kernel ou geração de chave acontecerá.

Se o Arranque Seguro estiver desactivado, a geração e inscrição no MOK ainda acontece, pois o utilizador poderá mais tarde activar o Arranque Seguro. Se esse for o caso, o sistema deve funcionar corretamente.

O usuário instala o Ubuntu em um novo sistema

O usuário passa através do instalador. No início, quando se prepara para instalar e apenas se o sistema requerer módulos de terceiros para funcionar, o utilizador é solicitado a obter uma palavra-passe do sistema que está claramente marcada como sendo necessária após a instalação estar completa, e enquanto o sistema está a ser instalado, é automaticamente gerado um novo MOK sem interacção adicional do utilizador.

Os drivers de terceiros ou módulos do kernel requeridos pelo sistema serão compilados automaticamente quando o pacote for instalado, e o processo de compilação inclui um passo de assinatura. O passo de assinatura utiliza automaticamente o MOK gerado anteriormente para assinar o módulo, de modo que ele possa ser imediatamente carregado assim que o sistema for reinicializado e o MOK for incluído no banco de dados de confiança do sistema.

Após a instalação estar completa e o sistema ser reiniciado, na primeira inicialização o usuário é apresentado com o programa MokManager (parte do shim loader instalado), como um conjunto de painéis de modo texto que todos os usuários cadastram no MOK gerado. O usuário seleciona “Enroll MOK”, é mostrada uma impressão digital do certificado a ser cadastrado e é solicitado a confirmar o cadastro. Uma vez confirmado, o novo MOK será inserido no firmware e o usuário será solicitado a reiniciar o sistema.

Quando o sistema reinicia, os drivers de terceiros assinados pelo MOK recém-inscritos serão carregados conforme necessário.

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

Na atualização, os pacotes shim e shim-signed são atualizados. As tarefas de pós-instalação do pacote shim-signed continuam para 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 completado e o sistema reinicializado.

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

Após a atualização, é recomendado que o usuário reinicialize seu sistema.

No reinício, o usuário é apresentado com o programa MokManager (parte do shim loader instalado), como um conjunto de painéis de modo texto que todo o usuário deve registrar o MOK gerado. O usuário seleciona “Enroll MOK”, é mostrada uma impressão digital do certificado a ser cadastrado e é solicitado a confirmar o cadastro. O usuário também é apresentado com um prompt para reativar a validação do Secure Boot (no caso de ter sido desabilitado); e o MokManager novamente requer confirmação do usuário. Uma vez todos os passos confirmados, a validação do shim é reativada, o novo MOK será inserido no firmware e o usuário será solicitado a reiniciar o sistema.

Quando o sistema reinicia, os drivers de terceiros assinados pelo MOK recém-inscritos serão carregados conforme necessário.

Em todos os casos, uma vez que o sistema esteja rodando com o UEFI Secure Boot habilitado e uma versão recente do shim; a instalação de qualquer novo módulo DKMS (driver de terceiros) irá proceder para assinar o módulo construído com o MOK. Isto acontecerá sem interação do usuário se uma chave MOK válida existir no sistema e parecer já estar cadastrada.

Se não existir MOK ou se o MOK existente não estiver inscrito, uma nova chave será automaticamente criada imediatamente antes de assinar e o usuário será solicitado a inscrever a chave, fornecendo uma senha que será necessária no momento da reinicialização.