Die meisten Leute einschließlich der Entwickler halten das für ein vernachlässigbares Problem. Zudem können normale User gar nicht an diese Informationen gelangen, wenn man die Permissions entsprechend setzt.
Ich halte es auch nicht für ausgeschlossen, dass dieser Punkt nochmal überarbeitet wird. Auf jeden Fall ist es besser als keine Verschlüsselung, und man darf gespannt sein, ob und wie es in 4.1-rc1 erscheinen wird.
Für mich liegt der Sinn einer Verschlüsselung wenn mein Laptop gestohlen wird. Wenn mein Laptop gestohlen wird, kann jeder die Festplatte und meine Daten auslesen, da nützt das Linux Rechtesystem nichts. Einfach Linux Live-CD und als Root die Festplatte auslesen. Nur eine Verschlüsselung kann dies verhindern und da muss alles verschlüsselt sein, auch die Metadaten.
Schon mal Folgendes ausprobiert: Home ist für alle user verschlüsselt mit ecryptfs. Zuerst meldet sich user1 an. Dann user2, der auch in den sudoers ist. User2 erhält nun mit sudo root Rechte und kann schön ALLES lesen was im home von user1 ist! Also wenn das keine Sicherheitslücke höchsten Ranges ist...
Root darf *alles*, also natürlich auch auf momentan entschlüsselt eingebundene Dateisysteme zugreifen. Das ist keine Sicherheitslücke, sondern ergibt sich rein aus dem Root-Prinzip. Gleiches gilt ja auch für sshfs-Mounts etc.
Die prinzipbedingte "Sicherheitslücke" jeder Verschlüsselung besteht aus dem unvermeidbaren Fakt, dass man nur mit entschlüsselten Daten arbeiten kann.
Lösung: Nur vertrauenswürdigen Leuten Rootrechte geben.
Weiß jemand warum das jetzt schneller sein sollte? Die Daten müssen ver- und entschlüsselt werden, ob das jetzt über oder unter dem Dateisystem passiert.
Ist mir auch nicht ganz klar, aber die Kernelentwickler werden es schon verstehen und gemessen haben.
Ich verwende jetzt seit geraumer Zeit (Voll-)Verschlüsselung mit dm-crypt/LUKS auf meinem Laptop (Core i5 mit AES-Coprozessor). Ich merke keinen spürbaren Geschwindigkeitsnachteil zum Zeitraum vorher, habe allerdings auch noch nie gezielt gemessen.
Von Martin Steigerwald am Fr, 10. April 2015 um 13:31 #
ecryptfs ist ein Stacked Filesystem. D.h. es arbeitet im Grunde genau wie die Verzeichnis-Verschlüsselung von Ext4 der Beschreibung im Artikel nach arbeitet, mit dem Unterschied, dass sie eben nicht in das Original-Dateisystem integriert ist, sondern über ein Verzeichnis desselben das ecryptfs drüber gemountet ist.
Das Passwort ist dann beim Mounten anzugeben. Da habe ich noch nicht geschaut, wie das bei den Ext4 Verschlüsselungspatches ist.
So läuft ecryptfs hier für einen Benutzer auf einem BTRFS RAID 1. Und das durchaus schnell genug. Jedenfalls deutlich schneller als encfs.
So oder so, hätte ich das Verschlüsselung auch gerne direkt in BTRFS integriert :).
Ne das ist dann doch nix wenn die Dateiattribute und Verzeichnisstruktur sichtbar sind. Da bleibe ich bei LUKS und Truecrypt.
Die meisten Leute einschließlich der Entwickler halten das für ein vernachlässigbares Problem. Zudem können normale User gar nicht an diese Informationen gelangen, wenn man die Permissions entsprechend setzt.
Ich halte es auch nicht für ausgeschlossen, dass dieser Punkt nochmal überarbeitet wird. Auf jeden Fall ist es besser als keine Verschlüsselung, und man darf gespannt sein, ob und wie es in 4.1-rc1 erscheinen wird.
Für mich liegt der Sinn einer Verschlüsselung wenn mein Laptop gestohlen wird. Wenn mein Laptop gestohlen wird, kann jeder die Festplatte und meine Daten auslesen, da nützt das Linux Rechtesystem nichts. Einfach Linux Live-CD und als Root die Festplatte auslesen. Nur eine Verschlüsselung kann dies verhindern und da muss alles verschlüsselt sein, auch die Metadaten.
Nur eine Verschlüsselung kann dies verhindern und da muss alles verschlüsselt sein, auch die Metadaten.
Wenn Dateinamen und Dateiinhalte verschlüsselt sind, dürfte das für die meisten Anwendungen ausreichen.
Was nutzen dem durchschnittlichen Dieb Deine Metadaten?
Schon mal Folgendes ausprobiert:
Home ist für alle user verschlüsselt mit ecryptfs. Zuerst meldet sich user1 an. Dann user2, der auch in den sudoers ist. User2 erhält nun mit sudo root Rechte und kann schön ALLES lesen was im home von user1 ist! Also wenn das keine Sicherheitslücke höchsten Ranges ist...
Dafür musst - du - User2 bewusst oder unbewusst ermöglichen, sich in deiner Sitzung anzumelden.
Oder er muss dein Passwort kennen.
Root darf *alles*, also natürlich auch auf momentan entschlüsselt eingebundene Dateisysteme zugreifen. Das ist keine Sicherheitslücke, sondern ergibt sich rein aus dem Root-Prinzip. Gleiches gilt ja auch für sshfs-Mounts etc.
Die prinzipbedingte "Sicherheitslücke" jeder Verschlüsselung besteht aus dem unvermeidbaren Fakt, dass man nur mit entschlüsselten Daten arbeiten kann.
Lösung: Nur vertrauenswürdigen Leuten Rootrechte geben.
Das hätte ich jetzt gerne noch für BtrFS…
Weiß jemand warum das jetzt schneller sein sollte? Die Daten müssen ver- und entschlüsselt werden, ob das jetzt über oder unter dem Dateisystem passiert.
Ist mir auch nicht ganz klar, aber die Kernelentwickler werden es schon verstehen und gemessen haben.
Ich verwende jetzt seit geraumer Zeit (Voll-)Verschlüsselung mit dm-crypt/LUKS auf meinem Laptop (Core i5 mit AES-Coprozessor). Ich merke keinen spürbaren Geschwindigkeitsnachteil zum Zeitraum vorher, habe allerdings auch noch nie gezielt gemessen.
Bsp. Suchen nach einer Datei mit bestimmten Datum
Vollverschlüsselung: muss Metadaten bei jeder Datei entschlüsseln
Nur-Inhalte-Verschlüsselung:
Metadaten müssen nicht erst entschlüsselt werden.
In der Praxis dürfte der Geschwindigkeitsvorteil minimal und nur messbar sein.
ecryptfs ist ein Stacked Filesystem. D.h. es arbeitet im Grunde genau wie die Verzeichnis-Verschlüsselung von Ext4 der Beschreibung im Artikel nach arbeitet, mit dem Unterschied, dass sie eben nicht in das Original-Dateisystem integriert ist, sondern über ein Verzeichnis desselben das ecryptfs drüber gemountet ist.
Das Passwort ist dann beim Mounten anzugeben. Da habe ich noch nicht geschaut, wie das bei den Ext4 Verschlüsselungspatches ist.
So läuft ecryptfs hier für einen Benutzer auf einem BTRFS RAID 1. Und das durchaus schnell genug. Jedenfalls deutlich schneller als encfs.
So oder so, hätte ich das Verschlüsselung auch gerne direkt in BTRFS integriert :).