Vlákno názorů k článku
GRUB obsahuje chybu BootHole, která dovoluje obejít Secure Boot od ptrj - Ako je na tom ked mam encryptovany /boot...

Ako je na tom ked mam encryptovany /boot ?
Je to viac secure alternativa ?

| EFI | LUKS1 /boot | LUKS2 LVM (root&swap) |

Admin password do BIOSu na Dell strojoch zamedzia boot s USB. Mozno idelany by bol aj BIOS Disk password, ale ten pre NVME disky zatial nieje mozny..

1. 8. 2020, 22:22 editováno autorem komentáře

s /boot na LUKS utocnik muze nahradit Grub EFI binarku (kterou zajistujes odemceni LUKS) za vlastni s keylogerem a odchytit tve LUKS heslo...

vhodnejsi je pouzit misto Grub zavadec sicherboot, s tim ze v EFI smazes vychozi (=Microsofti) klice, pres sicherboot vygenerujes vlastni, pres jeho KeyTool naimportujes tyto sve klice do EFI, sicherboot pak pri kazde instalaci/aktu­alizaci jadra a/nebo initramdisku vygeneruje "svou" EFI binarku obsahujici jadro+initramdisk a podepise je tvejma klicema... (+ to zminene heslo do biosu)

tedy utocnik sice ma pristup k tvemu "zabalenemu" (do EFI formatu) initramdisku kterej zajistuje odemceni LUKS na /boot, nicmene tim ze mas s SecureBoot+Vlas­tniKlice zamezen start cehokoliv jineho nez tebou podepsaneho, utocnik to nema jak kompromitovat...

EDIT: k "nema jak kompromitovat" mysleno normalni cestou, stale ale muze udelat to ze zrusi tve heslo do biosu, vypne secure boot (nebo obnovi MS klice ci da sve vlastni), prida zavadec s keylogerem... k tomu by potreboval stroj rozebrat a odpajet zalozni baterku a/nebo preprogramuje eeprom...

2. 8. 2020, 23:30 editováno autorem komentáře

A nestacilo by len po starte skontrolovat checksum grubx86.efi a v pripadne ked sa nieco zmeni, tak viem ze som kompromitovany a potom nasledne konat.. menit vsetky LUKS hesla/kluce a znovu nainstalovat GRUB atd. ?

Myslim si ze fyzicky utok na notebook je utok z najmensim percentom. Ked mi ho ukradnu, tak sa k datam nedostanu iba ze by ukradli aj mna a nejaky "Boris" by to uz somna vytlkol ale to by uz bolo asi jedno vtedy :-)

Záleží, jak sofistikovaný útok bude, ale útočník může v podstatě vše virtualizovat a předhodit ke kontrole původní binárku.

Fyzický útok – záleží. Krádež nebo očividná manipulace vypnutého notebooku zašifrovaného silným a unikátním heslem nemusí být pro znalého a dbalého uživatele z hlediska krádeže dat problém. Pokud něco z předpokladů neplatí (zapnutý notebook, nenápadná modifikace, slabé heslo, neznalý nebo nedbalý uživatel, slabé nebo opakovaně použité heslo), už to s tou bezpečností nemusí být až tak slavné...

@ptrj

nez bys udelal kontrolu muze davno pres par_radkovej_u­tocnikuv_skrip­t.sh vratit regulerni grubx86.efi, odeslat odposlechnutej luks klic, zajimave soubory z /etc, tveho home, atd...

obecne je proste vhodne v ramci moznosti co nejvice (kdyz uz nelze vsem) moznostem predejit, nez kontrolovat "nejak" az nasledne zda te nekdo napadl a menit hesla, resp. pokud mas aktivni SecureBoot+vyh­radne_vlastni_kli­ce muzes tu kontrolu pridat jako detekci pruniku pri bugu kterej by SecureBoot obesel, ale urcite to nemit jako "nahradu" "bezpecnosti" pri vypnutem SecureBoot, jak sem tvoji otazku pochopil :)

EDIT: + treba doporucuju odebrat prava adresari /boot pro skupinu a ostatni
sudo chmod go-rwx /boot
tedy by vzdaleny utocnik kterej by pres nejakej deravej program bezici pod uzivatelem nemel pristup na EFI oddil kterej je pod /boot i presto ze EFI oddil je bezpravovej FAT...

4. 8. 2020, 01:12 editováno autorem komentáře