Por que desabilitar o “Secure Boot” é uma política aplicada ao instalar módulos de terceiros

Question

Ao instalar 16.04 , me pediram para desligar o Secure Boot "se eu quisesse instalar módulos / drivers de terceiros .

Eu não cumpri.

E quando eu instalei manualmente os únicos drivers de terceiros que eu uso ( bcmwl-kernel-source ), fui perguntado novamente (durante a instalação do pacote) para desligar o "Secure Boot".

Usar bcmwl-kernel-source funcionou perfeitamente com o Secure Boot em 15.10 . Isso não parece estar relacionado a um bug para mim.

Então, parece que o Ubuntu se recusa a assinar mais os drivers / módulos de terceiros para que funcionem (??) com o "Secure Boot". Ou parece considerar módulos de terceiros como inseguros e quebrando "Secure Boot", portanto, inforcing para desativá-lo para deixar claro? Estou certo?

    

Answer 1

Isso não é um bug, é um recurso.

Como diz Anthony Wong, quando você instala um pacote DKMS, você mesmo está compilando o pacote, portanto, a Canonical não pode assinar o módulo para você.

No entanto, você pode definitivamente usar o Secure Boot, no entanto, este é exatamente o caso de uso em que o Secure Boot está tentando protegê-lo de si mesmo, porque não pode saber se você confia ou não em um módulo.

Por padrão , há uma chave de plataforma (PK) em sua máquina UEFI, que é a autoridade de certificação confiável para carregar o código em seu processador.

O GRUB, ou shim, ou outros mecanismos de inicialização podem ser assinados digitalmente por uma KEK confiável pela CA raiz (PK) e, assim, seu computador pode, sem qualquer configuração, software de inicialização Ubuntu Live USB / DVDs.

No Ubuntu 16.04, o kernel é construído com CONFIG_MODULE_SIG_FORCE = 1, o que significa que o kernel aplicará os módulos a serem assinados por uma chave confiável na plataforma. Considere que a plataforma UEFI, por padrão, contém uma PK sobre a qual você não tem controle e, portanto, não pode assinar binários com uma chave reconhecida pela sua própria máquina.

Algumas pessoas criticam e reclamam disso, mas não há realmente uma maneira melhor (do ponto de vista de segurança) do que ser você mesmo que registra a nova chave que deseja.

Se o seu sistema de inicialização usa shim, você pode usar algo chamado banco de dados de Chaves do Proprietário da Máquina, e inscrever sua chave como um MOK (Você pode fazer isso com o mokutil). Se você não o fizer, também poderá inscrever sua chave no banco de dados UEFI como uma chave de assinatura.

Depois de inscrever sua chave, você pode assinar seu pacote do DKMS com o seu MOK (deve haver um script em perl em /usr/src/kernels/$(uname -r)/scripts/sign-file ) e após ele ser assinado, pode carregá-lo no kernel .

Com certeza, alguém deve dar mais instruções visuais sobre isso, e provavelmente até criar um assistente ou um padrão DKMS melhor para permitir que as chaves sejam levadas em consideração, mas é isso que temos a partir de agora.

    

Answer 2

Em suma, isso não é um bug, mas uma nova mudança introduzida em 16.04.

Porque o que você está instalando é um pacote dkms. Os módulos DKMS são compilados em sua própria máquina e, portanto, a Canonical não pode assinar o módulo para você. Se a Canonical não puder assiná-la, não há como confirmá-la digitalmente. Se você tiver a inicialização segura ativada, isso significará que seu módulo não pode ser usado e, para usá-lo, você terá que desativar a inicialização segura, e é por isso que está sendo questionado pela pergunta.

Por que isso acontece apenas em 16.04, mas não em versões anteriores, Rod Smith deu uma boa resposta. No Ubuntu 16.04, o Ubuntu começa a impor a inicialização segura ao nível do kernel. Antes de 16.04, o Ubuntu não obriga você a usar o kernel com sinal e os módulos assinados do kernel, mesmo que você tenha a inicialização segura ativada. Mas isso não é mais o caso em 16.04.

Este é o bug relacionado: link

Este é o modelo relacionado: link

    

Answer 3

Outra maneira de fazer isso é criar sua própria chave, inserir a parte pública no banco de dados MOK e assinar os módulos que você compila com a parte privada. Procure aqui informações detalhadas: Não foi possível carregar 'vboxdrv' após a atualização para o Ubuntu 16.04 (e eu quero manter a inicialização segura)

    

Answer 4

A resposta aceita é muito completa, mas gostaria de adicionar esta simples informação, tirada daqui:

link

Inicialização basicamente segura pode impedir que você carregue algum driver instalado, o que pode ser bastante frustrante. Eu já passei por isso: o driver instalado corretamente, tudo parecia ser bom para ir, mas simplesmente não funcionou. Demorei um pouco para descobrir que o boot seguro está impedindo o sistema operacional de carregá-lo.