Você desabilita a inicialização segura ou assina o módulo do kernel.
Pessoalmente, desativo a inicialização segura na BIOS.
Veja link
Ou para assinar manualmente o módulo do kernel, consulte
link
============================== KERNEL MODULE SIGNING FACILITY ==============================ÍNDICE
- Visão geral.
- Configurando a assinatura de módulos.
- Gerando chaves de assinatura.
- Chaves públicas no kernel.
- Assinando módulos manualmente.
- Módulos assinados e remoção.
- Carregando módulos assinados.
- Assinaturas não válidas e módulos não assinados.
- Administrando / protegendo a chave privada.
======== VISÃO GERAL
O recurso de assinatura de módulo do kernel criptograficamente assina os módulos durante a instalação e, em seguida, verifica a assinatura ao carregar o módulo. Isso permite aumentar a segurança do kernel, impedindo a carregamento de módulos ou módulos não assinados assinados com uma chave inválida. A assinatura de módulo aumenta a segurança, dificultando o carregamento de módulo malicioso no kernel. A verificação de assinatura do módulo é feito pelo kernel, para que não seja necessário ter confiança bits do espaço do usuário.
Este recurso usa certificados padrão X.509 ITU-T para codificar o chaves públicas envolvidas. As assinaturas não são codificadas em qualquer tipo padrão industrial. A instalação atualmente suporta apenas o padrão de criptografia de chave pública RSA (embora seja plugável e permite que outros sejam usados). Os possíveis algoritmos de hash que podem ser são utilizados SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512 (o algoritmo é selecionado pelos dados na assinatura).
========================== CONFIGURAÇÃO DE MÓDULO DE SINAL
O recurso de assinatura de módulo está ativado indo para o "Ativar Loadable Module Support "seção da configuração do kernel e ligando
CONFIG_MODULE_SIG "Verificação de assinatura de módulo"
Isso tem várias opções disponíveis:
(1) "Requer que os módulos sejam assinados validamente" (CONFIG_MODULE_SIG_FORCE)
This specifies how the kernel should deal with a module that has a signature for which the key is not known or a module that is unsigned. If this is off (ie. "permissive"), then modules for which the key is not available and modules that are unsigned are permitted, but the kernel will be marked as being tainted, and the concerned modules will be marked as tainted, shown with the character 'E'. If this is on (ie. "restrictive"), only modules that have a valid signature that can be verified by a public key in the kernel's possession will be loaded. All other modules will generate an error. Irrespective of the setting here, if the module has a signature block that cannot be parsed, it will be rejected out of hand.(2) "Assina automaticamente todos os módulos" (CONFIG_MODULE_SIG_ALL)
If this is on then modules will be automatically signed during the modules_install phase of a build. If this is off, then the modules must be signed manually using:scripts / arquivo de sinais
(3) "Qual algoritmo hash deve ser assinado com os módulos?"
This presents a choice of which hash algorithm the installation phase will sign the modules with:CONFIG_MODULE_SIG_SHA1 "Assinar módulos com SHA-1" CONFIG_MODULE_SIG_SHA224 "Assinar módulos com SHA-224" CONFIG_MODULE_SIG_SHA256 "Assinar módulos com SHA-256" CONFIG_MODULE_SIG_SHA384 "Assinar módulos com SHA-384" CONFIG_MODULE_SIG_SHA512 "Assinar módulos com SHA-512"
The algorithm selected here will also be built into the kernel (rather than being a module) so that modules signed with that algorithm can have their signatures checked without causing a dependency loop.(4) "Nome do arquivo ou PKCS # 11 URI da chave de assinatura do módulo" (CONFIG_MODULE_SIG_KEY)
Setting this option to something other than its default of "certs/signing_key.pem" will disable the autogeneration of signing keys and allow the kernel modules to be signed with a key of your choosing. The string provided should identify a file containing both a private key and its corresponding X.509 certificate in PEM form, or — on systems where the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by RFC7512. In the latter case, the PKCS#11 URI should reference both a certificate and a private key. If the PEM file containing the private key is encrypted, or if the PKCS#11 token requries a PIN, this can be provided at build time by means of the KBUILD_SIGN_PIN variable.(5) "Teclas X.509 adicionais para chaveiro do sistema padrão" (CONFIG_SYSTEM_TRUSTED_KEYS)
This option can be set to the filename of a PEM-encoded file containing additional certificates which will be included in the system keyring by default.Observe que a ativação da assinatura do módulo adiciona uma dependência ao OpenSSL Desenvolver pacotes para os processos de construção do kernel para a ferramenta que a assinatura.
======================= GERANDO CHAVES DE ASSINATURA
Os keypodes criptográficos são necessários para gerar e verificar assinaturas. Uma chave privada é usada para gerar uma assinatura e os correspondentes chave pública é usada para verificar isso. A chave privada é necessária apenas durante a compilação, após o que pode ser excluída ou armazenada com segurança. o chave pública é construída no kernel para que possa ser usada para verificar as assinaturas conforme os módulos são carregados.
Em condições normais, quando CONFIG_MODULE_SIG_KEY não é alterado de seu padrão, a compilação do kernel gerará automaticamente um novo keypair usando openssl se não existir no arquivo:
certs / signing_key.pem
durante a construção do vmlinux (a parte pública da chave precisa ser construído em vmlinux) usando parâmetros no:
certs / x509.genkey
Arquivo(que também é gerado se ainda não existir).
É altamente recomendável que você forneça seu próprio arquivo x509.genkey.
Mais notavelmente, no arquivo x509.genkey, o req_distinguished_name seção deve ser alterada a partir do padrão:
[req_distinguished_name] #O = Empresa não especificada CN = Tempo de compilação chave do kernel autogerada #emailAddress = [email protected]
O tamanho da chave RSA gerada também pode ser definido com:
[req] default_bits = 4096
Também é possível gerar manualmente os principais arquivos privados / públicos usando o arquivo de configuração de geração de chaves x509.genkey na raiz nó da árvore de fontes do kernel Linux e o comando openssl. o A seguir, um exemplo para gerar os arquivos de chave pública / privada:
openssl req -new -nodes -utf8 -sha256 -dias 36500 -batch-x509 \ -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem
O caminho completo para o arquivo kernel_key.pem resultante pode então ser especificado na opção CONFIG_MODULE_SIG_KEY, e o certificado e a chave será usada em vez de um par de chaves gerado automaticamente.
========================= CHAVES PÚBLICAS NO KERNEL
O kernel contém um anel de chaves públicas que podem ser visualizadas pelo root. Eles estão em um chaveiro chamado ".system_keyring" que pode ser visto por:
[root @ deneb ~] # cat / proc / keys ... 223c7853 Eu ------ 1 perm 1f030000 0 0 chaveiro .system_keyring: 1 302d2d52 I ------
1 perm 1f010000 0 0 assimetria Chave de assinatura do kernel do Fedora: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...Além da chave pública gerada especificamente para assinatura de módulo, certificados confiáveis adicionais podem ser fornecidos em um arquivo codificado por PEM referenciada pela opção de configuração CONFIG_SYSTEM_TRUSTED_KEYS.
Além disso, o código de arquitetura pode levar chaves públicas de um hardware armazene e adicione-os também (por exemplo, no banco de dados de chaves UEFI).
Por fim, é possível adicionar outras chaves públicas fazendo isso:
keyctl padd assimétrico "" [.system_keyring-ID] & lt; [arquivo-chave]
por exemplo:
keyctl padd assimétrico "" 0x223c7853
Note, no entanto, que o kernel permitirá apenas que chaves sejam adicionadas .system_keyring se o wrapper X.509 da nova chave for validamente assinado por uma chave que já é residente no .system_keyring no momento em que o chave foi adicionada.
========================= MÓDULOS DE ASSINATURA MANUALMENTE
Para assinar manualmente um módulo, use a ferramenta scripts / arquivo de sinais disponível em a árvore de origem do kernel do Linux. O script requer 4 argumentos:
- O algoritmo hash (por exemplo, sha256)
- O nome de arquivo da chave privada ou PKCS # 11 URI
- O nome da chave pública
- O módulo do kernel a ser assinado
O seguinte é um exemplo para assinar um módulo do kernel:
scripts / arquivo de sinais sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko
O algoritmo de hash usado não precisa corresponder ao configurado, mas se isso não acontecer, você deve se certificar de que o algoritmo de hash é ou embutido no kernel ou pode ser carregado sem precisar de si mesmo.
Se a chave privada exigir uma senha ou PIN, ela poderá ser fornecida em a variável de ambiente $ KBUILD_SIGN_PIN.
============================ MÓDULOS ASSINADOS E DESPEDIDA
Um módulo assinado tem uma assinatura digital simplesmente anexada no final. A string "~ Assinatura do módulo anexada ~." no final do módulo arquivo confirma que uma assinatura está presente, mas não confirma que a assinatura é válida!
Os módulos assinados são BRITTLE, pois a assinatura está fora da definição Recipiente ELF. Assim, eles não podem ser retirados uma vez que a assinatura é computado e anexado. Observe que o módulo inteiro é a carga assinada, incluindo toda e qualquer informação de depuração presente no momento da assinatura.
====================== CARREGANDO MÓDULOS ASSINADOS
Os módulos são carregados com insmod, modprobe, init_module () ou finit_module (), exatamente como para módulos não assinados, pois nenhum processamento é feito no espaço do usuário. A verificação da assinatura é feita dentro do kernel.
========================================= ASSINATURAS NÃO VÁLIDAS E NÃO UTILIZADAS MÓDULOS
Se CONFIG_MODULE_SIG_FORCE estiver ativado ou module.sig_enforce = 1 for fornecido na linha de comando do kernel, o kernel só carregará validamente módulos assinados para os quais possui uma chave pública. Caso contrário, será também carrega módulos não assinados. Qualquer módulo para o qual o kernel tem uma chave, mas que prova ter uma incompatibilidade de assinatura não será permitido carregar.
Qualquer módulo que tenha uma assinatura incomparável será rejeitado.
========================================= ADMINISTRAÇÃO / PROTEÇÃO DA CHAVE PRIVADA
Como a chave privada é usada para assinar módulos, vírus e malware poderia usar a chave privada para assinar módulos e comprometer o funcionamento sistema. A chave privada deve ser destruída ou movida para uma localização e não mantidos no nó raiz da árvore de origem do kernel.