FreeBSD 11 - ZFS, Geli + USB

J

joneum

Guest
Ich habe hier einen neuen Rechner, der 2x 1TB und 1x 100GB zur Verfügung stellt. 16 GB sind in der Kiste verbaut.
Es wurde eben frisch FreeBSD 11 amd64 mit ZFS Installiert. Nun steht die Überlegung im Raume , das System mittels Geli zu Verschlüsseln.
Im Wiki finden sich 3 Artikel, leider alle aus 2011, also nicht mehr wirklich Zeitgemäß.
Auch im Web findet man nicht wirklich etwas aktuelles.

Hat hier jemand ein FreeBSD 11 mit ZFS am laufen, das mit Geli verschlüsselt wurde?

Interessant finde ich noch die Zusätzliche Option, das System nur dann booten zu lassen wenn ein USB stick gesteckt ist.

Hat hier jemand Erfahrungswerte, da Geli für mich komplettes Neuland wäre.
 
Das läuft eigentlich ziemlich unabhängig voneinander. Du legst einen Geli-Container an, dann packst Du das ZFS da rein.
 
Das Thema ist komplex. Alle FreeBSD-Versionen vor 11.0 müssen den Kernel auf einem unverschlüsselten Dateisystem speichern. Man braucht also Minimum 3 Partitionen:
  • Den Bootloader
  • /boot
  • /
Das Problem dabei ist, dass ZFS Boot Environments nicht funktionieren können, wenn /boot nicht auf dem Dataset des Root-Dateisystems liegt. Außerdem landet man schnell in einer Symlink-Orgie, da innerhalb des /boot Dateisystem die korrekte Verzeichnisstruktur erhalten bleiben muss. Der Loader erwartet /boot/loader. Im System ergibt sich dadurch /boot/boot/loader (das erste /boot ist Mounpoint, /boot/loader dann der Pfad innerhalb des Dateisystems), was diverse Tools wiederum nicht so toll finden...

Ab 11.0 kann daher der BIOS-Loader (für den UEFI-Loader gibt es Patches) den Kernel von einem verschlüsselten Dateisystem laden. Damit braucht man kein seperates /boot mehr, die Probleme sind Geschichte. Der einzige Nachteil ist, dass man keine Keyfiles nutzen kann. Da es dazu noch wenig Doku gibt und ich es letzte Woche gerade gemacht habe, einmal auf dem Kopf für GPT geschrieben:
  1. Wir legen eine neue Partitionstabelle an. Darein kommen mindestens 3 Partitionen, eine für den Bootloader und eine für das ZFS und eine für die Swap:
    Code:
    gpart create -s gpt ada0
    gpart add -a 4k -t freebsd-boot -s 256 -l boot ada0
    gpart add -a 4k -t freebsd-swap -s 8G -l swap ada0
    gpart add -a 4k -t freebsd-zfs -l root ada0
    gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
  2. Nun das Geli anlegen. -g sagt ihm, dass der Loader den Kernel von dieser Partition laden soll. Das ist notwendig, da er ohne Kennwort ja nicht in die Partition schauen kann und daher nicht weiß, dass auf ihr der Kernel liegt. -b sagt dann später dem Kernel, dass er die Partition entschlüsseln soll. Er wird nicht nach dem Kennwort fragen, da er dieses vom Loader übergeben bekommt. Man muss es also nur einmal eingeben:
    Code:
    geli init -l 256 -g -b /dev/gpt/root
  3. Nun kann man /dev/gpt/root per 'geli attach' öffnen, den zpool anlegen und darauf normal installieren. Nach der Installation muss noch die verschlüsselte Swap in die /etc/fstab des neuen Systems eingetragen werden:
    Code:
    /dev/gpt/swap.eli  none  swap  sw  0  0
  4. Nach einem Neustart fragt der Loader nach dem Passwort. Auf englisches Layout achten! Wenn man es 3x falsch eingegeben hat, einmal strg-alt-entf und von vorne.
Das ist nun sehr schematisch. Wenn noch Fragen sind, immer her damit. Man kann es noch erweitern. Zum Beispiel diskutieren, ob man TRIM auf den verschlüsselten Partitionen will. Oder weitere Geli-Devices beim Boot automatisch entschlüsseln.
 
Hallo @joneum , ja hier! Ich nutze die Full-Disk-Encryption, die der Installer mitbringt. Das allerdings funktioniert nicht mehr mit einem Key, sondern nur noch mit einer Passphrase. Das hatte mich zunächst verwirrt, aber Allan Jude, der das "verbrochen" hat, hat's dann erklärt - siehe diesen Thread.

Die Version mit USB-Schlüssel hatte ich früher einmal am Laufen. Vom Key wurde FreeBSD gebootet, die Platte entschlüsselt und dann weiter mit den Dateien von der Festplatte gearbeitet. Allerdings hatte ich mehrfach Probleme mit den USB-Keys (ich hatte so kleine im Portmonnaie und die haben einfach nicht lange gehalten) und hab's später wieder gelassen und dann nur mein HOME-Verzeichnis sowie Swap verschlüsselt.

Die Standard-Methode (per Installer) in 11 läuft für mich absolut einwandfrei. Die Anzahl der Runden für die Verschlüsselung wird beim Installieren dynamisch ermittelt - wenn ich mich recht erinnere, wird die Anzahl immer verdoppelt, bis die Berechnung auf dieser Hardware mind. 2 Sekunden dauert (man kann aber wohl auch von Hand einen anderen Wert einstellen, z.B. wenn man auf einem schwach-brüstigen System ist und nicht will, dass die Platte oder SD-Card auf einem schnellen Rechner vielleicht doch in akzeptabler Zeit geknackt werden kann).
 
Ich habe eben gemerkt, dass ich bei der Installation Vergessen habe, ZFS mit der Option "Encrypt Disks?" zu aktivieren ... Ist es da Sinnvoll, die FreeBSD Installation nochmals mit dieser Option zu wiederholen?
 
Ja. Anders wirst Du kaum zu einer Vollverschlüsselung kommen (bzw. falls es einen Weg gibt, ist der vermutlich nicht gerade schneller).
 
Ich wollte am Wochenende auch einmal die manuelle Installation von FreeBSD mit UEFI-Boot von ZFS auf geli-Verbund von 3 SSDs probieren.

Die aktuellste Doku, die ich hier gefunden habe (10.1), schlägt noch UFS als /boot Partition vor. Der Installer hat mir allerdings einen unverschlüsselten "bootpool" erstellt...

@Yamagi kann ich den von dir beschriebenen Weg hier als Einstiegspunkt verwenden?

Wenn möglich würde ich den Kernel gern vom UEFI-Loader per Passphrase booten lassen (also alles encrypted und kein UFS). Ist das möglich?

Gruß
 
Zuletzt bearbeitet:
Vielleicht solltest du noch überlegen, -e aes-cbc zu verwenden, ist auf allen meinen Rechnern deutlich schneller als aes-xts (default wenn man -e weglässt). Kann man ja im Zweifel auch mal kurz testen.
 
@Yamagi kann ich den von dir beschriebenen Weg hier als Einstiegspunkt verwenden?

Wenn möglich würde ich den Kernel gern vom UEFI-Loader per Passphrase booten lassen (also alles encrypted und kein UFS). Ist das möglich?
Nein, ein verschlüsseltes /boot mit UEFI wird derzeit noch nicht unterstützt. Das ist in Arbeit, es gab dazu auch schon einen Call for Testers. Vielleicht zu FreeBSD 11.1, aber drauf wetten würde ich nicht. Das Passwort bzw. den aufgelösten Schlüssel sicher vom Loader an den Kernel zu übergeben und sicherzustellen, dass er nicht irgendwo im RAM bleibt, ist bei UEFI wesentlich komplizierter als beim klassischen BIOS-Boot. Daher braucht es seine Zeit... Du kannst also per BIOS booten, was ich empfehlen würde, oder du arbeitest mit einem unverschlüsselten /boot. Das kostet dich aber ZFS Boot Environments, zumindest wenn sie ohne Gefrickel auskommen sollen.

Vielleicht solltest du noch überlegen, -e aes-cbc zu verwenden, ist auf allen meinen Rechnern deutlich schneller als aes-xts (default wenn man -e weglässt). Kann man ja im Zweifel auch mal kurz testen.
Und damit hast du dich gerade gegen Bit Flipping Attacks angreifbar gemacht.
 
Vielleicht solltest du noch überlegen, -e aes-cbc zu verwenden, ist auf allen meinen Rechnern deutlich schneller als aes-xts (default wenn man -e weglässt). Kann man ja im Zweifel auch mal kurz testen.
Keine gute Idee, AES-XTS hat für Disk Encryption seine Berechtigung.

Davon abgesehen: AES-XTS sollte auf aktueller Hardware dank AESNI-Beschleunigung eigentlich nicht langsamer sein, im Gegenteil - siehe Artikel von Intel. Mal per kldstat geprüft, ob aesni.ko geladen ist? Anstonsten in der loader.conf per aesni_load="YES" aktivieren.

Gruß
 
Und damit hast du dich gerade gegen Bit Flipping Attacks angreifbar gemacht.

Die Checksums auf ZFS sollten das erkennen und den ganzen Block verwerfen. Zudem gibt es ähnliche, und teils schwerwiegendere Probleme mit XTS (https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ ).

Ad AESNI: Auf meinen BSD Servern ist kein AESNI verhanden, wenn wir uns aber um Sachen wie bitflipping gedanken machen, sollten wir auch in betracht ziehen, dass dem AESNI von Intel nicht zu trauen ist (Siehe RNG von Intel).
 
..., dass dem AESNI von Intel nicht zu trauen ist (Siehe RNG von Intel).

Das ist ein ganz guter Punkt. Wollte hier ebenfalls danach gefragt haben. Wusste aber nicht, wie ich die Frage formulieren soll ...

Ich habe letztes Wochenende während meines Custom-Kernel-Experimentier-Maratons folgenden (alten) Artikel entdeckt:

https://m.theregister.co.uk/2013/12/09/freebsd_abandoning_hardware_randomness/

Da mein Xeon auch ein solches "Schmuckstück" beinhaltet, habe ich mir nun die Frage gestelt, ob ich den Treiber dafür nun im Kernel lassen oder deaktivieren soll.

Das FreeBSD die Ergebnisse von RDRAND erst durch nen anderen Algorithmus jagt, habe ich verstanden. Aber wird dadurch der Hanrdwaregenerator nicht so oder so überflüssig?
 
Das ist ein ganz guter Punkt. Wollte hier ebenfalls danach gefragt haben. Wusste aber nicht, wie ich die Frage formulieren soll ...

Ich habe letztes Wochenende während meines Custom-Kernel-Experimentier-Maratons folgenden (alten) Artikel entdeckt:

https://m.theregister.co.uk/2013/12/09/freebsd_abandoning_hardware_randomness/

Da mein Xeon auch ein solches "Schmuckstück" beinhaltet, habe ich mir nun die Frage gestelt, ob ich den Treiber dafür nun im Kernel lassen oder deaktivieren soll.

Das FreeBSD die Ergebnisse von RDRAND erst durch nen anderen Algorithmus jagt, habe ich verstanden. Aber wird dadurch der Hanrdwaregenerator nicht so oder so überflüssig?

Die Frage ist, ob du überhaupt so viel Zufall benötigst. Die standard Algorithmen von BSD / LINUX .. sind sehr gut, das lässt sich nachvollziehbar testen ( FIPS 140-2 RNG ). Ein HW Generator zahlt sich nur aus, wenn du wirklich so viel Zufall brauchst, dass das OS mit den soft-Methoden nicht nach kommt. Spontan fallen mir da wenig Anwendungsfälle ein.
 
Hy!

Ich habe nun ein paar Stunden damit verbracht, die Installation von Hand nachzuvollziehen. Leider finde ich im Internet nur Tutorials aus denen ich nicht wirklich schlau werde ...
Zu letzt habe ich eine solche Installation mit FreeBSD 10.2 und UFS auf einer einzigen Platte realisiert (MBR/BSD) ... mein Vorwissen nützt mir also nix.

Mein Ziel ist es, 4 Platten (SSD) in einem verschlüsselten Verbund (Stripe) zusammenzulegen und darauf dann ZFS zu erstellen. Die Verschlüsselung soll ein Passphrase fordern, sobald der Bootloader anspringt. In meiner bisherigen Installation muss ich 2x ein Passwort eingeben -> direkt vor dem Loader und wenn der Kernel geladen wurde und Geli die Platten entschlüsseln will. Das würde ich gerne so beibehalten. Pro Platte soll eine verschlüsselte Swap-Partition außerhalb von ZFS erstellt werden

Da ich die von @Yamagi empfolene Methode anwenden wollen würde, stelle ich mir zu Beginn die Frage: GPT oder MBR mit BSD Slices? Würde MBR überhaupt funktionieren?
Zweitens: Wie schließe ich via Geli die 4 Platten zu einer zusammen und installiere dann auf dem Verbund einen ZFS-Pool?
Drittens: In der Fastfoot-Installationsroutine hat mir der Installer auf jede meiner 4 Platten eine /dev/gpt/gptboot* erstellt. Ist das wirklich notwendig? Es soll ja wirklich nur von der 1. Platte gebootet werden.
Viertens: Hat einer von euch evtl. ein Howto/Tutorial zu empfehlen, in welchem das Thema "N00b"-gerecht erklärt wird??^^

Danke, dass ihr euch die Zeit nehmt!

Gruß
 
Zudem gibt es ähnliche, und teils schwerwiegendere Probleme mit XTS (https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ ).

Ja super. Ich lese da nur, dass disk encryption nun mal ein scheiß Anwendungsfall ist und XTS ziemliches Gefrickel, was man sonst nicht haben will. Was ich nicht finde: wie man den Anwendungsfall besser behandelt.

Das heißt für mich trotzdem immer noch, dass es für FDE nichts besseres als XTS gibt, ergo ist es Unsinn, jemandem kein XTS zu empfehlen, wenn der gewünschte Anwendungsfall FDE ist.
 
Ja super. Ich lese da nur, dass disk encryption nun mal ein scheiß Anwendungsfall ist und XTS ziemliches Gefrickel, was man sonst nicht haben will. Was ich nicht finde: wie man den Anwendungsfall besser behandelt.

Zitat aus dem Artikel: CBC comes closer to a workable solution, but it too has problems: /* Aufzählung der Probleme */

Des weiteren sagt der Artikel aus, dass fast alle Probleme mit Authentication wegfallen -> etwas was FreeBSD Geli kann (-a HMAC/.....).

Das heißt für mich trotzdem immer noch, dass es für FDE nichts besseres als XTS gibt, ergo ist es Unsinn, jemandem kein XTS zu empfehlen, wenn der gewünschte Anwendungsfall FDE ist.

Ich habe nicht empfohlen, aufgrund von sicherheitstechnischen Bedenken kein XTS zu verwenden, sondern wegen der Performance. Bei mir (ohne AESNI) hat cbc immer um 300-400% besser performt. Ich halte in der Tat XTS sowie CBC beide für ausreichend sicher. Mit dem Artikel wollte ich nur verdeutlichen, dass auch XTS nicht das cryptografische Seelenheil bringt.
 
Zitat aus dem Artikel: CBC comes closer to a workable solution, but it too has problems: /* Aufzählung der Probleme */

Etwas Textverständnis würde dir guttun.

Consider the “big three” block cipher modes: the default (ECB), CBC, and CTR. All three could form the basis of an FDE system.
Dann fängt er an aufzuzählen. CBC ist "closer to a workable solution" einzig und allein in Bezug auf ECB. Von XTS ist an der Stelle noch gar keine Rede. Erst weiter unten dann

Enter “tweakable” ciphers.
 
Da ich die von @Yamagi empfolene Methode anwenden wollen würde, stelle ich mir zu Beginn die Frage: GPT oder MBR mit BSD Slices? Würde MBR überhaupt funktionieren?
Immer und grundsätzlich GPT, außer du hast einen sehr guten Grund noch MBR zu nutzen. GPT ist einfach flexibler und robuster. Mit MBR kannst du aber sowieso nicht von verschlüsselten Platten booten und ZFS ist damit auch mittelgroßes Gefummel. Also stellt sich die Frage nicht wirklich.

Zweitens: Wie schließe ich via Geli die 4 Platten zu einer zusammen und installiere dann auf dem Verbund einen ZFS-Pool?
Gar nicht. Du verschlüsselst die Platten mit dem gleichen Passwort. Dann musst du es nur einmal eingeben, er entschlüsselt alle Platten damit. Anschließend baust du auf den entschlüsselten Platten deinen Pool.

Drittens: In der Fastfoot-Installationsroutine hat mir der Installer auf jede meiner 4 Platten eine /dev/gpt/gptboot* erstellt. Ist das wirklich notwendig? Es soll ja wirklich nur von der 1. Platte gebootet werden.
Wirklich notwendig nicht. Aber mit Bootcode auf jeder Platte hast du den Vorteil, dass jede von ihnen in der Firmware als Bootdevice eingestellt sein kann.
 
Hallo zusammen,

ich habe heute erfolgreich, mit den o.g. Informationen, dem Wikibeitrag https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot und dem Lesen von /usr/libexec/bsdinstall/zfsboot, eine FreeBSD 13.0-RC3 Neuinstallation mit ZFS und GELI durchgeführt.
Das System wird im Dualbootmodus parallel mit Linux betrieben. Aus diesem Grund konnte ich den FreeBSD Installations Wizzard nicht für die Partitionierung verwenden, da für ZFS die ganze Platte/SSD benötigt wird. Als EFI Loader kommt rEFInd zum Einsatz. Anbei meine durchgeführten Schritte. Vielleicht sind sie ja für andere nützlich...

FreeBSD vom Installationsmedium starten und dann die Shell Mode Paritionierung verwenden

#Vorarbeit - alte/ungenutzte Partitionen löschen
gpart delete -3 ada0 gpart delete -2 ada0

#neue Partitionen anlegen (-a 1m habe ich aus dem zfsboot Skript übernommen)
gpart add -a 1m -s 2G -t freebsd-swap -l swap0 ada0 gpart add -a 1m -t freebsd-zfs -l zfs0 ada0

#GELI für ZFS einrichten
geli init -bg -e AES-XTS -l 256 -s 4096 /dev/gpt/zfs0 geli attach /dev/gpt/zfs0

#ZFS einrichten (habe ich mit zpool history auf einem anderen System ermittelt und nur Pool-/Devicenamen angepasst)
zpool create -o altroot=/mnt -O compress=lz4 -O atime=off -m none -f tank /dev/gpt/zfs0.eli zfs create -o mountpoint=none tank/ROOT zfs create -o mountpoint=/ tank/ROOT/default zfs create -o mountpoint=/tmp -o exec=on -o setuid=off tank/tmp zfs create -o mountpoint=/usr -o canmount=off tank/usr zfs create tank/usr/home zfs create -o setuid=off tank/usr/ports zfs create tank/usr/src zfs create -o mountpoint=/var -o canmount=off tank/var zfs create -o exec=off -o setuid=off tank/var/audit zfs create -o exec=off -o setuid=off tank/var/crash zfs create -o exec=off -o setuid=off tank/var/log zfs create -o atime=on tank/var/mail zfs create -o setuid=off tank/var/tmp zfs set mountpoint=/tank tank zpool set bootfs=tank/ROOT/default tank zfs set canmount=noauto tank/ROOT/default

#Link für /home anlegen
ln -s /usr/home /mnt/home chmod 1777 /mnt/var/tmp chmod 1777 /mnt/tmp

Per exit in den Installations Wizzard wechseln und die Installation und Konfiguration abschließen. Vor Abschluss der Installation, noch ZFS und GELI für den Loader aktivieren.

/etc/rc.conf zfs_enable="YES"

/boot/loader.conf geom_eli_load="YES" zfs_load="YES"

/etc/sysctl.conf vfs.zfs.min_auto_ashift=12

Den FreeBSD EFI Loader habe ich vom Installationsmedium kopiert und auf der EFI Partition, der HDD/SDD, unter EFI/freebsd ablegt. Anschließend wird FreeBSD als Option im rEFInd angezeigt.

Falls das System anschließend nicht neu startet (da man(n) vergessen, hat die /boot/loader.conf anzupassen :)), kann das Troubleshooting nach dem Start vom FreeBSD Installationsmedium wie folgt beginnen:

mount -rw / geli attach /dev/gpt/zfs0 zpool import tank zpool status zfs list mount -t zfs tank/ROOT/default /mnt

Die verschlüsselte swap Partion habe ich dann im laufenden System, wie im Handbuch unter https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/swap-encrypting.html beschrieben, konfiguriert.

Viele Grüße....
 
Zurück
Oben