LuKS encrypted /boot, Frage root decrypt

[realmuelli]

Hallo zusammen,

ich habe einige Server mit verschlüsselter /boot Parition (Debian 11) und verschlüsselter / Partition, bei der ich nur einmal den Passphrase eingebe um /boot zu entschlüsseln in in Grub2 und das wars dann.

Grundsätzlich läuft es so:
- Grub2 fragt mich direkt beim Boot nach dem Passphrase für die Bootpartition
-> /boot wird unlocked
- In der Initrd ist ein keyfile für die Rootpartition, crypttab sagt dann, dass dies in key-slot=1 liegt und so wird dann / gemounted
-> weitere Bootprozess

Das tut alles wie gesagt wunderbar in Debian 11, nur 1x Passworteingabe.

Jetzt habe ich hier ein Debian 12 fertig gemacht und habe das dort auch umgesetzt, allerdings erlebe ich da ein merkwürdiges Phänomen.
Beim Booten werde ich von Grub2 nach der Passphrase für die Bootparition gefragt, soweit normal, aber direkt danach werde ich nochmal nach der Passphrase für die Rootpartiion gefragt.
Zuerst dachte ich, ich hätte das Keyfile vergessen oder versehentlich den falschen Key-Slot angegeben oder eine UUID wär falsch etc, aber ne, da stimmt alles.

Hat jemand eine idee, ob sich in da in Debian 12 irgendwas geändert hat? Stehe hier grade auf dem Schlauch. Ist zwar nur eine kleine Unpässlichkeit mit der doppelten Passphrase eingabe, aber ich würde gerne das "wieso" verstehen.

Danke für irgendeinen Hinweis!

[juhuu]

Interessanter Inhalt:
etwa seit Release von Ubuntu 22.04 verschlüssele ich alle Datenträger eines PC. Mittlerweile sind es mehrere Debian 12-PC.
Dafür nutze ich ausschliesslich die Installationsprogramme der Distribution. Diese bieten die Verschlüsselung an.
Mit einem keyfile für LUKS kam ich dabei noch nie in Berührung.
Es genügt die einmalige Eingabe des LUKS-Schlüssels.

Habe "meine" grub.cfg-Datei angeschaut. Nirgendwo ein Hinweis auf LUKS oder cryptomount. Ich bin sicher, dass zumindest hier GRUB mit LUKS nichts zu tun hat.
ABER: siehe auch https://cryptsetup-team.pages.debian.ne ... -boot.html
Dort wird etwas beschrieben, was zu Deiner Schilderung besser passt.

Frage 1:
Ist dieser/Dein Aufwand gerechtfertigt? Der verlinkte Text weist auf Coreboot und OS im ROM hin

Frage 2:
Was riskiere ich mit einer unverschlüsselten /boot-Partition?

SERVER:
die Massenspeicher der Server habe ich ohne den Installer eingerichtet. Für das autom. Mount nutze ich dann ein keyfile.
Somit einmalige Passworteingabe für den Serverstart.
Dabei hat sich dropbear unter Debian 12 bewährt, während es mit Ubuntu-Server 22.04 wiederholt versagte.
Das und das Ubuntu-"Programm" für Expanded Security Maintenance (ESM) haben mich zum Umstieg auf Debian bewogen. Bisher bin ich hochzufrieden!

[MSfree]

Was riskiere ich mit einer unverschlüsselten /boot-Partition?

In der Boot-Partition stehen neben Grub noch der Kernel und die initial RAM-Disk (initrd). Theoretisch könnte ein Angreifer die RAM-Disk manipulieren, um dort ein Root-Kit oder ähnliche Schadsoftware einzubauen. Derartige Software würde den Bootprozeß überleben und nach dem Öffnen der LUKS-Container vollen und entschlüsselten Zugriff suf die HDD/SSD haben.

[cosinus]

In der Boot-Partition stehen neben Grub noch der Kernel und die initial RAM-Disk (initrd). Theoretisch könnte ein Angreifer die RAM-Disk manipulieren,

Selbst wenn /boot verschlüsselt ist - /boot/efi kann niemals verschlüsselt sein. Man würde da also auch mit verschlüsseltem /boot eine kleine Angriffsfläche offen lassen.

Was ist denn mit der Alternative Diskpassword, welches man im BIOS setzt oder mit hdparm? Dann kann von der Platte nur gelesen werden, wenn sie mit diesem Passwort entsperrt wurde. Dann wäre auch nicht unbedingt LUKS notwendig.
So mach ich das bei meinem Surfnotebook...wenn es geklaut wird, können die mit der internen SSD nichts anfangen, das reicht mir.

[MSfree]

Was ist denn mit der Alternative Diskpassword

Ich persönlich halte davon gar nichts.

Einerseits habe ich hier einen Haufen Hardware rumliegen, u.a. mindestens 20 Festplatte. Wenn die alle passwortgeschützt wären, müßte ich darüber irgendwie Buch führen, um nicht die eine oder andere Platte durch Vergesslichkeit zum Briebeschwerer werden zu lassen.

Andererseits halte ich so eine Sperre, die sich nur in Form von Firmware auf dem Controller der Platte/SSD manifestiert, für inherent unsicher. Verschlüsselung ist schon eine ganz andere Nummer als eine Festplattezugangssperre.

[hikaru]

Hat jemand eine idee, ob sich in da in Debian 12 irgendwas geändert hat?

Grub hatte früher nur Support für luks1. luks2 wurde erst mit Grub 2.06 eingeführt (und auch das nur teilweise).
Daher musste bis einschließlich Bullseye eine luks-verschlüsselte /boot-Partition in luks1 verschlüsselt werden, während man ansonsten aus Sicherheitsgründen eher zu luks2 greift.
Seit Bookworm könnte man auch /boot luks2-verschlüsseln, wenn man ein paar Rahmenbedingungen zwecks Grub-Kompatibilität beachtet. Ob das bei deinem System der Fall ist, und warum das zum beobachteten Effekt der doppelten Schlüsseleingabe führt, weiß ich nicht. Aber es könnte im Rahmen eines Nebeneffekts ein Erklärungsansatz sein.

etwa seit Release von Ubuntu 22.04 verschlüssele ich alle Datenträger eines PC. Mittlerweile sind es mehrere Debian 12-PC.
Dafür nutze ich ausschliesslich die Installationsprogramme der Distribution. Diese bieten die Verschlüsselung an.
Mit einem keyfile für LUKS kam ich dabei noch nie in Berührung.
Es genügt die einmalige Eingabe des LUKS-Schlüssels.

Nun, irgendwo müssen die Schlüssel für andere Dateisysteme hinterlegt sein, wenn du nur einmal ein Passwort eingibst.

Habe "meine" grub.cfg-Datei angeschaut. Nirgendwo ein Hinweis auf LUKS oder cryptomount. Ich bin sicher, dass zumindest hier GRUB mit LUKS nichts zu tun hat.

Dann ist dein /boot vermutlich nicht verschlüsselt. Ich meine mich dunkel zu erinnern, dass dies das Standardverhalten des Installers (sowohl Debian, als auch Ubuntu) ist, wenn man Verschlüsselung wählt.

So richtig tief stecke ich in der Materie allerdings nicht drin. Ich setze meine Systeme ohne Installer mit debootstrap auf, und erzeuge vorher händisch luks-Volumes und bei Bedarf Softraids. (lvm spare ich mir dabei, denn um auch noch das im Kopf zu behalten, fehlt mir mindestens eine Gehirnwindung.)

[cosinus]

Andererseits halte ich so eine Sperre, die sich nur in Form von Firmware auf dem Controller der Platte/SSD manifestiert, für inherent unsicher. Verschlüsselung ist schon eine ganz andere Nummer als eine Festplattezugangssperre.

Inhärent? Man kann dieses Passwort nicht mal eben so umgehen. Und Geheimdienste werden's ja auch nicht auf deine internen Disks abgesehen haben.
Ich hab dieses Diskpasswort als Alternative genannt, eben damit man keine Verrenkungen beim verschlüsselten /boot braucht.

Ich finde diese Diskussion auch immer wieder müßig, immer wieder wird erzählt, dass bei einem unverschlüsselten /boot ja sofort irgendwelche Supercracker drauf anspringen und dort via Live-System oder wie auch immer dann da rootkits reinpflanzen.

Jedenfalls muss man sich dann entscheiden. Entweder unverschlüsseltes /boot und die unglaubliche hohe Gefahr, Opfer eines Supercrackers zu werden, da mal im Handumdrehen rootkits nach /boot reinbastelt oder man macht es kurz und schmerzlos mit einem Diskpasswort.

Einerseits habe ich hier einen Haufen Hardware rumliegen, u.a. mindestens 20 Festplatte. Wenn die alle passwortgeschützt wären, müßte ich darüber irgendwie Buch führen, um nicht die eine oder andere Platte durch Vergesslichkeit zum Briebeschwerer werden zu lassen.

Du musst ja auch nicht alle Platten mit so einem Passwort absichern. Es ging um die Platten, auf dem man ein OS hat. Und andererseits musst du bei den heutigen Kontenzwang eh alles dokumentieren. Wozu gibt es KeePass? Oder nimmst du online für alles ein Passwort? Bei LUKS auch überall und ein dieselbe Passphrase? Das nicht richtig dokumentieren zu "können" klingt eher nach Faulheit als nach einem Argument.