Wie stoppt das Verschlüsseln der / home-Partition mit ecryptfs unter Linux die gefährliche Änderung von / boot oder / (root)?

704
pangolin

Auf dieser Seite erklärt ein Entwickler von ecryptfs den Unterschied zwischen ecryptfs und dm-crypt: https://stackoverflow.com/questions/18230784/what-is-difference-bween-linux-kernel-subsystem-dm-crypt-and -ecryptfs / 18234635 # 18234635 . Es blieb mir jedoch die Frage, ob ecryptfs nur die /homePartition verschlüsselt. Dies hindert einen böswilligen Hacker daran, die Partition /oder die /bootPartition zu ändern, um möglicherweise das Verschlüsselungskennwort ausfindig zu machen oder ein Programm zu ändern, usw.

Kurz gesagt, wie kann ich sicher sein, dass meine Computerdaten nicht nur nicht von Unbefugten gelesen werden können, sondern wie kann ich auch sicher sein, dass auf meinem Computer nichts geändert wird, ohne dass ich davon Kenntnis habe?

Wo endet das auch, weil der Boot-Code irgendwann unverschlüsselt sein muss, damit der Prozessor das verstehen kann? (Es sei denn, Sie verwenden eine Art Hardware-Entschlüsselung.) Aber per Definition kann alles Unverschlüsselte geändert werden?

(Nebenbei sehe ich eine Möglichkeit, die Integrität der Boot-Sequenz zu bestimmen, indem ein Hash des unverschlüsselten Teils des Boot-Codes im verschlüsselten Teil aufbewahrt wird und bei der Entschlüsselung ein vorberechneter Hash mit einem Hash des unverschlüsselten Teils von verglichen wird die Startsequenz zur Laufzeit. Dies löst jedoch nicht das Problem, dass unverschlüsselte Bereiche vorhanden sind. Es ist nur ein Weg, um herauszufinden, ob etwas geändert wurde.)

1

1 Antwort auf die Frage

1
davidgo

Die kurze Antwort lautet "sehr wenig", damit ein Hacker keine Änderungen an / booten kann - wirklich nur Zeit, unerkannter physischer Zugriff und die Möglichkeit, initrd mit einem Schlüssellogger neu zu kompilieren.

Nichts hindert einen böswilligen Hacker daran, ein Ecryptfs-basiertes / oder / boot zu ändern, wenn er physischen Systemzugriff hat - aber siehe später - darum geht es nicht.

"/" kann durch vollständige Festplattenverschlüsselung wie LUKS geschützt werden (jedoch nicht meines Wissens pro Dateiverschlüsselung) - Da das System ursprünglich von / boot gebootet wird, kann initrd die Passphrase anfordern, die zum Entsperren des Datenträgers vor dem Mounten benötigt wird.

Ich denke, Sie überschätzen die Fähigkeit der vollständigen Festplattenverschlüsselung - ich sage Ihnen, dass sie darauf abzielt, die Menschen vor nicht persistenten Bedrohungen zu schützen, beispielsweise wenn ein Laptop gestohlen wird oder wenn Sie eine Festplatte mit persönlichen Informationen auf RMA speichern möchten In beiden Fällen sind die Daten für Sie nicht weiter von Nutzen, Sie möchten jedoch den Zugriff einer unbekannten dritten Partei aufhalten. Oft ist eine dateibasierte Verschlüsselung Ihrer Dokumente ausreichend. Wer kümmert sich, wenn er eine unverschlüsselte Kopie des Systems besitzt binaries - sie sind sowieso Open Source.

Sie können Ihr System nicht vor unbefugten Personen mit lokalem Zugriff schützen. Daher besteht die Lösung darin, den physischen Zugriff zu verhindern. Sie können einen Teil dazu beitragen, sicherzustellen, dass keine Änderungen ohne Ihr Wissen vorgenommen werden, indem Sie alle Ihre Systemdateien prüfen und Vergleiche mit einem Offline-Backup durchführen. Dies ist jedoch nicht vollständig sicher, da Sie sicherstellen müssen, dass Sie ein nicht modifiziertes Prüfsummenprogramm ausführen macht das Wiederherstellen von Kollisionshashes praktisch unmöglich. [Möglicherweise können Sie dies vereinfachen, wenn Sie Ihre Dateisysteme voneinander trennen und einige Readonly-Dateien erstellen und dann einen einzelnen Hash für jede readonly-Partition aufbewahren.] Dieser ganze Prozess ist jedoch umständlich.

Bei der vollständigen Festplattenverschlüsselung "/" Sie würden den Computer normalerweise nicht als "root" verwenden, außer für Upgrades usw. - dies bietet ein gutes Maß an

Verwandte Probleme