[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Partition /home verschluesseln: Vergleich: Luks / Truecrypt & journaling, Fehleranfaelligkeit



Am Sonntag 25 November 2007 schrieb wolfgang friedl:
> Hallo Liste,
>
> ich ueberlege, mein /home (Partition) zu verschluesseln und erwaege
> entweder luks oder truecrypt.
> Fuer Luks sprechen mir die performance (L.magazin 10/06) und
> Mehr-User-"Faehigkeit".
>
> Habt ihr Erfahrungen mit Folgendem:
> * "Robustheit" von Luks und TC bei unsauberem Aushaengen (bzw. gar
> nicht aushaengen - ist natuerlich nicht der Standard... ),
> Wiederherstellbarkeit (1)
> * Darf/soll das Dateisystem auf dem Volume dann ein journaling fs sein
> (eher ext3 oder reiser?)
> * wuerde sich ein suspend-to-disk [verschluesselt oder
> unverschluesselt] mit der Sache "beissen" - wiegesagt, es geht nur im
> das home-VZ. ? * gibt es Knoppix o. aeh. Livedisks mit luks oder
> truecrypt onboard?

Hallo Wolfgang!

Ich verwende derzeit das FUSE-Dateisystem encfs. /tmp liegt in einem 
tmpfs, ist beim Ausschalten also eh weg.

Ich mache es derzeit noch manuell

encfs --public /home/.ms /home/ms

Im verschlüsselten Verzeichnis sieht das dann in etwa so aus:

shambala> ls /home/.ms | head -5                                                                                                 
~
0JSry0dSPB-A91
10IozWEUuX8Zr1Z2metjiM2P
1cBcJjpuWVrnOu1FcK5R2BEb5ZmY5bG09aA
1HVA6CEYiae93I-m8QrB2Z6K
3g-LmIilp9UqZ,

Die Dateiinhalte verschlüsselt encfs naturlich auch auch.

Was mir dabei gefällt:
- Ich muss nicht an Partitionsgrenzen entscheiden. Ich kann z.B. jedes 
Homeverzeichnis anders verschlüsseln.

- Ich kann fürs Backup rsync direkt auf die verschlüsselten Dateien 
loslassen, es ist fürs Backup also nicht erst eine Entschlüsselung und 
erneute Verschlüsselung erforderlich. Wichtig ist halt, dass ich 
Mountpoints für entschlüsselte Verzeichnisse vom rsync ausschließe.

- EncFS verschlüsselt zwar die Dateinamen und auch die Dateigröße ändert 
sich etwas, die eigentliche Struktur des darunterliegenden Dateisystems 
bleibt jedoch unverschlüsselt. Das könnte im Recovery-Fall hilfreich 
sein, da wirklich nur die Blöcke kaputt sind, die nicht gelesen werden 
können. Bei Blockgeräte-basierter Verschlüsselung sind je nach 
Algorithmus, so stelle ich mir das jedenfalls vor, evtl. auch 
benachbartete Bereiche eines nicht mehr lesbaren verschlüsselten Blocks 
nicht mehr entschlüsselbar.

- Während das Homeverzeichnis eines Users entschlüsselnd gemountet ist, 
können alle anderen noch verschlüsselt sein. Der User kann mit den 
anderen verschlüsselten Verzeichnissen also nix anfangen, auch wenn er 
das Passwort für seines weiß. So ganz stimmt das mit encfs --public 
jedoch nicht... normalerweise ist der Mount wirklich nur für den User 
zugänglich, nichtmal für "root", aber das haut dann mit dem Einloggen via 
X11 nicht hin, da da einige Dateien für root zugänglich sein müssen. Man 
kann glaub auch speziell einen weiteren User erlauben... das habe ich 
aber noch nicht zum Laufen bekommen. Auf meinem Notebook brauche ich das 
bislang allerdings nicht.


Nachteile:
- Die Verwendung eines Schlüssels statt Passwort ist nicht möglich. Das 
ist zumindest mein Stand des Wissens, vielleicht hat sich da mittlerweile 
was geändert.

- encfs verbirgt nicht ganz so viel. ein ls -l auf ein verschlüsseltes 
Verzeichnis offenbar die Anzahl der Dateien und Verzeichnisse sowie deren 
ungefähre Größe und die ungefähre Länge der Dateinamen. Auch die 
Berechtigungen sind sichtbar. Nun, mir reicht, was es verbirgt.


Alternative:
- ecryptfs, das ist im Kernel drin. Es hat mich bei meinen letzten Test 
allerdings nicht überzeugt. Jede Datei war dann mindestens 8KB groß, das 
wäre heftig für Maildirs und andere Verzeichnisse mit vielen kleinen 
Dateien. Ich glaube, mittlerweile lassen sich die 
Verschlüsselungsmeta-Informationen jedoch auch in extended attrs 
speichern, doch dann brauchts einen rsync mit xattr patch oder rsync 3.0, 
um das zu sichern


Ausbaumöglichkeiten:

- libpam-encfs ;) (oder vielleicht auch mit libpam-mount), das habe ich 
bislang noch nicht am Start.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: