schreibgeschützte LUKS-Partition neu auf Lese-/Schreibzugriff umstellen

schreibgeschützte LUKS-Partition neu auf Lese-/Schreibzugriff umstellen

cryptsetup kann mit der Option --readonlyoder aufgerufen werden -r, wodurch eine schreibgeschützte Zuordnung eingerichtet wird:

cryptsetup --readonly luksOpen /dev/sdb1 sdb1

Wenn ich ein Gerät schreibgeschützt geöffnet habe, kann ich es dann später auf Lese-/Schreibzugriff umstellen? Offensichtlich meine ich damit, es schreibgeschützt zu machen, ohne es vorher zu schließen und es dann erneut zu öffnen. Kann ich es umstellen, ohne mein Passwort erneut eingeben zu müssen?

Wenn dies nicht möglich ist, liegt es einfach daran, dass Cryptsetup dies nicht unterstützt, oder gibt es eine grundlegendere Ebene?

Antwort1

cryptsetupMit dem Befehl scheint das nicht möglich zu sein . cryptsetupHat leider ein paar solcher unveränderlichen Flags... --allow-discardsist auch eines davon. Wenn dies beim Öffnen des Containers nicht gesetzt war, kannst du es nachträglich nicht hinzufügen.

Zumindest nicht mit dem cryptsetupBefehl. Da jedoch cryptsetupreguläre Device Mapper-Ziele erstellt werden, können Sie auf zurückgreifen, dmsetupum sie zu ändern. Dies ist natürlich aus verschiedenen Gründen nicht zu empfehlen: Es ist, als würden Sie die Partitionstabelle der verwendeten Partitionen ändern – wenn Sie es vermasseln, verlieren Sie möglicherweise alle Ihre Daten.

Der Gerätemapper ermöglicht die dynamische Neuzuordnung aller Geräte zur Laufzeit und kümmert sich dabei überhaupt nicht um die Sicherheit Ihrer Daten. Aus diesem Grund wird diese Funktion normalerweise hinter der LVM-Schicht verborgen, die die notwendigen Metadaten zur Gewährleistung der Sicherheit aufbewahrt.

Erstellen Sie ein schreibgeschütztes LUKS-Gerät:

# truncate -s 100M foobar.img
# cryptsetup luksFormat foobar.img
# cryptsetup luksOpen --read-only foobar.img foobar

Der Weg dmsetupsieht es so:

# dmsetup info foobar
Name:              foobar
State:             ACTIVE (READ-ONLY)
Read Ahead:        256
Tables present:    LIVE
[...]
# dmsetup table --showkeys foobar
0 200704 crypt aes-xts-plain64 ef434503c1874d65d33b1c23a088bdbbf52cb76c7f7771a23ce475f8823f47df 0 7:0 4096

Beachten Sie den Hauptschlüssel, der normalerweise nicht weitergegeben werden sollte, da er den Brute-Force-Schutz von LUKS unterbricht. Leider habe ich keinen Weg gefunden, ihn nicht zu verwenden, da dmsetupauch eine direkte --make-this-read-writeOption fehlt. dmsetup reloadEr ermöglicht jedoch das vollständige Ersetzen einer Zuordnung, daher ersetzen wir sie im Lese-/Schreibmodus durch sich selbst.

# dmsetup table --showkeys foobar | dmsetup reload foobar
# dmsetup info foobar
Name:              foobar
State:             ACTIVE (READ-ONLY)
Read Ahead:        256
Tables present:    LIVE & INACTIVE

Nach dem Neuladen ist es immer noch schreibgeschützt, da beim Neuladen die inaktive Tabelle geladen wird.

Um die inaktive Tabelle zu aktivieren, verwenden Sie dmsetup resume:

# dmsetup resume foobar
# dmsetup info foobar
Name:              foobar
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE

Und somit haben wir ein LUKS-Gerät mit Lese-/Schreibzugriff.

Funktioniert es mit einem Live-Dateisystem?

# cryptsetup luksOpen --readonly foobar.img foobar
# mount /dev/mapper/foobar /mnt/foobar
mount: /mnt/foobar: WARNING: device write-protected, mounted read-only.
# mount -o remount,rw /mnt/foobar
mount: /mnt/foobar: cannot remount /dev/mapper/foobar read-write, is write-protected.

Es ist also schreibgeschützt. Machen Sie es schreibgeschützt und mounten Sie es erneut:

# dmsetup table --showkeys foobar | dmsetup reload foobar
# dmsetup resume foobar
# mount -o remount,rw /mnt/foobar
# echo hey it works > /mnt/foobar/amazing.txt

Können wir zum schreibgeschützten Modus zurückkehren?

# mount -o remount,ro /mnt/foobar
# dmsetup table --showkeys foobar | dmsetup reload foobar --readonly
# dmsetup resume foobar
# mount -o remount,rw /mnt/foobar
mount: /mnt/foobar: cannot remount /dev/mapper/foobar read-write, is write-protected.

Es funktioniert also wahrscheinlich. Der Vorgang zum Hinzufügen eines allow_discardsFlags zu einer vorhandenen Crypt-Zuordnung ist ähnlich – Sie müssen mit einer Tabelle neu laden, die dieses Flag enthält. Ein Dateisystem, das das Fehlen der Discard-Unterstützung bereits erkannt hat, lässt sich jedoch möglicherweise nicht davon überzeugen, dies sofort erneut zu erkennen. Es ist also unklar, wie praktisch es ist.


Wenn Sie jedoch keine guten Gründe haben, dies nicht zu tun, sollten Sie beim erneuten Öffnen mit regulären cryptsetupBefehlen bleiben, selbst wenn dies bedeutet, dass Sie die Verbindung trennen und die Passphrase erneut eingeben müssen. Dies ist rundum sicherer und, was noch wichtiger ist, es umgeht nicht das LUKS-Sicherheitskonzept.

Antwort2

Es ist nicht möglich, nach dem Öffnen des Datenträgers von schreibgeschützt auf Lese-/Schreibzugriff umzustellen. Ich sehe im Cryptsetup-Quellcode keine Optionen dafür.

verwandte Informationen