¿Cómo el cifrado de la partición /home con ecryptfs en Linux detiene la modificación maliciosa de /boot o /(root)?

¿Cómo el cifrado de la partición /home con ecryptfs en Linux detiene la modificación maliciosa de /boot o /(root)?

Esta es una página donde un desarrollador de ecryptfs explica la diferencia entre ecryptfs y dm-crypt:https://stackoverflow.com/questions/18230784/what-is-difference-between-linux-kernel-subsystem-dm-crypt-and-ecryptfs/18234635#18234635. Sin embargo, esto me dejó con una pregunta: si ecryptfs solo cifra la /homepartición, ¿qué impide que un hacker malicioso modifique la partición /o /boottal vez para detectar la contraseña de cifrado o modificar un programa, etc.?

En resumen, ¿cómo puedo estar seguro de que no sólo los datos de mi computadora no pueden ser leídos por una persona no autorizada, sino también de que nada en mi computadora se modifica sin que yo lo sepa?

Además, ¿dónde termina esto porque, en algún momento, el código de arranque debe estar descifrado para que el procesador lo entienda? (A menos que utilice algún tipo de descifrado de hardware) Pero, por definición, ¿todo lo que no esté cifrado se puede modificar?

(Como punto adicional, puedo ver una forma de determinar la integridad de la secuencia de inicio manteniendo un hash de la parte no cifrada del código de inicio en la parte cifrada y, al descifrarlo, comparando el hash precalculado con un hash de la parte no cifrada de la secuencia de inicio en tiempo de ejecución Sin embargo, esto no resuelve el problema de tener áreas no cifradas, solo una forma de saber después del hecho si se modificó algo).

Respuesta1

La respuesta corta es "muy poco" impide que un hacker modifique /boot; en realidad, solo el tiempo, el acceso físico no detectado y la capacidad de recompilar initrd con un registrador de claves.

Nada impide que un hacker malintencionado modifique un / o /boot basado en ecryptfs si tiene acceso físico al sistema, pero (ver más adelante) no se trata de eso.

"/" se puede proteger usando cifrado de disco completo como LUKS (pero, que yo sepa, no por cifrado de archivos): como el sistema se inicia inicialmente desde /boot initrd, puede solicitar la frase de contraseña necesaria para desbloquear el volumen antes de montarlo /

Creo que está sobreestimando la capacidad del cifrado completo del disco; le digo que está diseñado para dejar de proteger a las personas contra amenazas no persistentes, como el robo de una computadora portátil o cuando desea obtener RMA de un disco duro con información personal, en En ambos casos, los datos ya no le son útiles, pero desea impedir que un tercero desconocido acceda a ellos (y, muy a menudo, el cifrado de sus documentos basado en archivos es adecuado), ¿a quién le importa si tienen una copia no cifrada del sistema? binarios: de todos modos son de código abierto.

No puede proteger su sistema de personas no autorizadas con acceso local a él, por lo que la solución es evitar el acceso físico. Puede avanzar de alguna manera para garantizar que las cosas no se modifiquen sin su conocimiento sumando todos los archivos de su sistema y comparándolos con una copia de seguridad fuera de línea (esto no es totalmente seguro ya que necesita asegurarse de que está ejecutando un programa de suma de verificación no modificado) y uno que hace que los hashes de colisión sean prácticamente imposibles de recrear. [Es posible que pueda simplificar esto si separa sus sistemas de archivos y hace que algunos de ellos sean de solo lectura, luego mantenga un único hash para cada partición de solo lectura]. Sin embargo, todo este proceso es engorroso.

Cuando utilice el cifrado de disco completo "/", normalmente no utilizará la computadora como "root", excepto para actualizaciones, etc.; esto proporciona un buen grado de

información relacionada