ZFS + GELI für Dinge wie /usr/home

S

SolarCatcher

Well-Known Member
Irgendwie finde ich immer nur Hinweise für full disk encryption. Ich will jetzt aber wieder nur eine Partition verschlüsseln, auf die ich dann die sensitiven Datasets wie /usr/home legen kann.

ada1p2 enthält das OS mit der zroot
ada1p3.eli soll als Backend für einen neuen ZFS pool dienen

Was mir nicht klar ist: An welcher Stelle kann ich dem System mitteilen, dass es ada1p3 als Geli-Provider entschlüsseln soll? Klassisch (mit UFS) habe ich dazu in /etc/rc.conf
Code: 
geli_devices="ada0p3"
geli_ada0p3_flags="-k /path/to/ada0p3.key"
Und in /etc/fstab sowas wie
Code: 
/dev/ada0p3.eli /usr/home  ufs  rw  2  2
Dann werde ich beim Hochfahren des Rechners nach dem Passwort gefragt, sobald /usr/home gemounted werden soll.

Wie erreiche ich etwas vergleichbares, wenn ich ZFS nehme?
 
Ich kann dir nur von solchen Setups abraten. Es lässt sich kaum sinnvoll für alle Anwendungen auditieren wo sie temporäre Dateien liegen lassen z.B. könnte ein Editor alle deine Dateien aus $HOME nach /var/tmp/ leaken indem er dort Autosaves speichert. Ein Browser könnte Videos durch /tmp spoolen usw. Auf auch nur halbwegs zeitgemäßer Hardware mit AESNI spielt der GELI Overhead keine Rolle. Selbst mein Laptop schafft trotz GELI mehr als ein GB/s von seinen SSDs bei einem ZFS Scrub.

Sofern du sicheren Zugriff auf die Systemkonsole hast (by default Keyboard und Videooutput) würde ich ZFS mit GELI drunter für FDE (full disk encryption) verwenden. Seit FreeBSD 10.3 versteht der FreeBSD Bootloader auch Bootumgebungen.

Sollte das System ohne lokale Tastatureingaben starten können gibt wäre die nächst beste Lösung eine (virtuelle) serielle Systemkonsole. Die meisten x86er Server bieten dies per IPMI. Natürlich ist die IPMI Transportverschlüsselung nicht zu gebrauchen du solltest das also nicht quer durchs LAN schicken.

Falls dies alles nicht möglich ist gibt es sei FreeBSD 10.3 das sog. Rerooting. Damit kannst du ein unverschlüsseltes FreeBSD System booten um die GELI Provider einzuhängen (z.B. über SSH) und anschließend mittels reboot -r fast runterfahren und neustarten. Beim Rerooting werden alle Userspaceprozesse inklusive init beendet und alle Dateisysteme inklusive / unmounted. Anschließend mounted der Kernel ein neues Rootdateisystem und startet einen neuen init Prozess anstatt runterzufahren. Damit kannst du das unverschlüsselte Rootdateisystem durch ein verschlüsseltes ersetzen. Leider ist das etwas umständlich aufzusetzen, aber ich verwende es erfolgreich auf einem dedicated Rootserver.
 
Hallo Crest,

danke für Deine Einschätzung. Es gibt im Netz viele Hinweise und Howtos für ZFS + GELI full disk encryption - teilweise Jahr alt. Mit dem Installer (von 11-ALPHA1 bin ich leider gescheitert). Was ist denn derzeit die beste Lösung, wenn man das händisch installieren will/muss? Ich möchte gerne 11 installieren, um Win10 unter Bhyve nutzen zu können - ich benötige das gelegentlich für die Arbeit.

Ansonsten noch der Hinweis: Das ganze ist tatsächlich auch "nur" für meinen Arbeitslaptop. Es geht mir nicht darum, die NSA zu überlisten und das letzte bisschen zu verschlüsseln. Vor allem geht es darum, dass ein vielleicht einmal gestohlener Laptop nicht gleich ein Problem ist (von Kundeninformationen bis Kreditkartendaten). Bisher bin ich mit der Verschlüsselung von /usr/home sowie von Swap (wobei /tmp als tmpfs läuft und notfalls dahin ausgeswappt würde) zufrieden gewesen. Die möglichen Datenleaks nach /var/irgendwas kann ich - glaube ich - verkraften.

Trotzdem: Wenn es einen praktikablen Weg zur Full-disk-encryption mit ZFS-on-root gibt nehme ich den gerne. Aber jüngste Posts von Allan Jude, der ja daran in Zusammenhang mit EFI-Boot arbeitet, schienen mir darauf hinzuweisen, dass das noch nicht ganz komplett ist. Muss man dafür über einen MBR gehen?

Schöne Grüße
SolarCatcher
 
Nun, es gibt derzeit für Full Disc Encryption drei Wege:
  • Klassisch und seit irgendwann in den FreeBSD 7.x unterstützt ist ein unverschlüsseltes /boot mit einem verschlüsselten /. Der Loader lädt den Kernel von /boot, der Kernel fragt nach dem Kennwort für / und entschlüsselt es. Das funktioniert mit BIOS-Boot und UEFI-Boot. Allerdings harmoniert es nur schlecht mit ZFS Boot Environments und der unverschlüsselt gespeicherte Kernel ist ein möglicher Angriffspunkt.
  • Neuerdings unterstützt der Loader selbst GELI, wodurch er den Kernel vom verschlüsselten / laden kann. Das funktioniert derzeit nur mit dem BIOS-Boot, für den UEFI-Boot gibt es Patches und letztens dazu eine Grundsatzdiskussion auf hackers@, ob man das wirklich will. Der Vorteil ist, dass der Kernel verschlüsselt gespeichert wird und es ZFS Boot Environments stark vereinfacht. Der Nachteil ist, dass die BIOS- oder UEFI-Umgebung Zugriff auf die Schlüssel bekommt.
  • Das von Crest beschriebene Rerooting.
Um einzelne ZFS-Datasets zu verschlüsseln ist sysutils/pefs-kmod meist der genutzt Weg.
 
Die BIOS bzw. EFI Firmware kann auch einfach nen bösartigen SMM Handler verwenden um Privilege Escalation zu ermöglichen. Wer seiner Firmware misstraut kann das Gerät nur noch der thermischen Endverwertung durch Thermit zuführen.
 
Kleines Update: Mit Euren Hinweisen (Danke, Yamagi) hat es geklappt. Ich hatte doch noch nicht alle sinnvollen Kombinationen ausprobiert. Im Installer "GPT (Bios)" ausgewählt und dann ging es - mit passender Bios-Einstellung, natürlich.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben