Vlákno názorů k článku Kernel lockdown: nová vlastnost ochrání jádro i před rootem od filbar - Docela se mi tato vlastnost jádra líbí, jenom...
-
Ondřej CaletkaZlatý podporovatelZákaz se týká ne uspávání (do RAM) ale hibernace, tedy přesunu obsahu paměti na disk. Proč to tak je dává smysl – útočník může zařízení hibernovat a následně si vyčíst obsah RAM z disku.
-
Ondra Satai NekolaZlatý podporovatelMám pro tebe šokující novinku - ne každá fíčura kernelu je pro každého. Zejména v první verzi.
-
Martin X (neregistrovaný)
Sifrovaci kluc hibernacneho suboru by mohol byt odvodeny od hesla uzivatela. "Drobnym problemom" by bolo len to, ze by sa heslo muselo zadavat aj pri vstupe do hibernacie, nielen pri prebudeni. Pripadne, ak je disk zasifrovany a utocnik si nevie precitat /etc/shadow, by mohol byt sifrovaci kluc odvodeny z hashu hesla uzivatela a nebolo by ho tak treba zadavat pri vstupe do hibernacie ("salt" konkretneho uzivatela by ale asi musel byt ulozeny v hibernacnom subore otvorene, co ciastocne znizi bezpecnost).
-
sifrovaci klic hibernacniho souboru neni odvozen od hesla uzivatele, protoze jde o sifrovaci klic pro LUKS, krome sifrovaneho swap pocitam samozrejme i s sifrovanym rootfs (vcetne /boot)...
rozdil z pohledu sifrovani mezi starem nehibernovaneho stroje a startem hibernovaneho stroje je minimalni, v obou pripadech se "prvni faze grub" zepta na LUKS heslo, jeste nez zobrazi Grub menu, heslem se oemkne LUKS, nahodi v nem LVM a nasledne uzivatel v menu vybere (nebo pocka na timeout defaultu) polozku ktera natahne jadro a initramfs, initramfs odemkne znovu LUKS+LVM (zepta se na LUKS heslo uzivatele nebo provede automaticky pres pripravenej keyfile), v tuhle chvili se ty 2 postupy rozejdnou:
1. v pripade cisteho startu se provede cistej start
2. v pripade probuzeni z hibernace se natahne ram obnovi ze swaptedy z bezpecnostniho hlediska je start ze sifrovaneho disku se sifrovanym swap totozne bezpecna jako probuzeni z hibernace
-
Martin X (neregistrovaný)
"sifrovaci klic hibernacniho souboru neni odvozen od hesla uzivatele, protoze jde o sifrovaci klic pro LUKS, krome sifrovaneho swap pocitam samozrejme i s sifrovanym rootfs (vcetne /boot)..."
To znamena, ze ak je na danom pocitaci viac uzivatelov, tak vsetci zdielaju rovnake heslo pre LUKS.
V pripade notebooku je to OK, tam je vacsinou len jeden pouzivatel ale v pripade viacerych pouzivatelov to moze byt problem.
V AIXe je sifrovany filesystem rieseny tak, ze sa sifruje na urovni suborov (teda nie LVM/celeho fs) , pricom kazdy subor ma vlastny nahodne vygenerovany sifrovaci kluc (symetricka sifra, najcastejsie AES), ktory je ulozeny v metadatach suboru a zasifrovany verejnymi klucmi vsetkych pouzivatelov a skupin, ktori maju pristup k danemu suboru (v metadatach je tolko kopii sifrovacieho kluca, kolko uzivatelov/skupin ma pristup k suboru) . Pri zmene vlastnika, skupiny, pridani uzivatela do ACL suboru sa dany sifrovaci kluc zasifruje verejnym klucom daneho uzivatela a prida sa do metadat suboru. Pri odobrani pristupu uzivatela sa jeho kluc odoberie aj z metadat suboru. Standartne je tam pridany aj root (v metadatach je sifrovaci kluc suboru zasifrovany verejnym klucom roota), ale da sa zapnut aj volba, ze root sa k sifrovanemu suboru nedostane, pokial mu vlastnik nepovoli pristup.
25. 10. 2019, 19:32 editováno autorem komentáře
-
Myslím, že tato debata není moc produktivní.
Pokud se bavíme o bezpečnosti, je potřeba mít shodu v tom, jaké útočníky v jakých situacích řešíme. Často není potřeba explicitní dohoda, protože je to všem zřejmé, tady je situace jiná.
Začnu vaším srovnáním probuzení z hibernace a bootu. Mějme secure boot a mějme útočníka, který má přístup ke klíčům swapu. Může to znít jako silné možnosti pro útočníka, ve skutečnosti to odpovídá realitě, pokud útočník nějakou zranitelností převezme vládu nad systémem. Secure boot zde má aspoň zabránit perzistentnímu útoku, hibernace ale umožní tuto ochranu obejít. Přitom Vaše úvaha byla asi správná, jen vycházela z jiných předpokladů.
Je tedy potřeba si před podobnou debatou ujasnit, jaké útočníky řešíme. Útočník může přistupovat k zařízení přes síť, může mít uživatelský účet a může jít o člověka s více či méně omezeným přístupem k zařízení. U vzdálených útočníků nám nejspíš moc šifrování disku nepomůže (stejně jim je například dm-crypt transparentně rozšifruje), u útočníků s fyzickým přístupem šifrování může více či méně pomoci. Ale záleží například, jestli to zařízení budeme po útočníkovi dále používat (=> může být „obohaceno“ třeba o nějaký keylogger nebo něco podobného), jestli se dostal k zapnutému používanému zařízení (=> útočník se může pokoušet o cold boot attack), jaké má schopnosti a rozpočet apod.
Teď je snad již pěkně vidět, že bez předpokladů můžeme vést debaty donekonečna bez valného výsledku.
-
AFAIK jde spíš o opačný problém: aby útočník nemohl podvrhnout falešnou image a tu "probudit" místo skutečného uspaného systému. Podobný problém je třeba s
kexec(který je potřeba pro kdump). Prostě celá podstata je snaha zajistit, aby na počítači jako OS běželo jen to, co tam opravdu má běžet. Pokud umožníte suspend to disk a následné probuzení bez podepsání image a ověření toho podpisu při resume nebo kexec libovolného jádra, pak tím vlastně úplně obejdete celý secure boot a ten tím ztratí smysl. -
jak podvrhnes swap kdyz je (vcetne grub.cfg) v LUKS, jedine ze podvrhnes i grub efi binarku na nesifrovanem EFI oddilu, ta by ale jiz nebyla podepsana... pripadne lze pouzit sicherboot kterej zabali jadro+initramfs a podepise ho vlastnima klicema ulozenejma do uefi s tim ze vychozi klice vyhodis, pak uz nevim zda to lze naborit...
