Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: martinus26 16. 05. 2021, 11:44:22
-
Mal som 2 roky fungujúci Linux Mint 19.1 s fulll disc encryption podla tohoto návodu.
https://community.linuxmint.com/tutorial/view/2438 (https://community.linuxmint.com/tutorial/view/2438)
návod v pdf
https://drive.google.com/file/d/1s67TqFT0Nc4Ak9ABPE2m0jFRTj7toqWG/view (https://drive.google.com/file/d/1s67TqFT0Nc4Ak9ABPE2m0jFRTj7toqWG/view)
Po aktualizacii systému a reboote zostal systém zaseknutý na čiernej obrazovke Grub 2.04.
Vyriešil som to podla Appendix B z pdf návodu. Nabootoval Live USB, znovu vytvoril chybajuci /boot/efistub, grub-update, update-initramfs, zapisal na disk pomocou efibootmgr (staré záznamy vymazal).
Systém sa znova spustil.
Problém je že zašifrovaný dmcrypt systém (asi EFI STUB) sa sám od seba desifroval bez toho aby pýtal heslo od používatela.
Nevie mi niekto poradiť ako zabezpečiť aby systém znova pýtal heslo k desifrovaniu celého disku a hlavne sa nespustil sám bez hesla ?
Je to chyba mojej konfiguracie alebo je tam niekde riadna bezpečnostná diera ?
P.S. Všimol som si že na LIVE USB bol Grub 2.02, nainštalovaný bol 2.04. (aktualizoval sa aj grub ked sa system rozbil). Jadro 4.15.0-143-generic.
-
navod sem necetl, ale predpokladam ze je to klasika, sifrovanej /boot (oddelenej nebo soucast rootfs) a LUKS heslo si zadaval do Grub a aby se podruhe na LUKS neptal initramfs, tak si pripravil luks key_file a initramdisk (kterej byl na sifrovanem ulozisti a musel si nejdriv odemknout rucne v Grubu) pak odemknul podruhe sam...
a nejspis se ted z nejakeho duvodu nepta Grub, protoze vidi grub.cfg i kernel a initramfs na nesifrovanem EFI...
dodej vystup z "tree /boot" a "lsblk"
-
vystup tree /boot posielam v prilozenom subore
lsblk vystup
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3,7T 0 disk
└─sda1 8:1 0 3,7T 0 part
└─md126 9:126 0 3,7T 0 raid1
└─hdd3700crypt 253:5 0 3,7T 0 crypt
├─hdd3700vg-elektronika 253:6 0 150G 0 lvm /mnt/btrfs/elektronika
├─hdd3700vg-multimedia 253:7 0 1000G 0 lvm /mnt/btrfs/multimedia
├─hdd3700vg-archiv 253:8 0 300G 0 lvm
└─hdd3700vg-zaloha 253:9 0 500G 0 lvm /mnt/btrfs/zaloha
sdb 8:16 0 3,7T 0 disk
└─sdb1 8:17 0 3,7T 0 part
└─md126 9:126 0 3,7T 0 raid1
└─hdd3700crypt 253:5 0 3,7T 0 crypt
├─hdd3700vg-elektronika 253:6 0 150G 0 lvm /mnt/btrfs/elektronika
├─hdd3700vg-multimedia 253:7 0 1000G 0 lvm /mnt/btrfs/multimedia
├─hdd3700vg-archiv 253:8 0 300G 0 lvm
└─hdd3700vg-zaloha 253:9 0 500G 0 lvm /mnt/btrfs/zaloha
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 1G 0 part /boot/efi
└─nvme0n1p2 259:2 0 464G 0 part
└─md127 9:127 0 463,9G 0 raid1
└─ssd464crypt 253:0 0 463,9G 0 crypt
├─ssd464vg-root 253:1 0 75G 0 lvm /mnt/btrfs/root
├─ssd464vg-swap 253:2 0 16G 0 lvm [SWAP]
├─ssd464vg-home 253:3 0 100G 0 lvm /mnt/btrfs/home
└─ssd464vg-virtualpc 253:4 0 150G 0 lvm
nvme1n1 259:3 0 465,8G 0 disk
├─nvme1n1p1 259:4 0 1G 0 part
└─nvme1n1p2 259:5 0 464G 0 part
└─md127 9:127 0 463,9G 0 raid1
└─ssd464crypt 253:0 0 463,9G 0 crypt
├─ssd464vg-root 253:1 0 75G 0 lvm /mnt/btrfs/root
├─ssd464vg-swap 253:2 0 16G 0 lvm [SWAP]
├─ssd464vg-home 253:3 0 100G 0 lvm /mnt/btrfs/home
└─ssd464vg-virtualpc 253:4 0 150G 0 lvm
Na zaciatku toho návodu pre Full Disc encryption sa píse
In this new project I am abandoning the standard boot loader GRUB, replacing it with
the EFI STUB loader.
Pros:
SUPPORT FOR TYPE 2 LUKS ENCRYPTED PARTITIONS (LUKS2)
FULL DISK ENCRYPTION (FDE) REQUESTING ONLY ONE PASSWORD AT BOOT-UP
NO LUKS UNLOCK KEYFILES REQUIRED
Tak teraz neviem ci je problem v Grub alebo v EFI STUB
Posielam aj obsah /etc/default/grub
GRUB_DEFAULT=0
#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash cryptdevice=/dev/md/ssd464raid1:ssd464crypt nvidia-drm.modeset=0"
GRUB_CMDLINE_LINUX="amd_iommu=on iommu=pt swapaccount=1"
-
takze mas MDM RAID1 na 2x NVMe, nad tim LUKS, nad tim LVM, boot oddelenej neni.
EFI STUB nepouzivam, ale pokud se nepletu nijak s Grub (nic co ma v EFI, v grub.cfg ci /etc/default/grub) nemuze souviset, coz je i v te tve citaci ze Grub nahrazuje EFI "STUBem"...
i kdybys misto EFI STUB ted startoval GRUB, tak nevidim duvod proc by se na LUKS heslo nezeptal a zaroven OS nastartoval.
zkusim na ten navod teda kouknout, zatim co da vystup?: efibootmgr -v
-
navod sem prolitnul a prijde mi ze to dela rucne v podstate to same co dela automatizovane "sicherboot" kterej pouzivam, take vyuziva systemd-boot boot manager, take bali jadro a initramfs do 1 efi binarky kterou podepisuje klicem co ti vygeneruje, rozhrani vypada "stejne" jen z navodu dela polozky "last kernel" a "second last kernel", sicherboot dela normalne "os verze jadra" a nevim zda z navodu automaticky pri povyseni jadra ho vybere, se sicherboot ne a rucne vzdy pri startu prepnu na nove a zmacknu "d" pro nastaveni jako default...
nicmene trklo me tam "Appendix F" - automaticke odemknuti LUKS pres TPM modul, neni mozny ze jsi s tim nejak laboroval? protoze to z toho co si poslal a ja v navodu cetl je asi jedina moznost jak by se to mohlo odemykat samo :-)
-
tu je vis efibootmgr -v
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0005,0004,0003
Boot0000* Mint HD(1,GPT,400aa5ff-07eb-4571-9403-72fe62026f2b,0x800,0x200000)/File(\EFI\MINT\KERNEL.EFI)
Boot0003 Hard Drive BBS(HD,,0x0)..GO..NO........}.S.a.m.s.u.n.g. .S.S.D. .9.7.0. .P.R.O. .5.1.2.G.B....................A.......................................%8Z.........4..Gd-.;.A..MQ..L.S.4.6.3.N.F.0.K.A.3.4.2.0.4.V........BO..NO........q.S.a.m.s.u.n.g. .S.S.D. .9.7.0. .E.V.O. .5.0.0.G.B....................A...........................%8[..T......4..Gd-.;.A..MQ..L.S.4.6.6.N.X.0.K.B.5.1.5.8.5.E........BO..NO........u.W.D.C. .W.D.4.0.E.F.R.X.-.6.8.N.3.2.N.0....................A.................................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.7.C.3.K.N.H.E.6.U.6........BO..NO........u.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.C.F./.M.D.1...0.0....................A.........................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.S.M./.x.D.1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.S.D. .1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.M.S. .1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.S.D./.M.S.1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........u.S.T.4.0.0.0.V.N.0.0.8.-.2.D.R.1.6.6....................A.................................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .D.Z.5.H.D.2.7.3........BO
Boot0004* UEFI OS HD(1,GPT,eebe8210-3b89-4854-aef1-e391b25fd246,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0005* UEFI OS HD(1,GPT,400aa5ff-07eb-4571-9403-72fe62026f2b,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
TPM nepouživam ani som nič s TPM vedome nerobil. Ako zistit ci sa do TPM nejako nahodne neulozili kluce ?
-
Tak to vyzerá že ten návod na uplne šifrovanie disku sa vyvíja v priebehu času. Aktuálna verzia nepoužíva keyfiles. Ja ale mám keyfiles a aj cestu k nim v mojom /etc/crypttab
Je možné aby efi alebo grub nejakým sposobom precítali a ulozili si niekde tieto keyfiles a potom uz nepotrebovali heslo pocas startu systemu ?
Skúsim odstranit moje keyfiles z mojho crypttabu a znovu spustit update-initramfs, grub-update a znovu vytvorit efi.
/etc/crypttab z navodu pre FDE
sda2_crypt UUID=$(sudo blkid -s UUID -o value /dev/sda2) none luks
moj /etc/crypttab
ssd464crypt /dev/md/ssd464raid1 /etc/keys/crypto_keyfile_ssd464.key luks
hdd3700crypt /dev/md/hdd3700raid1 /etc/keys/crypto_keyfile_hdd3700.key luks
-
no to uz to vse vysvetluje a je to jak sem psal ;-) nejdirv si mel Grub v kterem si zadaval heslo a v initramdisku jsi mel keyfile aby se znovu/podruhe uz neptal ale tim keyfile odemnul sam, pak si presel misto Grubu na EFI Stub = kernel.efi = zabalene jadro+initramdisk(S KLICEM) a protoze je to v EFI tak se to samozrejme nepta na heslo pro pristup k tomu zabelenemu kernel.efi a ve chvili kdy tohle reseni se ma ptat na heslo = pri natazeni initramdisku, se to uz nepta kdyz v nem (a v crypttab uveden) je klic ;-)
jinak v crypptab co si citoval z navodu je samozrejme vhodneji, na druhe pozici mit uvedene UUID=uuid_toho_zarizeni, misto uvedene primo to zarizeni ktere se teoreticky muze za urcitejch okolnosti zmenit a pak by ti to nenajelo ;-)
-
Vyhodil som kluce z /ect/crypttab, vymazal stare efi aj kluce a nanovo prešiel celý návod.
Systém už pri štarte pýta heslo (toto som chcel).
Ešte je tu taká drobnosť. Pri zadávaní hesla nie je možné zapnúť NumLock. Po zapnutí PC keď sa objaví uvodna obrazovka UEFI Biosu, Numlock svieti (nastavené v Biose). Numlock potom zhasne a ked EFI vypyta heslo, nie je možne Numlock zapnúť.
Po zadaní hesla a spustení Linux Mintu už znova je možné zapnúť NumLock.
-
[...] Ešte je tu taká drobnosť. Pri zadávaní hesla nie je možné zapnúť NumLock [...]
zkus tento postup (https://superuser.com/a/1085795)
pokud se ti to zda slozite, tak strucne:
1. prvni skript (odstavec zacinajici "#! /bin/sh -e") vlozis do /etc/initramfs-tools/hooks/numlock
2. druhej skript (odstavec zacinajici "#!/bin/sh") vlozis do /etc/initramfs-tools/scripts/init-top/numlock
# nastavis oboum souborum opravneni
sudo chmod 0755 /etc/initramfs-tools/hooks/numlock /etc/initramfs-tools/scripts/init-top/numlock
# a pregenerujes initramdisk
sudo update-initramfs -u
tim zaridis ze v initramds je "hook" zapinajici numlock, kterej je pusten druhym skriptem pred dotazem na LUKS heslo...