Como a criptografia da partição /home com ecryptfs no Linux interrompe a modificação maliciosa de /boot ou /(root)?

Como a criptografia da partição /home com ecryptfs no Linux interrompe a modificação maliciosa de /boot ou /(root)?

Esta é uma página onde um desenvolvedor de ecryptfs explica a diferença entre ecryptfs e dm-crypt:https://stackoverflow.com/questions/18230784/what-is-difference-between-linux-kernel-subsystem-dm-crypt-and-ecryptfs/18234635#18234635. No entanto, isso me deixou com uma pergunta: se o ecryptfs criptografa apenas a /homepartição, o que impede um hacker mal-intencionado de modificar a partição /ou /bootpara talvez detectar a senha de criptografia ou modificar um programa, etc.

Resumindo, como posso ter certeza de que não apenas os dados do meu computador não poderão ser lidos por uma pessoa não autorizada, mas também como posso ter certeza de que nada no meu computador será modificado sem que eu saiba?

Além disso, onde isso termina porque, em algum momento, o código de inicialização deve ser descriptografado para que o processador o entenda? (A menos que você use algum tipo de descriptografia de hardware) Mas, por definição, qualquer coisa não criptografada pode ser modificada?

(Como ponto secundário, posso ver uma maneira de determinar a integridade da sequência de inicialização, mantendo um hash da parte não criptografada do código de inicialização na parte criptografada e na descriptografia comparando um hash pré-computado com um hash da parte não criptografada de a sequência de inicialização em tempo de execução No entanto, isso não resolve o problema de ter áreas não criptografadas, apenas uma forma de saber após o fato se algo foi modificado)

Responder1

A resposta curta é "muito pouco" impede um hacker de modificar /boot - realmente apenas tempo, acesso físico não detectado e a capacidade de recompilar o initrd com um key logger.

Nada impede um hacker malicioso de modificar um / ou / boot baseado em ecryptfs se ele tiver acesso físico ao sistema - mas veja mais tarde - não é disso que se trata.

"/" pode ser protegido usando criptografia completa de disco como LUKS (mas não, que eu saiba, por criptografia de arquivo) - Como o sistema é inicializado inicialmente a partir de /boot, o initrd pode solicitar a senha necessária para desbloquear o volume antes da montagem /

Acho que você está superestimando a capacidade de criptografia completa do disco - eu disse a você que ela foi projetada para parar de proteger as pessoas contra ameaças não persistentes, como o roubo de um laptop ou quando você deseja fazer RMA de um disco rígido com informações pessoais - em em ambos os casos, os dados não têm mais utilidade para você, mas você deseja impedir que terceiros desconhecidos os acessem - e, muitas vezes, a criptografia baseada em arquivo dos seus documentos é adequada - quem se importa se eles têm uma cópia não criptografada do sistema binários - eles são de código aberto de qualquer maneira.

Você não pode proteger seu sistema de pessoas não autorizadas com acesso local a ele - portanto, a solução para isso é impedir o acesso físico. Você pode garantir que as coisas não sejam modificadas sem o seu conhecimento, somando todos os arquivos do seu sistema e fazendo comparações com um backup offline - isso não é completo, pois você precisa ter certeza de que está executando um programa de soma de verificação não modificado - e um que torna os hashes de colisão praticamente impossíveis de recriar. [Você pode simplificar isso se separar seus sistemas de arquivos e tornar alguns deles somente leitura e, em seguida, manter um único hash para cada partição somente leitura]. Todo esse processo é complicado.

Ao usar criptografia completa de disco "/" Você normalmente não usaria o computador como "root", exceto para atualizações, etc. - isso fornece um grau razoável de

informação relacionada