Dezvoltarea containerului LUKS în momentul inițializării sistemului

Bună ziua, bună seara! Acest post va fi util celor care folosesc criptarea datelor LUKS și doresc să decripteze discurile pe Linux (Debian, Ubuntu) în stadiul de decriptare a partției root. Și astfel de informații nu am reușit să găsesc pe internet.

Recent, cu creșterea numărului de discuri din rafturi, m-am confruntat cu problema decriptării discurilor folosind metoda bine cunoscută prin /etc/crypttab. Personal, evidențiez câteva probleme legate de utilizarea acestei metode, și anume, că fișierul este citit doar după încărcarea (mount) a partției root, ceea ce afectează negativ importul ZFS, în special dacă acestea au fost create din partiții pe un dispozitiv *_crypt, sau din raid-uri mdadm, create de asemenea din partiții. Știm cu toții că se poate utiliza parted pe containere LUKS? Și există și problema pornirii timpurii a altor servicii, când array-urile nu sunt încă disponibile, dar folosi deja este necesar ceva (lucrez cu Proxmox VE 5.x clustering și ZFS peste iSCSI).

Puțin despre ZFS over iSCSIiSCSI funcționează pentru mine prin LIO, iar când se inițiază iscsi-target-ul și nu vede dispozitivele ZVOL, pur și simplu le șterge din configurație, ceea ce nu permite sistemelor gazdă să pornească. De aici apare fie restaurarea fișierului de backup json, fie adăugarea manuală a dispozitivelor cu identificatorii fiecărei VM, ceea ce este pur și simplu groaznic, când există zeci de mașini și în configurația fiecărei mai mult de 1 disc.

Și a doua întrebare pe care o voi analiza este cu ce lucru pentru a decripta (acesta este momentul cheie al articolului). Și despre aceasta vom discuta mai jos, intrați în detalii!

Cel mai adesea, pe internet se folosește un fișier cheie (bineînțeles, adăugat mai înainte în slot cu comanda — cryptsetup luksAddKey), sau în cazuri rare (informațiile în limba română sunt foarte limitate) — scriptul decrypt_derived, care se află în /lib/cryptsetup/script/ (desigur, există și alte metode, dar eu am utilizat exact aceste două, care au stat la baza articolului). De asemenea, am vizat o activare complet autonomă după reporniri, fără comenzi suplimentare în consolă, astfel încât totul să „decoleze” imediat. De aceea, de ce să așteptăm? —

Să începem!

Presupunem un sistem, de exemplu Debian, instalat pe partția criptată sda3_crypt și o duzină de discuri pregătite pentru criptare și crearea a ceea ce ne dorim. Avem o frază cheie (passphrase) pentru deblocarea sda3_crypt și de pe această partție vom extrage „hash”-ul parolei de pe sistemul pornit (decriptat) și îl vom adăuga pe celelalte discuri. Totul este simplu, în consolă executăm:

/lib/cryptsetup/scripts/decrypt_derived sda3_crypt | cryptsetup luksFormat /dev/sdX

unde X este discurile, partițiile etc.

După criptarea discurilor cu „hash”-ul de la fraza noastră cheie, trebuie să aflăm UUID sau ID — depinde de preferințe. Luăm datele din /dev/disk/by-uuid și by-id respectiv.

Următorul pas este pregătirea fișierelor și mini-scripturilor pentru funcțiile necesare, să începem:

cp -p /usr/share/initramfs-tools/hooks/cryptroot /etc/initramfs-tools/hooks/
cp -p /usr/share/initramfs-tools/scripts/local-top/cryptroot /etc/initramfs-tools/scripts/local-top/

apoi

touch /etc/initramfs-tools/hooks/decrypt && chmod +x /etc/initramfs-tools/hooks/decrypt

Conținutul ../decrypt

#!/bin/sh

cp -p /lib/cryptsetup/scripts/decrypt_derived "$DESTDIR/bin/decrypt_derived"

apoi

touch /etc/initramfs-tools/hooks/partcopy && chmod +x /etc/initramfs-tools/hooks/partcopy

Conținutul ../partcopy

#!/bin/sh

cp -p /sbin/partprobe "$DESTDIR/bin/partprobe"
cp -p /lib/x86_64-linux-gnu/libparted.so.2 "$DESTDIR/lib/x86_64-linux-gnu/libparted.so.2"
cp -p /lib/x86_64-linux-gnu/libreadline.so.7 "$DESTDIR/lib/x86_64-linux-gnu/libreadline.so.7"

încă puțin

touch /etc/initramfs-tools/scripts/local-bottom/partprobe && chmod +x /etc/initramfs-tools/scripts/local-bottom/partprobe

Conținutul ../partprobe

#!/bin/sh

$DESTDIR/bin/partprobe

și în final, înainte de update-initramfs, trebuie să edităm fișierul /etc/initramfs-tools/scripts/local-top/cryptroot, începând de la linia ~360, fragment de cod mai jos

Original

                # decrease $count by 1, apparently last try was successful.
                count=$(( $count - 1 ))
                
                message "cryptsetup ($crypttarget): set up successfully"
                break

și îl transformăm într-o formă similară

Editat

                # decrease $count by 1, apparently last try was successful.
                count=$(( $count - 1 ))
                

                /bin/decrypt_derived $crypttarget | cryptsetup luksOpen /dev/disk/by-uuid/ *CRYPT_MAP*
                /bin/decrypt_derived $crypttarget | cryptsetup luksOpen /dev/disk/by-id/ *CRYPT_MAP*

                message "cryptsetup ($crypttarget): set up successfully"
                break

Rețineți că aici se poate folosi fie UUID, fie ID. Cel mai important este ca driverele necesare pentru dispozitivele HDD/SSD să fie incluse în /etc/initramfs-tools/modules. Pentru a afla driverul utilizat, se poate folosi comanda udevadm info -a -n /dev/sdX | egrep ‘looking|DRIVER’.

Acum, când am terminat și toate fișierele sunt la locul lor, pornim update-initramfs -u -k all -v, în logare nu ar trebui să existe erori în execuția scripturilor noastre. Facem o repornire, introducem fraza cheie și așteptăm puțin, în funcție de numărul discurilor. Ulterior, sistemul se va porni și în etapa finală de boot, adică după „mounting”-ul partției root, va fi executată comanda partprobe — aceasta va găsi și va atașa toate partițiile create pe dispozitivele LUKS și orice array-uri, fie ele ZFS sau mdadm, se vor forma fără probleme! Și toate acestea înainte de a porni serviciile și procesele principale care necesită aceste discuri/array-uri.

update1: Cum am observat AEP, această metodă funcționează doar pentru LUKS1.

Sursa: habr.com