Názory k článku Kernel lockdown: nová vlastnost ochrání jádro i před rootem
-
Lepší uzamčení jádra, než bylo dosud, je jasně potřeba, ale tohle mi připadá jako řešení typu "všechno, nebo nic". Lépe použitelné by mi připadalo, kdyby některé operace byly povolené pouze pro binárky, u nichž by se kontroloval digitální podpis. Třeba to bude možné v rámci tohoto frameworku implementovat?
22. 10. 2019, 02:36 editováno autorem komentáře
-
Já toto vnímám jako první krok. Navíc jsou věci, které nemají smysl nastavit samostatně. Pokud může root nahrát libovolný (nepodepsaný) kernelový modul, může si dělat co chce a ostatní opatření půjde obejít. Na první pohled mi tedy režim integrity přijde jako minimum, které dává smysl. Režim confidentiality jde dál.
Povolit některé operace pouze podepsaným binárkám – to by mohl být další krok, nicméně:
* Aby to bylo smysluplné, je potřeba například zakázat rootovi i debugování těchto binárek. Takových věcí může být i více. V první řadě je důležité si všechny uvědomit.
* Na takové binárky budou větší nároky než na ty se SUID bitem. U SUID bitu se musíme popasovat s upraveným $PATH nebo $LD_PRELOAD (mimo jiné). Tady bychom se nejspíš museli poprat i s upravenýma binárkama knihovem. Nebo vše slinkovat staticky.
* Nakolik je tato vlastnost z kategorie „by se mohlo někomu hodit“ a nakolik to má přímo i nějaké využití? -
Martin X (neregistrovaný)
V AIXe je bezpecnostny problem "root moze vsetko" rieseny formou Trusted AIX.
Uzivatel root je "vypnuty" a na administraciu sa pouzivaju 3 role, ktore su priradene 3 roznym uzivatelom/administratorom - ISSO(Information System security officer), SA(system administrator) a SO(system officer). Na vacsinu citlivych veci je potrebna spolupraca minimalne dvoch administratorov, napriklad ISSO nastavi parameter v konfiguracii a nasledne SO musi rebootnut system, pripadne SA vytvori uzivatela a ISSO mu nastavi heslo a role/autorizacie.
Sucastou je aj pouzivanie RBAC (role based access control - to, kto moze citat, zapisovat alebo spustit subor, zavisi od jeho nastavenej role a nie od samotnych prav suboru) a podpisane binarky a konfiguracne subory. Subory, uzivatelia, tlaciarne, komunikacne a pod. rozhrania mozu mat pridelene "security labels" (uzivatel s maximalne povolenym pristupom "secret" sa nedostane k suboru s labelom "top secret" ani ak je jeho vlastnikom).Vzhladom ku komplikovanosti celeho systemu a nutnosti komplikovane nastavit bezpecnostne opravnenia, role a pod. prakticky pre kazdu pouzivanu aplikaciu, sa to snad pouziva len v armade, nevidel som Trusted AIX implementovany ani v bankovom prostredi (a to som spolupracoval snad so vsetkymi bankami na Slovensku, kde sa pouziva AIX).
-
Jedno z možných řešení by bylo definovat novou roli "nadroot". Nadroot by jako jediný měl přístup k jaderným rozhraním, ale mohl by spouštět jenom podepsané binárky (včetně knihoven), případně by mohl obecně otevírat jenom podepsané soubory (tj. včetně firmwarových blobů, konfigurací atd). Pro normálního roota by jeho procesy byly nepřístupné pro trasování i jinou interakci, tak jako jsou root procesy nepřístupné běžným uživatelům.
-
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...
-
Doma je pouzitelnost narocnejsia. Vo firme v buducnosti dovolite len podpisane binarky. Ale to je nanic, ked v binarke mate buffer overflow, cez ktory moze utocnik ziskat vykonanie lubovolneho kodu. Toto je jedna vrstva ochrany, ktora utocnikovi vyrazne obmedzi manevrovaci priestor.
Ked si mozete dovolit mat zariadenie na audit logy, tak tam moze zapisovat kernel co sa deje bez velkeho rizika prepisu.
-
L.Stříbrný podporovatel
Třeba si tam nainstalovat vlastní backdoor, aby do něj mohli přistupovat po delší dobu.
-
Spíš jde o to, že bude těžší si udržet pokoutně získaný root.
Mám doma starší nepodporovaný telefon – BlackBerry PRIV. Hardware je to poměrně unikátní, nicméně softwarovou podporu (záplaty) dnes už prostě nemá, takže bych to na nic seriózního použít nechtěl. Navíc má zamčený bootloader. Ten by ovšem nemuselo být tak těžké obejít. Na tak starý telefon již zřejmě bude existovat nějaká vhodná známá zranitelnost umožňující získat roota. Přepsat kernel nebo /system nemůžete, ale můžeme si pomoci dvojitým bootem – nabootuje původní systém (nejlépe ve flight mode), spustí automaticky aplikaci, která získá roota, zavede kernel modul pro kexec a spustí jakýkoli jiný systém (třeba novější Android). Ještě jsem si nenašel čas to realizovat, ale jít by to teoreticky mělo. PRIV navíc ještě nemá (narozdíl od novějších modelů) downgrade protection. Samozřejmě toto může mít i ne až tak „mírové“ využití, ale to je už otázka použití.
Lockdown do toho (částečně) hodí vidle – jak do „mírového“, tak do „válečného“ využití. Už nebude stačit získat roota chybou v libovolné komponentě. Pro stejný postup bude nutné najít vhodnou zranitelnost přímo v jádře.
Je sice možné po každém bootu vždy získat nějakou zranitelností roota a pak s tím operovat v mezích zákona (lockdownu), ale má to svoje nevýhody. Zaprvé takto neaktualizujete kernel (problém pro „mírové“ využití), zadruhé ten exploit může destabilizovat systém, což kexec řeší elegantně.
Netrvdím, že je lockdown dobrý nebo špatný. Má příjemné i nepříjemné důsledky, záleží na situaci.
-
Něco podobného má i FreeBSD - securelevel. https://www.freebsd.org/cgi/man.cgi?securelevel
Ten se dá aktivovat kdykoliv - má tři úrovně. Snížit se zpětně nedá, lze jej jen zvyšovat (přitvrzovat). Pro snížení je nutný reboot.Myšlenkou těchto opatření je, že některé parametry se jednou nastaví a posléze už neexistuje potřeba je měnit, leda při změně konfigurace. Pro útočníka je pak daleko těžší najít takový exploit, který umožní konfiguraci změnit, uložit a rebootovat.
Unixy a unix-like systémy bojují se svojí zastaralou koncepcí, a je to dobře. Největší boj je o to, jaká opatření zavést, aby byla ještě účinná a zároveň nebyla na tolik obtěžující, aby je administrátoři ještě vůbec chtěli používat.
Zpět k Linuxu: tam mi stále děsně moc chybí parametr jádra, který by se spouštěla sít s firewallem v defaultu na DROP. Stále jsme závislí na tom, že neselže inicializace firewallu z userspace - a když selže, zůstává všude default ACCEPT.
-
problém s FW na linuxu řešíme jednou výchozí sítí pouze pro administraci a aplikační interface se natahuje až v userspace jakmile je FW a další kontroly ok. Je to zároveň i kvůli aplikacím, kdy řada aplikací je klidně listen, ale ještě neumí odpovídat na požadavky.
Má to výhodu v tom, že svůj interface a IP adresu dostane aplikace až prošla testy, je zahřátá (u Javy nutnost) a víme, že neovní produkci.
-
problém s FW na linuxu řešíme jednou výchozí sítí pouze pro administraci a aplikační interface se natahuje až v userspace jakmile je FW a další kontroly ok
Ano, přesně tak se to musí řešit, ale trochu to nabourává celou koncepci inicializace systému, která by se o to měla starat.
Tento problém má i FreeBSD. Tam natahuju opravdu minimalistický pf.conf během bootu. Teprve po inicializaci spouštím rozsáhlejší script u kterého nevadí, když zhavaruje. Pořád to jistí ta výchozí konfigurace.
Mně tento stav přijde děsně zajímavý. Když si vezmu, že přesně na této systémové chybě se vyškolil Microsoft u Windows XP SP1 skoro před dvaceti lety. Pořád se snažím přijít na to, co by bránilo Linuxu a FreeBSD toto také zavést (jako parametr jádra).
-
argumenty od FreeBSD jsem četl, že ten systém se může stát díky tomu neovladatelné a nedostupný při chybách. Windows je v drtivé většině nasazený na počítači s fyzickým přístupem, naproti tomu freebsd (nebo i linux) je často na headless stanicích.
Jako výchozí stav to je samozřejmě celé nešikovné, ti pokročilí si s tím ale poradí a není to překážka, se systemd lze již lépe řešit strom závislostí a dát jednotlivé služby do správného pořadí a stavu.
Dnes asi nikdo nechce dělat změnu, která rozbije world.
-
A co na to INTEL se svým IME?
Událo se v oblasti Intelího backdooru s Minixem uvnitř CPU něco zásadně pozitivního ve prospěch uživatelů, nebo se těmto snahám budou chlapci z různých třípísmenných státních agentur usmívat odněkud z hloubi Ring -3 ?
https://www.root.cz/clanky/minix-je-zrejme-nejrozsirenejsim-systemem-je-ukryty-v-procesorech-intel/
