Fremde Daten aufs Dateisystem abbilden

Es scheint ein Wesenszug von Computerdaten zu sein, möglichst verstreut aufzutreten: In Datenbanken, auf Fileservern, in Mailboxen oder auf Chipkarten. Und für jedes dieser Speichermedien gibt es extra Software, mit der die User auf ihre Daten zugreifen müssen. Wünschenswert wäre eine einheitliche Schnittstelle zu allen Informationen. Die hier vorgestellten Userspace-Dateisysteme leisten genau dies. Sie stellen Anwendern Daten aus den verschiedensten Quellen im Dateisystem bereit. So reduziert sich die Aufgabe, Informationen von der lokalen Chipkarte zum Computer am anderen Ende der Welt zu schicken, auf den einfachen Aufruf »cp Quelldatei Zielverzeichnis«.

Obwohl sich die zahlreichen Implementierungen im Detail unterscheiden, ist das Prinzip der Userspace-Dateisysteme stets gleich. Ein Kernelmodul hängt sich in das virtuelle Filesystem (VFS) des Kernels ein und fängt Systemaufrufe wie »open()«, »read()« und »write()« ab. Diese leitet es an einen Daemon oder eine Bibliothek weiter. Die kümmern sich dann um die Ausführung des Aufrufs, etwa bei einem »read()« den entsprechenden Befehl über das SSH-Protokoll an den entfernten Rechner zu schicken. Abbildung 1 illustriert diese Funktionsweise anhand von SHFS[1], das eine SSH-Verbindung ins Dateisystem einbindet. Dank des VFS bemerken die Anwendungen gar nicht, aus welcher Quelle die Dateien kommen.

Abbildung 1: Über ein Kernelmodul erhalten Userspace-Filesysteme den Zugriff auf die Systemaufrufe. Das VFS erlaubt die verschiedensten Kombinationen. ProcFS etwa stellt Systeminformationen bereit und NFS beliefert den Anwender mit Daten aus dem Netzwerk.

Vorteil Userspace

Theoretisch wäre es auch möglich, alle Funktionen direkt in den Kernel zu integrieren. Doch es ist sinnvoller, nur den unabdingbaren Teil der Programmlogik in ein Kernelmodul zu packen. Im Userspace nutzen die Programmierer dann die schon vorhandenen Bibliotheken und Programme. Den Großteil der Logik in den Userspace zu verlagern, eröffnet den Programmierern somit schier unendliche Möglichkeiten.

Mit den beiden Frameworks Fuse[2] und Lufs[3] lassen sich relativ einfach neue Dateisysteme entwickeln. Sie enthalten beide ein Kernelmodul und stellen für es Interfaces bereit. Bei Fuse erstellt der Programmierer ein eigenes Binary, das sich um das Mounten kümmert, in Lufs gibt es das generische Programm »lufsmount«, das eine jeweils passende Shared Library zur Laufzeit einbindet.

Fuse-Framework

Da die meisten Distributoren (außer Debian) keine Fuse-Pakete ausliefern, müssen Anwender die Sourcen von der Website[2] selbst kompilieren. Das geht aber problemlos vonstatten. (Trotz einer Fehlermeldung wie »failed to set capabilities: Operation not permitted« beim Mounten von Fuse-Filesystemen funktioniert das System.) Die Fuse-Suite kommt lediglich mit einem kleinen Beispielprogramm. Eine Liste aller Dateisysteme gibt es auf[4].

Eines davon ist EncFS[5], das Dateien transparent on the fly verschlüsselt. Es benutzt die OpenSSL-Bibliothek und ist einfach zu handhaben. Nach der Installation genügt der Aufruf »encfs Quellverzeichnis Zielverzeichnis«. Alle Dateien, die Anwender nun im Verzeichnis Zielverzeichnis anlegen, verschlüsselt EncFS. Die geschützten Dateiversionen landen im Quellverzeichnis. Nach dem Unmounten verschwinden die Dateien aus Zielverzeichnis wieder . In Listing 1 ist eine Beispielsession dargestellt.

01 murdoc:/home/mwerner/crypt/encfs$ encfs ~mwerner/crypt/encfs/raw/ ~mwerner/crypt/encfs/work/
02 EncFS Password:
03 murdoc:/home/mwerner/crypt/encfs$ ls work/
04 bar  foo  hello  test1  test2
05 murdoc:/home/mwerner/crypt/encfs$ touch work/diesisteintestencfsisttoll
06 murdoc:/home/mwerner/crypt/encfs$ fusermount -u ~mwerner/crypt/encfs/work/
07 murdoc:/home/mwerner/crypt/encfs$ ls raw/
08 BrzSPmfOyQShlXuiqnK,pTGE  Iqhy2xMtpIgZySpATSWqW8Tq  tSjZO5MKdWKAyinOnicF5amoHFLeHLAAF64usx69QsNm70
09 C5PWTazUPXqZ7A4bO5RyVm2A  m02yh6RPu8g6kw6W-DcSfTDC
10 D8A8qec=                  saoS-CJfXj2Gr,Q,ATWGPnTS
11 murdoc:/home/mwerner/crypt/encfs$

EncFS arbeitet also ähnlich wie die Kernelspace-Implementationen (DM-Crypt, Cryptoloop, Loop-AES). Doch da es im Userspace arbeitet, ist es flexibler: In den oben genannten Kernel-Crypto-Filesystemen müssen Anwender ein Dateisystem mit einer festen Größe anlegen, das sich nicht vergrößern oder verkleinern lässt. Da EncFS auf Verzeichnisebene arbeitet, ist die Größe lediglich durch die Partition bestimmt, auf der das verschlüsselte Verzeichnis liegt. Außerdem gestalten sich Backups leichter, da das Backupprogramm das Dateisystem nicht mounten muss, sondern einfach die verschlüsselten Dateien kopiert.

Angreifern ist es allerdings möglich, die Anzahl, Größe oder Rechte der verschlüsselten Dateien zu sehen. Daher ist EncFS nicht ganz so sicher wie seine Kernel-basierten Kollegen. Im Test wollte es außerdem nicht mit regulären Benutzern zusammenarbeiten, daher war es nötig, als Root zu mounten und die Rechte entsprechend zu setzen.