[gel.]luks: 3 x falsches Passwort, System danach unbenutzbar

[debianoli]

Nach kurzem Überfliegen ... ohne eigene Boot-Partition für den Clone würd ich Chaos erwarten. Ansonsten gibst du ja nicht an, wie du den Clone genau angepasst hast.

Verstehe ich das richtig: Sobald ich in meinem Setting* eine weitere System-Partiton im LVM hinzufüge, muss diese immer eine eigene /boot Partition haben? Ein update-grub vom eigentlichen Hauptsystem reicht dann nie aus?

Ist das auch so, wenn das keine UEFI-Rechner ist? Ist bei LVM für jedes Linux-System auf einer LVM-Partition eine eigene /boot-Partition außerhalb der LVM-Partition zwingend nötig? Oder nur bei Verschlüsselung der Partition mit dem LVM?

*) Mein Setting: sda1 für /boot/efi, sda2 für /boot, sda3 als verschlüsselte Partition mit LVM

[NAB]

Ich hab grad überlegt, wo du das /boot des Clones denn lassen willst ...

1) In der einzigen Boot-Partition -> Die Grub-Konfiguration würde sich gegenseitig überschreiben und je nach Name auch die Kernel.

2) In der /-Partition des Clones -> Du könntest bei Crypto nie mit dessen Kernel booten.

Außerdem gab's da glaub ich wirklich die Macke, dass ein update-grub LVM-Partitionen übersieht ... da war mal was *grübel*

Ja, eine eigene Boot-Partition ist eindeutig der problemärmere Weg. Unabhängig von LVM/Crypto/UEFI.

[debianoli]

Danke für die Antwort, jetzt weiß ich, wo es damals vermutlich gehakt hat. Da bleibt meine Lösung mit / unverschlüsselt und /home im verschlüsselten Container ohne LVM doch die einfachere Lösung.

[dirk11]

Weiterhin ist ein "swap" bei einer LUKS-Verschlüsselung auch ziemlich sinnlos und macht dir Suspend-to-Disk kaputt.

Äh, nö. Ich habe hier auch ein verschlüsseltes swap, es geht ja darum, daß Daten bei inaktivem System nicht noch aus dem swap erlesen werden können, sprich wenn man die Platte ausbaut, von einem Live-System bearbeitet oder so etwas in der Art. Das ein suspend-to-disk dann im zwar verschlüsselten, aber geöffneten swap liegt, ist logisch, sonst könnte das nicht funktionieren.

[NAB]

dirk11, ich spach von der crypttab, nicht von der fstab ... werd ich gleich oben noch einfügen, damit das klarer ist.

[habakug]

Hallo!

Ich habe die eigentliche Ausgangssituation aus dem ersten Posting auch nochmal nachgestellt, also "/" unverschlüsselt, "/home" und swap verschlüsselt. Ich kann da erstmal Entwarnung geben, das von @debianoli bemerkte Verhalten ist zwar seltsam, führt aber nicht zu irgendwelchen Zerstörungen am Dateisystem oder anderswo. Gibt man das Passwort falsch ein, man hat dazu genau dreimal die Möglichkeit, verhält es sich wie von @debianoli beschrieben. In der Konsole poppt immer wieder ein "cryptsetup: lvm is not available" auf. Nach einigen Minuten (;-)) kann man jedoch mit einem "Strg-D" in die busybox [initramfs] kommen und sich dort umschauen. Mit einem weiteren "Strg-D" wird der Boot-Prozess fortgesetzt und man erhält sofort die Gelegenheit das Passwort wieder einzugeben. Ist es richtig wird auch sofort entschlüsselt und eingebunden. Ist es falsch passiert wieder dasselbe wie vorher, man kann irgendwann in die Busybox. Leider ist es (in diesem Fall) aber so, das jetzt nicht sofort fortgesetzt wird, sondern zunächst nach dem Passwort für die swap gefragt wird. Das Warten wird wieder einige Minuten dauern. Etwas seltsam ist, das auch bei Eingabe eines falschen Passwortes der Boot fortgesetzt wird und das swap erfolgreich eingebunden wird, man kann bei der Abfrage für das swap-Passwort auch einfach die Eingabetaste drücken. Das dreimalige Eingeben des falschen Passwortes ist wohl ein Sicherheitsfeature mit hohem Timeout, hier dauerte der Vorgang im Schnitt 15 Minuten.
Ich musste hier nach sehr vielen Versuchen aber nie irgendetwas "reparieren" oder hatte es mit sonstigen Seltsamkeiten zu tun. Das System liess sich immer wieder normal starten.

Gruss, habakug

[NAB]

Etwas seltsam ist, das auch bei Eingabe eines falschen Passwortes der Boot fortgesetzt wird und das swap erfolgreich eingebunden wird, man kann bei der Abfrage für das swap-Passwort auch einfach die Eingabetaste drücken.

Aus den Aussagen von debianoli und deinen Logs oben geht hervor, dass systemd-cryptsetup hier bereits den LUKS-Header zerstört hat und eine Plain-Entschlüsselung versucht. Das müsstest du eigentlich auf deinem Testsystem nachvollziehen können ... die Swap-Partition sollte sich mit LUKS nicht mehr öffnen lassen.

Darum reicht es auch, die Eingabetaste zu drücken ... der LUKS-Schutzmechanismus wurde zerstört.

Darüber müsste das initrd-cryptsetup dann beim nächsten Bootversuch eigentlich meckern ... ein luksOpen geht ja nicht mehr.

Ich musste hier nach sehr vielen Versuchen aber nie irgendetwas "reparieren" oder hatte es mit sonstigen Seltsamkeiten zu tun. Das System liess sich immer wieder normal starten.

Fragt sich nur, wie dein Swap nun verschlüsselt ist ... und ob überhaupt.

(Danke für's Nachstellen übrigens)

[debianoli]

Das dreimalige Eingeben des falschen Passwortes ist wohl ein Sicherheitsfeature mit hohem Timeout, hier dauerte der Vorgang im Schnitt 15 Minuten.
Ich musste hier nach sehr vielen Versuchen aber nie irgendetwas "reparieren" oder hatte es mit sonstigen Seltsamkeiten zu tun. Das System liess sich immer wieder normal starten.

Gruss, habakug

Gut, dann habe ich wohl nicht lange genug gewartet. Aber bei mir sah die Sache so aus:

1. Das Passwort wurde 3 x falsch eingegeben und Rechner ausgeschaltet

2. Beim Nächsten Hochfahren kommt keine Frage nach dem Passwort, sondern nur die Fehlermeldung " cryptsetup: lvm is not available"

3. Wenn man dann den Rechner lange genug stehen lässt, kommt die busybox. Das man aus der durch strg+d rauskommt, war mir nicht bekannt

Ich teste das jetzt nocheinmal, denn nach meiner Erinnerung hat ein Auskommentieren der Swap in fstab und crypttab nichts gebracht. Man musste grub wieder rekonfigurieren. Aber ich habe leider nicht jeden Schritt mitgeschrieben, als ich den Laptop wieder zum Laufen brachte. Sollte man eigentlich immer machen.

[NAB]

2. Beim Nächsten Hochfahren kommt keine Frage nach dem Passwort, sondern nur die Fehlermeldung " cryptsetup: lvm is not available"

So gar keine Frage? Nicht mal nach der sda2_crypt?

Ist eigentlich die Reihenfolge in der crypttab , die du hier:
viewtopic.php?f=37&t=160471#p1087392
angegeben hast, originalgetreu? Also erst sda2, dann sda3?

[debianoli]

Nein, da kommt keine Frage nach einem Passwort, sondern Zeile um Zeile "cryptsetup: lvm is not available"
Nach einiger Zeit dann die busybox, ohne ein gemountetes / mit dem unverschlüsselten sda1. Das ist dann für mich schwierig, denn mit den begrenzten Möglichkeiten der busybox kann ich nicht viel anfangen. Mit einem Live-System wie grml schon, damit kann ich eine Installation per chroot etc richten.

Die Anordnung der Partitionen in der crypttab ist genau so, wie ich es geschrieben habe: zuerst sda2, dann sda3

[NAB]

Merkwürdig. Wenn Systemd sda2_crypt heil gelassen hätte, hätte die initramdisk eigentlich erst das Passwort von sda2_crypt abfragen müssen, und dann sda3_crypt nicht finden müssen und dann dann erst per LVM danach suchen müssen. Warum sda2_crypt dann auch verschwunden war, verstehe ich immer noch nicht

[debianoli]

Ja, eigentlich sollte sich das dann so verhalten: Man gibt 3 x je Partition sein Passwort falsch ein und landet in der Bash des Recovery-Modus, also beim gemounteten /
Danach wird bei einem Neustart wieder das Passwort abgefragt.

Doch hier läuft was ganz schief. Könnte doch damit zusammenhängen, dass die UUID der Swap-Partition weg ist? Scheinbar fragt irgendein systemd-Dienst oder Grub alle Partitionen ab und vergleicht sie mit der im initamfs (vermute ich mal) gespeicherten Partitionen für den Boot-Prozeß. Wenn das dann nicht passt, läuft der Dienst Amok, sucht als hinterlegte Notlösung nach lvm und beendet dann den Boot-Prozeß, ohne die unverschlüsselte sda1 als / einzuhängen. Das ist schlecht, denn dann kann man das System mit Bordmitteln nicht ohne weiteres richten.

ich habe den Rechner leider nicht mehr da, sonst würde ich das Testen.

[habakug]

Hallo!

Ich habe es mit dem Debian-Installer getestet. Da liegt der Hund begraben, die händische Installation produziert ganz andere Fehler .
Zum Verständnis vorweg: Das ist schon LVM und zwar mit dm_mod/dm_crypt.

Code: Alles auswählen

# dmsetup ls --tree -o device
sda4_crypt (253:1)
 └─ (254:4)
sda3_crypt (253:0)
 └─ (254:3)
# dmsetup info sda3_crypt
Name:              sda3_crypt
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        2
Event number:      0
Major, minor:      253, 0
Number of targets: 1
UUID: CRYPT-LUKS1-6632fc63ba944b6aa1c8a50358b9593a-sda3_crypt
# cryptsetup status sda3_crypt
/dev/mapper/sda3_crypt is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda3
  offset:  4096 sectors
  size:    348160 sectors
  mode:    read/write
# blkid
/dev/sda1: UUID="5F51-B597" TYPE="vfat" PARTUUID="d928d038-2ee0-4bbe-8af2-0f7b2ac956e4"
/dev/sda2: UUID="0b7dd957-0b46-4765-8bf2-5d94ee0af7c4" TYPE="ext4" PARTUUID="aec133c9-788a-442a-bc40-ba628911ac8c"
/dev/sda4: UUID="56d9f3d4-e664-46d5-9d75-32f5448c860e" TYPE="crypto_LUKS" PARTUUID="82847aff-2f8f-4cea-8be9-d13a7f417e00"
/dev/mapper/sda3_crypt: UUID="6632fc63-ba94-4b6a-a1c8-a50358b9593a" TYPE="swap"
/dev/mapper/sda4_crypt: UUID="3d3da2ba-489c-4f10-9d6c-aeee6b5b5dcd" TYPE="ext4"
/dev/sda3: PARTUUID="8ce98027-59e7-4adb-9316-9aaac6d34d5d"

So werkelt der Installer, das ist während der Installation geloggt. Der Installer möchte gerne ein swap-Device mit luks verschlüsseln, wenn der "keytype" eine Passphrase oder "none" ist (siehe "packages/partman-crypto/finish.d/crypto_config").

Code: Alles auswählen

#!/bin/sh

# This script does the following:
# dm-crypt:  creates /etc/crypttab entries

. /lib/partman/lib/base.sh
[...]
        # Set basic options
        if [ $keytype = passphrase ]; then
                opts="luks"
[...]
     # Set key source
        if [ $keytype = random ]; then
                keyfile="/dev/urandom"
        elif [ $keytype = passphrase ]; then
                keyfile="none"
        elif [ -f $realdevdir/keyfile ]; then
                keyfile=$(cat $realdevdir/keyfile)
        else
                return 1
        fi
[...]
        if [ $method = swap ]; then
                opts="$opts,swap"
[...]
        # Use UUID for LUKS devices
        if cryptsetup isLuks "$source"; then
                local uuid=$(cryptsetup luksUUID "$source")
                source="UUID=$uuid"
        fi

        # Add entry to crypttab
        echo "$target $source $keyfile $opts" >> /target/etc/crypttab
[...]

Daraus entsteht folgende crypttab:

Code: Alles auswählen

sda3_crypt UUID=6632fc63-ba94-4b6a-a1c8-a50358b9593a none luks,swap
sda4_crypt UUID=3d3da2ba-489c-4f10-9d6c-aeee6b5b5dcd none luks

Dazu aus der "neuen" Manpage:

Code: Alles auswählen

       For swap encryption, /dev/urandom or the hardware device
       /dev/hw_random can be used as the password file; using /dev/random may
       prevent boot completion if the system does not have enough entropy to
       generate a truly random encryption key.

Der Installer kann ja nichts dafür, wenn man beim Verschlüsseln der swap-Partition vergisst im Menü das "Schlüssel: Passphrase" gegen "Schlüssel: Zufälliger Schlüssel" auszutauschen. Obwohl es, wie man jetzt weiss, keinen Sinn macht, legt der Installer es an "wie gewünscht". Doch ein Bedienungsfehler.
Die "richtig" erzeugte crypttab hat dann diese Einträge:

Code: Alles auswählen

sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap
[...]

Gelöst ist das für mich erst jetzt .

Gruss, habakug

[NAB]

Die "richtig" erzeugte crypttab hat dann diese Einträge:

Diese Zeile ist zwar richtig, in dem Sinne, dass sie Widerspruchsfrei ist, aber sie macht das Suspend-to-Disk kaputt. debianoli will ja LUKS.

Und nachdem wir oben gesehen haben, dass systemd-cryptsetup auf magische Weise auch LUKS-Container plain öffnet mit unbekanntem Passwort, würd ich so einer plain-Verschlüsselung von Systemd nicht mehr über den Weg trauen, so schlampig wie das programmiert ist.

[habakug]

Hallo!

Dann muss er sein /home und die swap in eine verschlüsselte Partition (lvm) packen, das kann dann mit einem Passwort zugleich entschlüsselt werden (pvcreate/vgcreate/lvcreate). Ich glaube der Installer bietet solche Dinge (noch) nicht an.

Gruss, habakug

[NAB]

"muss" ...naja ... ich würd den Installer die sda3_crypt erst mal erstellen lassen und sie dann gar nicht verwenden, und mir den Rest dann per Hand zurecht basteln ...

Doch, händisch partitioniert müsste der Installer das hinbekommen, wenn man ein LVM in _eine_ Crypt-Partition packt. LVM ist ja eh die Vorgabe, sobald man Crypt benutzt. Wenn man diesen Weg verlässt, sollte man gründlich prüfen, was der Installer angerichtet hat.