Geli-Entschlüsselung mit zweitem Keyslot geht nicht

Krull

Well-Known Member
Hallo,

ich habe einen mit Geli verschlüsselten ZFS-Rootpool. In den zweiten Keyslot habe ich jetzt eine weitere Passphrase gesteckt. Beim Booten funktioniert die aber nicht. Nur die, die im ersten Keyslot steckt wird akzeptiert. Wenn ich allerdings von einer "Live-CD" boote und dann den Geli container aufmache, klappt es auch mit der zweiten Passphrase.

Versteht das jemand? Muss das so sein?
 
Nein, daran liegt es wahrscheinlich nicht. Die Phrase habe ich zum Testen relativ kurz gewählt. Sie besteht nur aus Buchstaben, ohne y, z oder Umlauten.
 
So, Das Problem stellt sich doch ein wenig anders dar. Die Passphrasen funktionieren prinzipiell, allerdings ist der Bootvorgang nach dem Wechsel einer Passphrase gestört.
Im Moment sieht die Sache bei mir so aus (es ist übrigens ein ZFS stripe):
- Vor dem Bootpromt werde ich nach einer Passphrase gefragt
- Bootpromt kommt sofort und FreeBSD bootet
- seit dem Passphrasenwechsel werde ich jetzt nochmal gefragt, und zwar jeweils für ada0 und ada1
- gebe ich die Phrase richtig ein, werde ich dennoch je drei mal gefragt. Dann allerdings wird weiter gebootet und ich kann mich einloggen.
- drücke ich die Passwortfragen nur mit Return weg, werde ich nach dem dritten Mal zum entschlüsseln von gpt/zfs0 bzw. gpt/zfs1 aufgefordert. Hier muss die Phrase richtig eingegeben werden, sonst geht's nicht mehr weiter.

Dieser Zustand ist ziemlich nervig und unlogisch obendrein. Ich habe hier zwar CURRENT, erinnere mich aber, dass ich vor länger Zeit schon mal ein sehr ähnliches, wenn nicht sogar dasselbe Problem mit einem STABLE oder RELEASE hatte und dann den ganzen Klump frusriert in die Ecke geworfen und wieder Linux verwendet habe. Jetzt weiß ich immerhin, dass man zumindest grundsätzlich ein GELI-Passwort ändern kann. Nur eben auf eine sehr unschöne Weise.

Im Moment verstehe ich die Sache so, dass mansein GELI-Passwort nur zum Preis eines sauberen Bootvorgangs ändern darf. Muss das so sein? Habe ich in der Doku irgendwas übersehen, einen Refresh vielleicht an irgendeiner Stelle?
 
GELI ist etwas komisch stellenweise und gar nicht so leicht zu verstehen was da genau passiert. Ich bin selbst kein GELI-Guru, musste mich aber mal für die Einrichtung meines NAS eingehender damit befassen. Was ich vermute was bei dir passiert, ist, dass der Boot Loader das Passwort nicht korrekt an den Kernel weiter gibt. Beim GELI-Root-on-ZFS kann ja seit einiger Zeit der gptzfs-Loader direkt von einem GELI-Pool booten. Das wird der erste Prompt sein, bei dem du das Passwort eingibst. Der schaltet das Root zimindest soweit frei, dass der eigentliche Boot Loader (der mit dem Menü) geladen werden kann. Und hier gibt es wohl das Problem, dass dieser Boot Loader nicht weiß welches Passwort du verwendet hast. Wenn dann der Kernel startet findet der zwei GELI Keys hat aber keine genaue Info wie das Passwort zu verwenden ist, wenn denn überhaupt eins übergeben wurde. Probier daher mal in der loader.conf geom_eli_passphrase_prompt="YES" mit anzugeben. Dann fragt der Menü Boot Loader zwar ebenfalls nach dem Passwort, welches dann hoffentlich dem Kernel erlaubt den zum Passwort jeweils passenden Key zu finden und den Pool ohne weitere Abfragen freizuschalten.

Soweit ich das im Handbuch verstanden habe ist es auch so an sich (vom Design her) glaube gar nicht vorgesehen den Root Pool mit zwei Keys/Passwörtern zu versehen. Sondern eher so gedacht dass "normale" Anwender Zugriff auf einen vom Root separaten Datenpool erhalten können ohne das "Masterpasswort" zu kennen.
 
Die loader.conf war jedenfalls schon mal die richtige Richtung. Allerdings war dort schon geom_eli_passphrase_prompt auf YES gesetzt. Dieser ganze Krempel stand da drin:
Code:
geli_ada0p5_keyfile0_load="YES"
geli_ada0p5_keyfile0_type="ada0p5:geli_keyfile0"
geli_ada0p5_keyfile0_name="/boot/encryption.key"
geli_ada1p5_keyfile0_load="YES"
geli_ada1p5_keyfile0_type="ada1p5:geli_keyfile0"
geli_ada1p5_keyfile0_name="/boot/encryption.key"
geom_eli_load="YES"
geom_eli_passphrase_prompt="YES"

Das Problem hat sich aufgelöst, als ich geli_ada[01]p5_keyfile0_load auf NO gestellt habe. Die neuen Passphrasen habe ich nämlich ohne Keyfile erstellt. Kann jemand sagen, welchen Zweck diese Keyfiles überhaupt haben sollen? Wenn man ganz ohne Passwort arbeiten möchte, ok. Aber zusätzlich zu einem (starken) Passwort? Dient das Ding dann als Salt?
 
Ahhh, das dachte ich mir schon fast, war mir aber nicht ganz sicher.

Die Key File ist eigentlich nur dafür da, wenn man kein Passwort nutzen möchte. Nun legt der 11er FreeBSD Installer immer eine mit einem Passwort geschützte Key File an. Warum weiß ich nicht. Das eigentliche Problem bei dem Ganzen ist aber, dass beide Master Keys sich den Iterationszähler teilen. Den bekommt man mit geli info (oder so) angezeigt und legt fest, wie oft die Passphrase durch den Hash-Algo geschickt wird. Konfiguriert man nun einen Master Key mit einem Key File und ohne Passphrase wird der Zähler auf Null gesetzt. Das Problem ist erkennbar, oder? Da sich der Iterationszähler geändert hat, passt die Passphrase (die wird ja jetzt statt xxx mal eben 0 mal gehasht) zum jeweils anderen Master Key nicht mehr. Man muss also vorher schon ein wenig überlegen, sonst sind mal ganz schnell die Keys hinüber und man hat eine tolle Eingabemenge Entropie (d.h. Datenmüll).

Aus sicherheitstechnischer Sicht ist es schon ratsam eine Key File zusätzlich mit einem Passwort zu sichern. Denn hat man die Key File (woher auch immer) kann man den GELI-Container ohne weiteres öffnen. Ein Passwort kann man hingegen so weiteres mal nicht kopieren, so wie eine Datei.

Damit das Ganze nur mit Passwörtern funktioniert muss man beide Master Keys für jeden GELI-Container ohne Key File konfigurieren und die Key File-Einträge in loader.conf löschen bzw. ausklammern. Sobald einer ein Key File hat, wird das eben im Loader mit geladen, und dann passt nur noch das Passwort mit dem die jeweilige Key File "gesichert" wurde.
 
Zurück
Oben