Co je dm-verity a jak chrání integritu systému?

Pokud pracujete s Androidem, Linuxem nebo vestavěnými systémy, pravděpodobně jste viděli zprávy jako „dm-verity corruption“ nebo jste slyšeli o verified boot, AVB nebo Secure Boot. Za tím vším se skrývá klíčová část jádra: dm-verity, mechanismus navržený k zajištění toho, aby souborový systém nebyl neoprávněně narušenani když je zařízení zapnuté, ani mezi restarty.

Může se to zdát jako drobný problém, ale ve skutečnosti ovlivňuje každodenní věci, jako je například to, že váš telefon neudržuje malware skrytý v systémovém oddílu nebo že router nebo „uzavřený“ server se vždy spouští ve stejném spolehlivém stavu. dm-verity se spoléhá na hašovací strom SHA-256 a kryptografické podpisy k ověření, že data na disku jsou stále taková, jaká by měla být, blok po bloku.A pokud něco nesedí, jádro může vrátit chyby čtení, restartovat počítač nebo dokonce panikařit, aby se vyhnulo dalšímu provádění pochybného kódu.

Co je dm-verity a jaký problém řeší?

dm-verity je cílem subsystému mapování zařízení v linuxovém jádru, který umožňuje ověření integrity blokového zařízení v reálném čase.Obvykle se jedná o oddíl nebo obraz obsahující kořenový souborový systém nebo kritický oddíl (např. /system v systému Android). Místo „slepného čtení“ disku je každý přístupný blok kryptograficky kontrolován oproti předem vypočítanému hašovacímu stromu.

V systému Android od verze 4.4 a na mnoha moderních linuxových distribucích dm-verity je základem ověřeného bootováníDíky tomu je zajištěno, že systémový oddíl bude přesně stejný, jako když byl obraz vytvořen. To ztěžuje rootkitům nebo jiným typům malwaru přetrvávat po restartu systému vkládáním škodlivých souborů nebo binárních souborů do systému.

Jednou z výhod tohoto přístupu je, že Zařízení dm-verity se v adresáři /dev/mapper zobrazují jako normální bloková zařízení.Díky tomu je lze připojit, jako by to byl jen další disk. Pro výše uvedený souborový systém (ext4, EROFS, squashfs atd.) se vše zdá standardní, ale každá operace čtení prochází kryptografickým filtrem Verity.

Proč je to nutné: malware s root oprávněním a důvěryhodným bootováním

V systémech jako Android, aplikace nebo binární soubory, které získají oprávnění kořen Dokážou se skrývat lépe než samotné detekční systémy.Díky většímu počtu oprávnění než antivirové nebo bezpečnostní nástroje mohou „lhát“ o souborech, procesech nebo konfiguracích, což ztěžuje jejich detekci a odstranění.

Bez mechanismu jako dm-verity, Útočník může upravit systémové binární soubory, knihovny nebo spouštěcí skripty, aby dosáhl perzistence.a tím zabránit nástrojům, které umožňují ověřit integritu souboru Detekují změnu, to znamená, že zůstávají i po vypnutí a opětovném zapnutí zařízení. To je klasická noční můra perzistentních rootkitů.

dm-verity funguje jako strážce základů systému: Jádro akceptuje jako platné pouze ty bloky, které splňují očekávaný hash kontrolního stromu.Pokud někdo ručně změnil systémový oddíl, hashe se již nebudou shodovat a jádro to zjistí, jakmile se pokusí přečíst změněná data.

Jak dm-verity funguje interně

Základní myšlenka je jednoduchá, ale účinná: Nad všemi bloky zařízení je vybudován kryptografický hašovací strom (obvykle SHA-256).hierarchicky. Tento strom je uložen na disku a při běžném používání se používá k ověření každého přečteného bloku.

Struktura hašovacího stromu

Verifikační strom je tvořen úrovněmi. Vrstva 0 obsahuje skutečná data (např. obraz systému ext4/EROFS), rozdělená do bloků o velikosti 4K.Pro každý z těchto bloků se vypočítá hash SHA-256 (obvykle s náhodnou solí pro posílení útoků před výpočtem).

Haše ve vrstvě 0 jsou zřetězeny a tvoří vrstvu 1. Vrstva 1 je přeskupena do bloků o velikosti 4K a pro každý výsledný blok je vypočítán hash SHA-256.čímž se vytvoří vrstva 2. Proces se opakuje vrstvu po vrstvě, dokud se celá sada hashů nevejde do jednoho bloku; hash tohoto posledního bloku je kořenový hash, který představuje celý strom.

Pokud vrstva nevyplňuje celý blok, Je vyplněno nulami, dokud nedosáhne 4KTím se zabrání nejednoznačnostem a umožní se detekce pokusů o „ořezání“ stromu nahrazením částí libovolnými daty: očekávaná struktura zahrnuje toto známé doplnění nulami.

Na disku, Strom je uložen zřetězením úrovní od nejvyšší vrstvy dolů (s výjimkou datové vrstvy 0)Celková velikost stromu se liší v závislosti na velikosti kontrolovaného oddílu, ale v praxi je obvykle poměrně malá, obvykle menší než 30 MB i u velkých systémových oddílů.

Verze formátu a hašovací algoritmy

Formát, ve kterém jsou uloženy hashovací bloky, se vyvíjí. Verze 0 formátu, původně používaná operačním systémem Chromium, přidávala sůl na konec při výpočtu hashe a ukládala digesty průběžně., čímž se zbytek bloku vyplní nulami.

Verze 1, doporučená pro nové systémy, při výpočtu hash umístí sůl před data a doplňuje každý digest na mocninu dvou. To zlepšuje zarovnání a odolnost proti určitým typům útoků nebo poškození. Tabulka dm-verity také uvádí použitý algoritmus (sha1, sha256 atd.), ačkoli v dnešní době je rozumné používat SHA-256.

Postupný výpočet kořenového hashe

Pokud chcete strom postavit ručně, obecné schéma je jasné. Nejprve se vybere náhodná solená hodnota (salt) v hexadecimálním formátu, obraz se rozdělí na 4K bloky a pro každý blok se vypočítá jeho solená SHA-256 hodnota.Tyto hashe tvoří první „logickou“ úroveň nad daty.

Luego, Haše se zřetězují, dokud se nenaplní 4K bloky.Pokud není dostatek místa, je blok vyplněn nulami. Každý výsledný blok je také hashován pomocí SHA-256, čímž se vytvoří další úroveň stromu. Tento proces „hashování hashů“ se opakuje, dokud nezůstane jediný hash: kořenový hash.

V praktických implementacích nástroje jako cryptsetup/veritysetup zvládají všechny tyto výpočty a přímo generují stromový soubor (verity.bin) a kořenová hašovací hodnota (roothash), připravené k použití v tabulce dm-verity nebo v podepsaných metadatech.

Tabulka dm-verity: popis, co a jak ověřovat

Aby jádro mohlo používat dm-verity, potřebuje přesný popis toho, kde se data nacházejí, kde se nachází hašovací strom a jaké parametry má použít. Tento popis je tabulka dm-verity, řádek parametrů, které mapovač zařízení interpretuje při vytváření ověřeného logického zařízení..

V jednom typická zjednodušená verzeDefinici lze chápat takto:

Nejdůležitější obory Tabulka dm-verity obvykle obsahuje:

• dev: zařízení, které obsahuje ověřovaná data (například oddíl /dev/sdXN nebo pár major:minor).
• hash_dev: zařízení, které ukládá hašovací strom; může být stejné jako dev, pokud hash_start ukazuje mimo rozsah ověřených dat.
• velikost_bloku_dat: velikost datového bloku v bajtech, typicky 4096.
• velikost_hash_bloku: velikost bloku pro hashe, obvykle je také 4096.
• počet_bloků_dat: počet datových bloků, které mají být chráněny.
• hash_start_block: posun v blocích od začátku zařízení do místa, kde začíná hašovací strom.
• algoritmushašovací algoritmus (sha256 je de facto standardem).
• digest (kořenový hash): hash kořenového bloku stromu, vyjádřený v hexadecimální soustavě; je to důvěryhodná „kotva“.
• sůlSůl používaná při výpočtu hashů, také v hexadecimální soustavě.

Kromě těchto základních oborů, Existují volitelné parametry, které upravují, jak systém reaguje na poškození nebo chyby.Můžete například určit, že v případě poškození by měl být systém restartován, měla by být spuštěna panika nebo by měl být problém ignorován a pouze se do systému přihlásit. protokolynebo že obnova FEC je aktivována před selháním.

Pokročilé možnosti tabulky: poškození, FEC a výkon

dm-verity obsahuje sadu příznaků pro chování profilování. ignore_corruption umožňuje pokračovat ve čtení, i když je detekováno poškození, ale zanechává stopu v protokolech., užitečné v prostředích, kde je dostupnost upřednostňována před striktní integritou.

Pokud hledáte pevnou ruku, `restart_on_corruption` nebo `panic_on_corruption` vynutí restart nebo paniku, pokud blok selže při ověření.Podobné varianty existují pro chyby I/O (restart_on_error, panic_on_error). Existuje také volba ignore_zero_blocks, která zabraňuje kontrole bloků, u kterých se očekává nula, a vrací nuly přímo.

U systémů, které integrují dopřednou korekci, `use_fec_from_device` spolu s `fec_roots`, `fec_blocks` a `fec_start` umožňují použití Reed-Solomonových kódů.S FEC je v případě selhání ověření možné pokusit se o rekonstrukci bloku pomocí redundantních informací, než jej považovat za ztracený.

Další možnosti, například check_at_most_once, Umožňují ověření každého bloku pouze při prvním přístupu.To snižuje režijní náklady za cenu nedetekce aktivních modifikací; jedná se o kompromis mezi zabezpečením a výkonem. Příznaky jako `root_hash_sig_key_desc` umožňují jádru ověřit podpis PKCS7 kořenového hashe pomocí klíčů uložených v keyringu.

Podpis, metadata a magické číslo pravosti

Aby všechno dávalo smysl, musí být kořenová hašovací hodnota spolehlivá. V klasickém Androidu je veřejný klíč součástí bootovacího oddílu a výrobce je zodpovědný za jeho externí ověření.Tento klíč se používá k ověření podpisu kořenového hashe nebo tabulky dm-verity, čímž se zajistí, že hash strom nebyl pozměněn.

Metadata Verity tyto informace zapouzdřují. Blok o velikosti 32 kB obsahuje magické číslo, verzi, signaturu, délku tabulky a obsah a navíc je doplněn nulami.Tato řízená struktura umožňuje lokalizaci a validaci metadat bez nejednoznačnosti.

Typická pole Tato metadata zahrnují:

• Magické číslo: pevná hodnota 0xb001b001, používaná komponentami jako fs_mgr k rozpoznání, že se jedná o platný blok verity.
• Verze: aktuálně 0, používá se k zavedení změn formátu v budoucnu.
• Společnost: podpis tabulky dm-verity, obvykle PKCS1.5 s klíčem RSA-2048 (256 bajtů).
• Délka stoluVelikost níže uložené tabulky dm-verity v bajtech.
• Tabla: samotná serializovaná tabulka dm-verity.
• Plněné: nuly, dokud není dokončeno 32 000 bajtů bloku.

Pokud se magické číslo nenajde při analýze konce systémového obrazu, Předpokládá se, že oddíl není připraven k ověření a proces ověření není aktivován.To například zabraňuje tomu, aby byl oddíl považován za ověřený, i když ověřený není.

V systému Android fs_mgr a soubor fstab řídí, které oddíly jsou kontrolovány.Jednoduše přidejte zaškrtávací políčko (například „verify“ v parametrech fs_mgr) a umístěte příslušný veřejný klíč do /boot/verity_key, čímž spustíte proces ověřování od začátku do konce.

Jak to propojuje s ověřeným startupem

dm-verity by byl k ničemu, kdyby útočník mohl vplížit dovnitř upravené jádro nebo bootloader, který akceptuje cokoli. Proto, v mobilní a zabezpečených platformách jsou kořenový hash a tabulka dm-verity součástí řetězce důvěry, který začíná v technické vybavení.

Výrobce obvykle vypálí veřejný klíč do zařízení. Tento klíč ověřuje podpis prvního bootloaderu, který následně kontroluje další úroveň, bootloader aplikace a nakonec obraz jádraOdtud jádro, nyní ověřené, převezme řízení a pomocí dm-verity rozšíří tuto důvěryhodnost na systémový oddíl.

Na moderním Androidu s AVB (Android Verified Boot 2.0), Bootloader obsahuje libavb a čte deskriptory hashtree v oddílech nebo ve vbmeta.S touto informací sestaví parametry dm-verity a předá je jádru na řádku příkazy, spolu s pokyny, jako například zda existuje FEC, co dělat v případě korupce atd.

dm-verity v systému Android: zprávy o chybách system-as-root, AVB a poškození systému

Android se na dm-verity spoléhá už léta. Od verze Android 4.4 se používá jako základ pro ověřené bootování a od verze Android 10 dále design system-as-root přímo integruje rootfs do souboru system.img.eliminace mnoha klasických nastavení a vynucení zpracování dm-verity z inicializace první fáze.

Se systémem jako root a moderními OTA, Systémový oddíl je obvykle pouze pro čtení a je chráněn ověřeným hashtree.Jádro to vidí přes zařízení dm-verity, transparentně pro nejvyšší vrstvu Androidu.

Chyby slotů A/B, vbmeta a „poškození dm-verity“

U zařízení se schématem A/B je docela snadné, že se něco vychýlí z osy. Pokud flashujete bootovací soubor nebo soubor vbmeta bez toho, aby odpovídaly kořenovému hash serveru a skutečnému stromu systémových oddílů, typickým výsledkem je obávaná zpráva „dm-verity corruption, your device is not trusted“ (poškození dm-verity, vaše zařízení není důvěryhodné)..

Pro obejití ověřování existují příkazy jako fastboot flash –disable-verity –disable-verification vbmeta vbmeta.imgnebo u některých výrobců `fastboot oem disable_dm_verity`. Ale buďte opatrní: Tím se zakáže ověřené spuštění a eliminují se záruky integrity.i když se vám ho podaří spustit bez otravných hlášek.

„Čistý“ způsob, jak to opravit, zahrnuje Ujistěte se, že obrazy systému, bootovací obrazy a obrazy vbmeta jsou vzájemně konzistentní.Regenerujte (nebo obnovte) strom pravdivosti a aktualizujte signatury nebo deskriptory tak, aby očekávaný kořenový hash odpovídal skutečnému. Pouze tímto způsobem můžete zachovat řetězec důvěryhodnosti bez... Triky nebezpečný.

Vztah k TWRP, odemčenému bootloaderu a modům

V reálném světě se mnoho lidí setkává s dm-verity při instalaci ROM, upravených jader nebo rootování. Pro použití TWRP, flashování firmwaru nebo instalaci modů obvykle potřebujete mít odemčený bootloader.protože ověřený proces spouštění zabraňuje spouštění obrazů, které nejsou podepsány výrobcem.

Existují postupy, které doporučují např. Nejprve nainstalujte specifický firmware, restartujte počítač do bootloaderu a spusťte příkazy jako „fastboot oem disable_dm_verity“ a poté „fastboot oem enable_dm_verity“.a poté nainstalujte novější firmware. Cílem těchto kroků je „resetovat“ stav Verity tak, aby nové obrazy byly přijímány bez hlášení o poškození.

Pokud se po pádech nebo chybách s blikáním systému při každém restartu zobrazí varování „dm-verity corruption“ (poškození dm-verity), Je rozumné zkontrolovat, zda systém oddílů není fyzicky poškozen a zda použité obrazy odpovídají vašemu modelu.Někdy může jednoduchý nesoulad mezi modemem, bootovacím a systémovým firmwarem narušit proces ověřeného bootování.

dm-verity na linuxových počítačích a serverech (systemd, veritysetup)

dm-verity není exkluzivní pro Android. V moderních linuxových distribucích, zejména se systemd, se stává populárním jako základ pro vysoce důvěryhodné kořenové systémy pouze pro čtení.velmi podobné tomu, jak fungují některé routery, zařízení nebo mediální boxy.

Typické root připojení s dm-verity zahrnuje: kořenový obraz nebo oddíl, soubor obsahující strom verity (verity.bin), hodnotu hash kořenového disku, jednotky systemd-veritysetup a příslušné parametry řádku jádraVolitelně je přidán podepsaný UKI (Unified Kernel Image) a Secure Boot, aby byl celý systém dobře chráněn.

Schéma dělení a souborový systém

Obvyklé doporučení je rezervovat pro hashe specifický oddíl. Běžně používané uspořádání se skládá z: oddílu EFI (ESP), oddílu XBOOTLDR pro UKI, kořenového oddílu (se šifrováním nebo bez něj), oddílu VERITY pro stromovou strukturu a volitelně zapisovatelných oddílů /home a /var..

Místo klasické ext4 pro root, EROFS je velmi zajímavá možnostJe navržen pouze pro čtení, má velmi dobrý výkon flash paměti a SSD a ihned po vybalení podporuje kompresi LZ4. Není náhoda, že se v kombinaci s dm-verity hojně používá na telefonech s Androidem.

Soubory, které je třeba zapsat, a běžné triky

Pokud je kořenový adresář připojen pouze pro čtení, je třeba pečlivě zvážit, které soubory je třeba upravovat. Mnoho programů očekává zápis do /etc, /var nebo podobných cest.Místo toho, aby byl /etc kompletně zapisovatelný, je efektivnější přesunout do /var/etc pouze to, co je nezbytné, a symbolicky to propojit z /etc.

Např Připojení NetworkManageru lze přesunout do /var/etc/NetworkManager/system-connections a ponechte symbolický odkaz z /etc/NetworkManager/system-connections. Tímto způsobem se nemění design neměnného kořenového adresáře, ale konfigurace, které je třeba změnit, lze stále měnit.

Abychom zjistili, co se skutečně zapisuje během spouštění a provádění, Můžete použít dracut-overlayroot, který připojí překryv tmpfs nad kořenový adresář a ponechá všechny skutečné zápisy zaznamenané v /run/overlayroot/u.Po chvíli používání systému jednoduše zkontrolujte daný adresář a zjistěte, co je třeba z ověřeného kořenového adresáře přesunout.

Je to také běžné v Arch Linuxu Přemístěte databázi pacmanu do /usr/lib/pacman a mezipaměť do /var/lib/pacmantakže kořenový obraz vždy odráží „zapečetěný“ stav systému, zatímco synchronizační a aktualizační operace se provádějí v zapisovatelných oblastech.

Vytvoření Verity a konfigurace bootovacího procesu pomocí systemd

Typický tok V systému Linux, který chce pro root přístup používat dm-verity, by to bylo:

• Spusťte systém z aktivního prostředí a připojte kořenový adresář pouze pro čtení., jakmile systém zmrazíte přesně tak, jak chcete.
• Spuštěním příkazu `veritysetup format root-device verity-device` vygenerujete hašovací strom a kořenový hash.Příkaz obvykle vypíše řádek s kořenovým hašem, který je uložen v souboru (například roothash.txt).
• Otestujte mapování s otevřeným veritysetup, vytvoření ověřeného souboru /dev/mapper/root a jeho připojení pro kontrolu, zda vše funguje.

Dále je třeba upravit příkazový řádek jádra. U systemd se používají parametry jako systemd.verity=1, roothash=…, systemd.verity_root_data=… a systemd.verity_root_hash=…., kromě možností jako systemd.verity_root_options=restart-on-corruption nebo panic-on-corruption v závislosti na požadované tvrdosti.

Pokud se používá UKI, Všechny tyto parametry jsou integrovány do obrazu kernel.efi, který je podepsán a spuštěn pomocí Secure Boot.Díky tomu se zabrání tomu, aby někdo změnil kořenový hash na příkazovém řádku, aniž by došlo ke zneplatnění podpisu, a tím se zachovává model důvěryhodnosti.

Bezpečné spouštění, šifrování a TPM: jak jednotlivé části dohromady

dm-verity zaručuje pouze integritu, nikoli důvěrnost. Data lze zobrazit, pokud nejsou šifrována, ale nelze je změnit, aniž by byla detekována.Proto se často kombinuje se šifrováním (LUKS) a TPM pro ochranu klíčů.

Běžně používaná strategie je Ukotvit dešifrovací klíče LUKS k určitým PCR TPM pomocí systemd-cryptenroll (například PCR 0, 1, 5, 7), takže změna firmwaru, rozložení oddílů nebo stavu Secure Boot zneplatní klíče. To útočníkovi zabrání v deaktivaci Secure Boot a vplížení jádra, které ignoruje verity, aniž by současně přerušilo dešifrovací řetězec.

Pokud se použije systemd-boot, Bootloader měří obraz kernelu.efi v PCR 4.Pokud se toto opatření změní, přidružené klíče se neuvolní a zašifrovaný oddíl se neotevře. Toto je další článek v řetězci, který zajišťuje, že jádro, initramfs a cmdline (včetně roothash) nebyly zmanipulovány.

Použití mimo kořenový adresář: další oddíly, překryvy a aktualizace

Ačkoli je ochrana kořene nejběžnější praxí, Příkaz dm-verity lze použít i na jiné oddíly, které jsou připojeny při bootování.Na systémech se systemd jsou tyto další oddíly popsány v souboru /etc/veritytab a jsou automaticky konfigurovány pomocí systemd-veritysetup@.service.

Ověřený oddíl bez oprávnění root je však méně bezpečný: Lze jej relativně snadno obnovit pro čtení/zápis a uživatel root na něm může dokonce deaktivovat Verity.Přesto je to užitečné pro data, která chcete monitorovat, nebo pro obrazy pouze pro čtení připojené v jiných bodech.

Pokud jde o aktualizace, ověřený kořenový adresář pouze pro čtení mění mentální model. Od administrátora se neočekává, že bude na produkčním kořenovém serveru provádět příkaz „pacman -Syu“ nebo podobný.ale spíše se generují nové obrazy systému s odpovídajícími stromy pravdivosti a transakčním způsobem se nasazují.

Existuje pro to několik strategií: Pro stahování a flashování nových obrazů použijte nástroje jako systemd-sysupdate a systemd-repart, nebo navrhnout A/B schéma se dvěma kořeny a dvěma veritami, kde aktualizujete neaktivní oddíl a poté prohodíte role.

Pokud chcete něco flexibilnějšího, Ověřený kořenový adresář lze připojit jako nižší adresář na OverlayFS s horní vrstvou na tmpfs nebo disku.Změny se tedy aplikují na horní vrstvu, ale základem zůstává ověřený obrázek. Můžete si dokonce zvolit volitelnou nebo efemérní perzistenci (například systemd.volatile=overlay) pro „jednorázové relace“.

Ve světě stolních počítačů technologie jako například Flatpak se do této filozofie dobře hodí.Instalují a aktualizují aplikace do adresářů /var a /home, aniž by se dotýkaly kořenového adresáře chráněného verity. Tím se udržuje neměnný základní systém a umožňuje se nezávislá správa aplikací.

Celý tento ekosystém dělá z dm-verity mnohem víc než jen kuriozitu jádra: Je to základní kámen neměnných, mobilních a vestavěných systémů, které se vždy musí spouštět ve známém stavu a detekovat jakoukoli manipulaci s nimi. skladovánía integruje se s ověřeným spouštěním, zabezpečeným spouštěním, šifrováním a TPM, čímž nabízí moderní model zabezpečení bez kompromisů v oblasti výkonu nebo flexibility.