Na verdade, o Debian tem suporte para inicialização segura (você pode usar utilitários para assinar os kernels você mesmo - a única parte complicada é instalar as chaves de assinatura automática, que depende da implementação do UEFI).
Estou interessado em configurar meu computador com criptografia total de disco e, como entendo, a partição / boot é a única parte complicada do processo. Ou seja, posso criptografar a partição / boot e instruir o GRUB a acessá-la adequadamente, mas como meu computador usa UEFI, precisarei de uma partição adicional não criptografada / boot / efi. Essa partição, como eu entendo, ainda é propensa ao ataque Maid Maid?
Existe alguma maneira de proteger essa partição, ou seja, sua integridade? Em outras palavras, existe alguma maneira que eu possa pelo menos receber um aviso uma vez que eu inicie o meu computador que minha partição / boot foi comprometida (verificação contra checksums, assinaturas, etc)?
Hoje eu aprendi sobre inicialização segura, mas algumas distribuições do Linux nas quais estou interessado não têm esse suporte (a saber, Debian). Então, há alguma coisa que eu possa fazer pelo menos após o login para descobrir se a integridade da partição / boot (/ boot / efi) foi comprometida?
Obrigado!
Na verdade, o Debian tem suporte para inicialização segura (você pode usar utilitários para assinar os kernels você mesmo - a única parte complicada é instalar as chaves de assinatura automática, que depende da implementação do UEFI).
Eu rodei o Debian 9 com inicialização segura ativada, com chaves auto-assinadas. Ele certamente pode proteger contra ataques triviais do tipo Evil Maid, como conectar uma unidade USB inicializável para capturar dados do sistema ou para instalar malware em partições não criptografadas. Mas isso dificilmente é o limite do que uma Maid Maid poderia fazer: se você é sério sobre isso, você também deve pensar sobre a segurança física do chassi do sistema.
Para verificações de integridade "retroativas", você precisaria de um chip TPM e um gerenciador de inicialização que utilizaria seus registradores PCR. Esses registros não podem ser definidos apenas para qualquer valor: quando novos dados são alimentados para esses registros, o próprio chip do TPM calculará um hash do valor antigo do registro + a entrada de dados e atribuirá isso como o novo valor do registro. O firmware do sistema preencherá os primeiros registros de PCR com os hashes do próprio firmware, as configurações atuais do firmware ea primeira parte do código de inicialização que foi realmente usado. Após esse ponto, o controle será transferido para esse código de inicialização.
Se você usou um gerenciador de inicialização que grava de forma semelhante os hashes do kernel e os arquivos initramfs realmente carregados nos registradores de PCR, você pode verificar os valores de PCR em relação a um conjunto de valores "conhecidos" armazenados na parte criptografada do disco. e exibir um aviso se os valores atuais não corresponderem ao estado em bom estado. O kernel também tem a opção CONFIG_IMA que, quando ativada, faz com que o kernel use um registrador de PCR do TPM para manter um hash de hashes de tudo que foi carregado. (Um hash de hashes, porque um TPM não é especialmente rápido: o envio de uma cópia completa de todos os dados carregados para o TPM para hashing retardaria enormemente o processo de inicialização.)
É claro que você teria que atualizar os valores válidos a cada vez que você atualizasse qualquer parte do sistema que fosse indexada nos PCRs, ou você obteria um alarme falso. Ao instalar uma atualização do sistema (por exemplo, um kernel com um patch de segurança) pode ser difícil prever antecipadamente quais serão os novos valores "bons" de PCR, então você pode ter que instalar a atualização, aceitar que a próxima inicialização irá acionar o alarme e, em seguida, registre o novo estado "bom".
Há alguns anos, quando experimentei os PCRs de TPM, foi com um sistema com um firmware de BIOS legado. Com o TrustedGRUB (basicamente uma versão do GRUB Legacy ativada pelo TPM), consegui implementar o tipo de verificação que descrevi no parágrafo anterior. Não tenho certeza se existe um carregador de boot UEFI do Linux com suporte a TPM disponível, portanto talvez você não obtenha uma cobertura completa de PCR do sistema anterior, a menos que inicialize usando apenas o carregador de stns UEFI integrado do kernel (para que o firmware termine gravação do hash do kernel real, em vez de apenas o bootloader).