a verificação do módulo falhou na assinatura e / ou faltou a chave requerida

9

Estou trabalhando em um módulo do kernel, que está funcionando bem. No entanto, olhando através do dmesg, vejo uma mensagem em relação ao meu módulo em que a verificação do módulo falhou (a verificação do módulo falhou na assinatura e / ou a chave requerida está faltando).

Como posso resolver este problema? Como faço para que meu módulo seja assinado para verificação?

Obrigado.

    
por user2000888 14.06.2014 / 18:58

2 respostas

1

Tudo o que você precisa está descrito aqui

FACILIDADE DE ASSINATURA DO MÓDULO KERNEL

CONTEÚDO

  • 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 módulos durante instalação e, em seguida, verifica a assinatura ao carregar o módulo. este permite maior segurança do kernel, impedindo o carregamento de módulos não assinados ou módulos assinados com uma chave inválida. A assinatura do módulo aumenta a segurança dificultando o carregamento de um módulo malicioso no kernel. O módulo verificação de assinatura é feita pelo kernel para que não seja necessário ter bits do espaço de usuário confiável.

Este recurso usa certificados padrão X.509 ITU-T para codificar as chaves públicas envolvido. As assinaturas não são codificadas em nenhum padrão industrial tipo. O recurso atualmente suporta apenas a criptografia de chave pública RSA padrão (embora seja plugável e permita que outros sejam usados). O possível Os algoritmos hash que podem ser usados são SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512 (o algoritmo é selecionado pelos dados na assinatura).

CONFIGURANDO O MÓDULO DE SINAL

O recurso de assinatura de módulo é ativado indo para o "Ativar módulo carregável Suporte "seção da configuração do kernel e ligando

CONFIG_MODULE_SIG   "Module signature verification"

Isso tem várias opções disponíveis:

  1. "Requer que os módulos sejam assinados com validade" (CONFIG_MODULE_SIG_FORCE)

    Isto especifica como o kernel deve lidar com um módulo que possui uma assinatura para a qual a chave não é conhecida ou um módulo não assinado.

    Se estiver desativado (ou seja, "permissivo"), os módulos para os quais a chave não está disponível e os módulos não assinados são permitidos, mas o kernel será marcado como corrompido e os módulos em questão serão marcados como contaminado, mostrado com o caractere 'E'.

    Se isto estiver ativado (isto é, "restritivo"), apenas os módulos que possuem uma assinatura válida que pode ser verificada por uma chave pública na posse do kernel serão carregados. Todos os outros módulos geram um erro.

    Independentemente da configuração aqui, se o módulo tiver um bloco de assinatura que não possa ser analisado, ele será rejeitado imediatamente.

  2. "Assinar automaticamente todos os módulos" (CONFIG_MODULE_SIG_ALL)

    Se isso estiver ativado, os módulos serão assinados automaticamente durante a fase modules_install de uma compilação. Se isso estiver desativado, os módulos deverão ser assinados manualmente usando:

    scripts/sign-file
    
  3. "Qual algoritmo hash deve ser assinado com os módulos?"

    Isto apresenta uma escolha de qual algoritmo de hash a fase de instalação irá assinar os módulos com:

    CONFIG_MODULE_SIG_SHA1      "Sign modules with SHA-1"
    CONFIG_MODULE_SIG_SHA224    "Sign modules with SHA-224"
    CONFIG_MODULE_SIG_SHA256    "Sign modules with SHA-256"
    CONFIG_MODULE_SIG_SHA384    "Sign modules with SHA-384"
    CONFIG_MODULE_SIG_SHA512    "Sign modules with SHA-512"
    

    O algoritmo selecionado aqui também será construído no kernel (em vez de ser um módulo) para que os módulos assinados com esse algoritmo possam ter suas assinaturas verificadas sem causar um loop de dependência.

  4. "Nome do arquivo ou PKCS # 11 URI da chave de assinatura de módulo" (CONFIG_MODULE_SIG_KEY)

    Configurar esta opção para algo diferente de seu padrão "certs / signing_key.pem" desativará a autogeração das chaves de assinatura e permitirá que os módulos do kernel sejam assinados com uma chave de sua escolha. A sequência fornecida deve identificar um arquivo contendo uma chave privada e seu certificado X.509 correspondente no formulário PEM ou - em sistemas nos quais o OpenSSL ENGINE_pkcs11 está funcional - um URI PKCS # 11 conforme definido pela RFC7512. Neste último caso, o PKCS # 11 URI deve referenciar um certificado e uma chave privada.

    Se o arquivo PEM contendo a chave privada estiver criptografado, ou se o token PKCS # 11 exigir um PIN, isso poderá ser fornecido no momento da criação por meio da variável KBUILD_SIGN_PIN.

  5. "Chaves X.509 adicionais para chaveiro do sistema padrão" (CONFIG_SYSTEM_TRUSTED_KEYS)

    Esta opção pode ser configurada para o nome do arquivo de um arquivo codificado por PEM contendo certificados adicionais que serão incluídos no chaveiro do sistema por padrão.

Observe que a ativação da assinatura do módulo adiciona uma dependência nos pacotes OpenSSL devel aos processos de criação do kernel para a ferramenta que faz a assinatura.

GERANDO CHAVES DE ASSINATURA

Os keypodes criptográficos são necessários para gerar e verificar assinaturas. UMA A chave privada é usada para gerar uma assinatura e a chave pública correspondente é usada para verificá-la. A chave privada é necessária apenas durante a compilação, após o que pode ser excluída ou armazenada com segurança. A chave pública é embutida no kernel para que possa ser usada para verificar as assinaturas, pois os módulos são carregado.

Em condições normais, quando o CONFIG_MODULE_SIG_KEY não é alterado do seu padrão, a compilação do kernel gerará automaticamente um novo par de chaves usando openssl se não existir um no arquivo:

certs/signing_key.pem

durante a construção do vmlinux (a parte pública da chave precisa ser construída no 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, a seção req_distinguished_name deve ser alterado do padrão:

[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#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 no nó raiz do Linux árvore de fontes do kernel e o comando openssl. O seguinte é um exemplo para gerar os arquivos de chave pública / privada:

openssl req -new -nodes -utf8 -sha256 -days 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 ser especificado na opção CONFIG_MODULE_SIG_KEY, e o certificado e a chave nele serão ser usado 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 I------     1 perm 1f030000     0     0 keyring   .system_keyring: 1
302d2d52 I------     1 perm 1f010000     0     0 asymmetri Fedora kernel signing key: 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 referenciado pela opção de configuração CONFIG_SYSTEM_TRUSTED_KEYS.

Além disso, o código da arquitetura pode pegar chaves públicas de um armazenamento de hardware e adicioná-las também (por exemplo, no banco de dados de chaves UEFI).

Por fim, é possível adicionar outras chaves públicas fazendo isso:

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

por exemplo:

keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509

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 a 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:

1.  The hash algorithm (e.g., sha256)
2.  The private key filename or PKCS#11 URI
3.  The public key filename
4.  The kernel module to be signed

O seguinte é um exemplo para assinar um módulo do kernel:

scripts/sign-file sha512 kernel-signkey.priv \
    kernel-signkey.x509 module.ko

O algoritmo de hash usado não precisa corresponder ao configurado, mas se não, você deve se certificar de que o algoritmo de hash seja incorporado ao kernel ou pode ser carregado sem precisar de si próprio.

Se a chave privada exigir uma senha ou PIN, ela poderá ser fornecida no Variável de ambiente $ KBUILD_SIGN_PIN.

MÓDULOS ASSINADOS E DESPEJOS

Um módulo assinado tem uma assinatura digital simplesmente anexada no final. A corda "~ Assinatura do módulo anexada ~." no final do arquivo do módulo confirma que um assinatura está presente, mas não confirma que a assinatura é válida!

Os módulos assinados são BRITTLE, pois a assinatura está fora do ELF definido recipiente. Assim, eles NÃO PODEM ser retirados assim que a assinatura for computada e em anexo. Observe que o módulo inteiro é a carga assinada, incluindo todo e qualquer informações de depuração presentes no momento da assinatura.

CARREGANDO MÓDULOS ASSINADOS

Os módulos são carregados com insmod, modprobe, init_module () ou finit_module (), exatamente como nos módulos não assinados, pois nenhum processamento é feito no espaço do usuário. o verificação de assinatura é feita dentro do kernel.

ASSINATURAS NÃO-VÁLIDAS E MÓDULOS NÃO ASSINADOS

Se CONFIG_MODULE_SIG_FORCE estiver habilitado ou enforcemodulesig = 1 for fornecido em a linha de comando do kernel, o kernel carregará somente módulos assinados validamente para o qual tem uma chave pública. Caso contrário, também carregará módulos que são sem assinatura. Qualquer módulo para o qual o kernel tenha uma chave, mas que prove ter uma incompatibilidade de assinatura não será permitida para carregar.

Qualquer módulo que tenha uma assinatura incomparável será rejeitado.

ADMINISTRAR / PROTEGER A CHAVE PRIVADA

Como a chave privada é usada para assinar módulos, vírus e malwares podem usar a chave privada para assinar módulos e comprometer o sistema operacional. o chave privada deve ser destruída ou movida para um local seguro e não mantida no nó raiz da árvore de origem do kernel.

    
por A.B. 23.10.2015 / 14:56
0

Edite ./include/generated/autoconf.h e altere a linha

define CONFIG_MODULE_SIG 1

para

define CONFIG_MODULE_SIG 0
    
por daniel 14.03.2017 / 14:22