Tendo instalado recentemente um driver que exigia que o módulo fosse assinado manualmente, ficou confuso o que a assinatura desse módulo estava realmente fazendo e por que deveria ser feita.
Há outras questões sobre o processo aqui, porém são mais técnicas. O que é uma explicação simples do que a assinatura de módulos faz e por que é necessário, bem como quais são as alternativas (aparentemente o dkms pode assinar módulos automaticamente)?
Responder1
O kernel pode ser configurado para apenas avisá-lo quando módulos não assinados ou assinados incorretamente são usados (por uma mensagem de log + definindo um sinalizador taint no kernel) ou para rejeitar completamente quaisquer módulos do kernel que não tenham uma assinatura no kernel pode validar.
Ao usar o processo de inicialização no estilo BIOS ou ao usar UEFI com inicialização segura desabilitada, este é essencialmente apenas um procedimento de segurança extra opcional. Isso tornará um pouco mais difícil para os intrusos adicionarem módulos de kernel malignos (como rootkits baseados em kernel, para ocultar as ferramentas e ações do intruso) ao sistema.
Mas ao usar UEFI com inicialização segura habilitada, isso faz parte dos requisitos de inicialização segura. O "espírito" do Secure Boot é proibir o carregamento de código não confiável no espaço do kernel. O firmware UEFI verifica a presença de uma assinatura válida (ou um hash SHA256 na lista de permissões) no bootloader; o bootloader é necessário para verificar o mesmo no kernel do sistema operacional; e o kernel deve estender esse requisito a todo o código que será executado no espaço do kernel.
É claro que, na prática, o kernel do sistema operacional pode facilmente optar por não atender a esse requisito. Mas as organizações que desenvolveram o Secure Boot decidiram que esta opção de exclusão deveria exigir pelo menos uma ação definitiva do administrador do sistema: o padrão deveria ser impor o requisito de assinatura.
(A propósito, isso também é parte do motivo pelo qual o Windows moderno exige que todos os drivers instalados sejam assinados por padrão. Se desejar instalar drivers não assinados, você precisará alterar explicitamente uma configuração que requer acesso de administrador.)
Uma ferramenta que seria inicializável em um sistema de inicialização segura e permitiria a execução de código de espaço do kernel não assinado "pronto para uso" seria chamada deDispositivo de evasão de inicialização segurae seria classificável como malware.
A Microsoft é o signatário do Secure Boot mais conhecido e assinará apenas versões do shimx64.efibootloader shim que imporão o requisito de assinatura.
Um firmware UEFI compatível com inicialização segura terá capacidade integrada de verificar assinaturas em binários que usam o formato binário Microsoft PE+, que é o que os *.efiarquivos usam. Mas o mundo Linux geralmente não usa esse formato binário: em vez disso, é usado o formato binário ELF.
Tanto os módulos do kernel Linux quanto os módulos do bootloader GNU GRUB são baseados no formato ELF. Isso requer que o bootloader e o kernel forneçam seus próprios algoritmos de verificação de assinatura para binários ELF, mas aparentemente o UEFI Forum (o consórcio da indústria que gerencia as especificações UEFI e Secure Boot) decidiu que não há problema em fazer isso, desde que o requisito padrão para assinaturas válidas é mantida.
É claro que isso não funciona como esperado se você usar o DKMS para construir e assinar automaticamente módulos do kernel: isso significa que haverá um certificado com sua chave privada presente que pode ser usado para produzir automaticamente uma assinatura válida, então um intruso também pode use-o para assinar quaisquer módulos malignos do kernel também. Não é menos seguro que um sistema sem inicialização segura, mas também não é muito mais seguro.
Se você tiver vários sistemas, poderá obter algum benefício de segurança ao ter a chave privada do certificado de assinatura do módulo apenas em um host (presumivelmente aquele que é menos ameaçado por invasores) e usá-la para construir quaisquer kernels e/ou módulos personalizados você pode precisar e distribuí-los a partir daí para quaisquer outros hosts que precisem deles. Dessa forma, os outros hosts precisariam apenas da parte pública do certificado de assinatura do módulo, que só pode ser usado para validar assinaturas existentes, e não para criar novas.