Fórum Root.cz

Hlavní témata => Distribuce => Téma založeno: martinus26 16. 05. 2021, 11:44:22

Název: Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: 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.
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: k3dAR 16. 05. 2021, 15:41:55
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"
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: martinus26 16. 05. 2021, 20:00:11
vystup tree /boot posielam v prilozenom subore

lsblk vystup
Kód: [Vybrat]
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
Citace
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
Kód: [Vybrat]
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"





Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: k3dAR 16. 05. 2021, 23:14:12
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
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: k3dAR 16. 05. 2021, 23:37:13
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 :-)
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: martinus26 17. 05. 2021, 16:51:52
tu je vis efibootmgr -v
Kód: [Vybrat]
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 ?

Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: martinus26 22. 05. 2021, 19:30:15
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
Kód: [Vybrat]
sda2_crypt UUID=$(sudo blkid -s UUID -o value /dev/sda2) none luks
moj /etc/crypttab
Kód: [Vybrat]
ssd464crypt /dev/md/ssd464raid1 /etc/keys/crypto_keyfile_ssd464.key  luks
hdd3700crypt /dev/md/hdd3700raid1   /etc/keys/crypto_keyfile_hdd3700.key   luks
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: k3dAR 23. 05. 2021, 01:35:55
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 ;-)
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: martinus26 23. 05. 2021, 13:17:13
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.
Název: Re:Mint spustí zašifrovaný systém bez zadania hesla k disku
Přispěvatel: k3dAR 23. 05. 2021, 14:55:47
[...] 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

Kód: [Vybrat]
# 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...