Por que desativar a “Inicialização segura” é aplicada à política ao instalar módulos de terceiros

Ao instalar o 16.04 , me pediram para desativar a " Inicialização segura " se eu quisesse instalar módulos / drivers de terceiros .

Eu não cumpri.

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

O uso do bcmwl-kernel-source funcionou perfeitamente com o Secure Boot na versão 15.10 . Isso não parece estar relacionado a um bug para mim.

Portanto, isso parece que o Ubuntu se recusa a assinar mais os drivers / módulos de terceiros para fazê-lo funcionar (??) com o "Secure Boot". Ou parece considerar os módulos de terceiros como inseguros e que quebram a "Inicialização segura", portanto, forçando a desativá-lo para deixar claro? Estou certo ?

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

Como Anthony Wong diz, 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, esse é exatamente o caso de uso em que o Secure Boot está tentando protegê-lo de si mesmo, porque ele não pode saber se confia em um módulo ou não.

Por padrão , existe uma Platform Key (PK) na sua máquina UEFI, que é a Autoridade de Certificação confiável para carregar o código no seu processador.

O GRUB, o shim ou outros mecanismos de inicialização podem ser assinados digitalmente por uma KEK confiável pela CA (PK) raiz e, portanto, o seu computador pode, sem nenhuma configuração, inicializar software como 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á módulos a serem assinados por uma chave confiável na plataforma. Leve em consideração 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 por sua própria máquina.

Algumas pessoas criticam isso, mas não há realmente nenhuma maneira melhor (do ponto de vista de segurança) do que ser você mesmo quem registra a nova chave desejada.

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 registrar sua chave como um MOK (você pode fazer isso com o mokutil). Caso contrário, você também pode registrar sua chave no banco de dados UEFI como uma chave de assinatura.

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

Concedido, alguém deve dar instruções mais 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 agora.

Você pode consultar esta explicação sobre como assinar seus próprios módulos do kernel: https://askubuntu.com/a/768310/12049

Em resumo, isso não é um bug, mas uma nova alteração introduzida na 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 conseguir assinar, não há como verificar digitalmente. Se você tiver a inicialização segura ativada, isso significa que seu módulo não pode ser usado e, para usá-lo, será necessário desativar a inicialização segura, é por isso que você está sendo solicitado 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 forçar a inicialização segura no nível do kernel. Antes do 16.04, o Ubuntu realmente não o impõe a usar o kernel assinado e os módulos do kernel assinado, mesmo que você tenha a inicialização segura ativada. Mas esse não é mais o caso em 16.04.

Este é o bug relacionado: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532

Este é o projeto relacionado: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-installing-unsigned-secureboot

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 o 'vboxdrv' após a atualização para o Ubuntu 16.04 (e eu quero manter a inicialização segura)

A resposta aceita é muito completa, mas eu gostaria de adicionar esta informação simples, extraída daqui:

https://askubuntu.com/a/843678/664391

A 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 bom, mas simplesmente não funcionou. Levei algum tempo para descobrir que era uma inicialização segura impedindo que o sistema operacional o carregasse.