Ako ste zabrinuti za integritet vašeg sistema, dm-verity je jedan od ključnih dijelova Linux ekosistema. za sigurno pokretanje i otkrivanje neovlaštenih promjena u pohrani. Nastao je kao dio mapera uređaja kernela i sada je osnova za verificirano pokretanje u Androidu, OpenWrt-u i distribucijama koje traže poboljšanu sigurnost.
Daleko od toga da je apstraktan koncept, dm-verity se konfiguriše i koristi sa stvarnim alatima kao što su veritysetup i systemd-veritysetupValidira blokove u hodu koristeći hash stabla i može reagirati na korupciju politikama koje se kreću od evidentiranja događaja do ponovnog pokretanja ili rušenja sistema. Pogledajmo to detaljnije, bez ostavljanja ikakvih nedovršenih zadataka.
Šta je dm-verity i zašto bi vas to moglo zanimati
dm-verity je cilj mapiranja uređaja u kernelu koji provjerava integritet blok uređaja dok se podaci čitajuRadi tako što izračunava i provjerava hešove svakog bloka (obično 4K) u odnosu na unaprijed izračunato heš stablo, obično koristeći SHA-256.
Ovaj dizajn omogućava Datoteke se ne mogu tiho mijenjati između ponovnih pokretanja ili tokom izvršavanjaTo je ključno za proširenje lanca povjerenja pri pokretanju sistema na operativni sistem, ograničavanje perzistencije zlonamjernog softvera, jačanje sigurnosnih politika i osiguranje mehanizama šifriranja i MAC adrese tokom pokretanja.
Na Androidu (od verzije 4.4) i Linuxu općenito, Povjerenje je usidreno u korijenskom hešu stabla, koji je potpisan i validiran javnim ključem koji se nalazi na zaštićenoj lokaciji (npr. na boot particiji ili u Secure Boot-potpisanom UKI-ju). Probijanje bilo kojeg bloka zahtijevalo bi probijanje osnovnog kriptografskog heša.
Verifikacija se vrši po blokovima i na zahtjev: Dodana latencija je minimalna u poređenju sa I/O troškovima.Ako provjera ne uspije, kernel vraća I/O grešku i datotečni sistem izgleda oštećen, što se očekuje kada su podaci nepouzdani. Aplikacije mogu odlučiti hoće li nastaviti ili ne na osnovu svoje tolerancije na greške.
Kako stablo verifikacije funkcioniše interno
Verifikacijsko stablo je izgrađeno u slojevima. Sloj 0 su sirovi podaci sa uređaja, podijeljeni u blokove od 4K; SHA-256 (salted) heš se izračunava za svaki blok. Ovi hešovi se zatim spajaju i formiraju sloj 1. Sloj 1 se zatim grupira u blokove i ponovo hešira kako bi se formirao sloj 2, i tako dalje dok se sve ne uklopi u jedan blok: taj blok, kada se hešira, proizvodi korijenski heš.
Ako bilo koji sloj ne u potpunosti dovrši blok, Dopunjuje se nulama dok ne dostigne 4K kako bi se izbjegla dvosmislenost. Ukupna veličina stabla zavisi od veličine particije koja se provjerava; u praksi je obično manja od 30 MB za tipične sistemske particije.
Opći proces je sljedeći: odaberite slučajnu sol, heširajte na 4K, izračunajte SHA-256 sa soli po bloku, spaja se da bi formirao nivoe, popunjava granicu bloka nulama i ponavlja se s prethodnim nivoom dok ne ostane samo jedan korijenski heš. Taj korijenski heš, zajedno sa korištenom soli, hrani dm-verity tabelu i potpis.
Verzije formata diska i algoritam
Format heš blokova na disku ima verziju. Verzija 0 je bila originalna verzija korištena u Chromium OS-u.Sol se dodaje na kraju procesa heširanja, sažeci se pohranjuju kontinuirano, a ostatak bloka se dopunjuje nulama.
La Verzija 1 se preporučuje za nove uređajeSalt se dodaje na početak heša, a svaki sažetak se dopunjuje nulama do potencija dva, poboljšavajući poravnanje i robusnost. dm-verity tabela također specificira algoritam (npr. sha1 ili sha256), iako se za trenutnu sigurnost koristi sha256.
dm-verity tabela i bitni parametri
Ciljna tabela dm-verity opisuje gdje se nalaze podaci, gdje se nalazi heš stablo i kako to provjeritiTipična polja tabele:
- devuređaj s podacima koji se provjeravaju (tip putanje /dev/sdXN ili veći:manji).
- hash_dev: uređaj sa hash stablom (može biti isti; ako je tako, hash_start mora biti izvan označenog raspona).
- veličina_bloka_podataka: veličina bloka podataka u bajtovima (npr. 4096).
- veličina_bloka_hash-a: veličina heš bloka u bajtovima.
- broj_blokova_podataka: broj provjerljivih blokova podataka.
- blok_početka_hash-a: pomak (u blokovima hash_block_size) u odnosu na korijenski blok stabla.
- algoritam: algoritam za heširanje (npr. sha256).
- digestheksadecimalno kodiranje heša korijenskog bloka (uključujući sol prema verziji formata); ova vrijednost je ona kojoj treba vjerovati.
- solheksadecimalna sol.
Pored toga, postoje opcionalni parametri veoma korisno za prilagođavanje ponašanja:
- ignoriši_korupcijuZapisuje oštećene blokove, ali omogućava nastavak čitanja.
- ponovno_pokretanje_pri_korupciji: ponovno pokretanje nakon detekcije korupcije (nije kompatibilno sa ignore_corruption i zahtijeva podršku korisničkog prostora kako bi se izbjegle petlje).
- panika_zbog_korupcije: : izaziva paniku prilikom otkrivanja korupcije (nije kompatibilno s prethodnim verzijama).
- ponovno_pokretanje_pri_grešci y panika_pri_grešciiste reakcije, ali za I/O greške.
- ignoriši_nula_blokova: ne provjerava blokove koji se očekuju kao nule i vraća nule.
- korištenje_fec_from_device + fec_roots + fec_blokovi + fec_startOmogućite Reed-Solomon (FEC) tehnologiju za oporavak podataka kada verifikacija ne uspije; područja podataka, heša i FEC-a se ne smiju preklapati, a veličine blokova moraju se podudarati.
- provjeri_najviše_jednomProvjerava svaki blok podataka samo prilikom prvog čitanja (smanjuje opterećenje na štetu sigurnosti kod napada uživo).
- opis_root_hash_sign_key-aReferenca na ključ u privjesku ključeva za validaciju PKCS7 potpisa korijenskog heša prilikom kreiranja mapiranja (zahtijeva odgovarajuću konfiguraciju kernela i pouzdane privjeske ključeva).
- try_verify_in_taskletAko su heševi keširani i veličina I/O operacija dozvoljava, provjerava donju polovinu kako bi se smanjila latencija; podešava se sa /sys/module/dm_verity/parameters/use_bh_bytes po I/O klasi.
Potpis, metapodaci i usidravanje povjerenja
Da bi dm-verity bio pouzdan, Root hash mora biti pouzdan i obično potpisanU klasičnom Androidu, javni ključ je uključen u boot particiju, koju eksterno verifikuje proizvođač; on validira potpis root hash-a i osigurava da sistemska particija nije izmijenjena.
Verity metapodaci dodaju strukturu i kontrolu verzija. Blok metapodataka uključuje magični broj 0xb001b001 (bajtovi b0 01 b0 01), verzija (trenutno 0), potpis tabele u PKCS1.5 (obično 256 bajtova za RSA-2048), dužina tabele, sama tabela i nula popunjavanje do 32K.
U Android implementacijama, verifikacija se oslanja na fs_mgr i fstabDodavanje kvačice odgovarajućem unosu i postavljanje ključa u /boot/verity_key. Ako magični broj nije tamo gdje bi trebao biti, verifikacija se zaustavlja kako bi se izbjegla provjera pogrešne stvari.
Početak operacije potvrđen
Zaštita se nalazi u kernelu: Ako se kompromituje prije pokretanja kernela, napadač zadržava kontroluZato proizvođači obično strogo validiraju svaku fazu: ključ ugrađen u uređaj verificira prvi bootloader, koji verificira sljedeći, bootloader aplikacije, i na kraju, kernel.
Sa verifikovanim kernelom, dm-verity je omogućen prilikom montiranja verifikovanog blok uređaja.Umjesto heširanja cijelog uređaja (što bi bilo sporo i trošilo energiju), provjerava se blok po blok prilikom pristupa. Kvar uzrokuje I/O grešku, a servisi i aplikacije reaguju u skladu sa svojom tolerancijom: ili nastavljaju bez tih podataka ili se potpuno ruše.
Ispravljanje grešaka unaprijed (FEC)
Od Androida 7.0, FEC (Reed-Solomon) je inkorporiran s tehnikama ispreplitanja kako bi se smanjio prostor i povećala mogućnost oporavka oštećenih blokova. Ovo funkcioniše zajedno sa dm-verity: ako provjera ne uspije, podsistem može pokušati da je ispravi prije nego što je proglasi nepopravljivom.
Performanse i optimizacija
Da biste smanjili uticaj: Omogućite SHA-2 ubrzanje od strane NEON-a na ARMv7 i SHA-2 ekstenzije na ARMv8 iz kernela. Podesite parametre unaprijed čitanja i prefetch_cluster za vaš hardver; verifikacija po bloku obično malo doprinosi troškovima ulazno/izlaznih operacija, ali ove postavke prave razliku.
Početak rada na Linuxu (systemd, veritysetup) i Androidu
Na modernom Linuxu sa systemd-om, dm-verity omogućava verifikovani root pristup samo za čitanje koristeći veritysetup (dio cryptsetup-a), systemd-veritysetup.generator i systemd-veritysetup@.service. Preporučuje se uključivanje Secure Boot-a i potpisanog UKI-ja (ujedinjene slike kernela), iako nisu strogo obavezni.
Priprema i preporučeno particioniranje
Dio funkcionalnog i prilagođenog sistema. Rezervišite volumen za hash stablo (8–10% veličine root direktorijuma je obično dovoljno) i razmislite o odvajanju /home i /var direktorijuma ako trebate pisati. Tipična shema uključuje: ESP (za bootloader), XBOOTLDR (za UKI-je), root (sa ili bez enkripcije), VERITY particiju i opcionalno /home i /var.
Kao korijen, EROFS je veoma zanimljiva alternativa za ext4 ili squashfs.Dizajniran je samo za čitanje, s vrlo dobrim performansama na fleš memoriji/SSD-u, lz4 kompresijom po defaultu i široko se koristi na Android telefonima s dm-verityjem.
Datoteke koje moraju biti zapisive
Sa root ro, neki programi očekuju pisanje u /etc ili tokom init-aMožete ga premjestiti u /var/etc i simbolički povezati sve što treba promijeniti (npr. veze NetworkManagera u /etc/NetworkManager/system-connections). Imajte na umu da systemd-journald zahtijeva da /etc/machine-id postoji u korijenskom direktoriju (ne simbolički link) kako bi se izbjeglo rano pokretanje.
Da biste saznali koje se promjene dešavaju u izvršenju, koristite dracut-overlayroot: prekriva tmpfs preko korijena, i sve što je zapisano se pojavljuje u /run/overlayroot/u. Dodajte modul u /usr/lib/dracut/modules.d/, uključite overlayroot u dracut i postavite overlayroot=1 u liniji kernela; na ovaj način ćete vidjeti šta migrirati u /var.
Korisni primjeri: pacman i NetworkManager
U Archu je zgodno Premjestite Pacman bazu podataka u /usr/lib/pacman tako da rootfs uvijek odražava instalirane pakete. Zatim, preusmjerite keš memoriju na /var/lib/pacman i povežite je. Da biste promijenili listu ogledala bez dodirivanja korijena, premjestite je na /var/etc i ipak je povežite.
Sa NetworkManagerom, premjesti sistemske veze u /var/etc/NetworkManager i link iz /etc/NetworkManager/system-connections. Ovo održava root nepromjenjivim i konfiguraciju aktivnom tamo gdje bi trebala biti dostupna za pisanje.
Konstrukcija istinitosti i testiranje
Iz uživo verzije i sa svim savršenim i montiranim u ro, kreirajte stablo i roothash sa Veritysetup formatPrilikom pokretanja, ispisuje liniju Root Hash-a, koju možete sačuvati u roothash.txt. Pokrenite ga za testiranje sa veritysetup: open root-device root verity-device $(cat roothash.txt) i mount /dev/mapper/root.
ako želite, prvo generira stablo u datoteku (verity.bin) i zatim ga zapišite na VERITY particiju. Rezultirajući skup je: korijenska slika, verity stablo i korijenski hash koji ćete zakačiti pri pokretanju.
Konfigurišite liniju kernela
Dodajte ove parametre: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (npr. LABEL=OS) i systemd.verity_root_hash=VERITY-PATH (npr. LABEL=VERITY). Postavite systemd.verity_root_options na restart-on-corruption ili panic-on-corruption za stroge politike.
Druge preporučene opcije: ro (ako ne koristite EROFS/squashfs), rd.emergency=ponovno pokretanje y rd.shell=0 (sprečavanje neovlaštenih ljuski ako pokretanje ne uspije), i zaključavanje=povjerljivost da zaštiti memoriju kernela od pristupa.
Dodatne pregrade sa Verity
Ne samo korijen: Možete definirati druga mapiranja u /etc/veritytab i systemd-veritysetup@.service će ih sastaviti prilikom pokretanja. Zapamtite: lakše je RW montirati particiju koja nije root, a root korisnik može onemogućiti Verity na tim particijama, tako da je sigurnosna vrijednost tamo niža.
Sigurnost: Secure Boot, UKI i potpisani moduli
dm-verity nije čarobni štapić. Potpišite UKI i omogućite Secure Boot sa svojim vlastitim ključevima kako bi se spriječilo da bilo ko prepiše kernel/initramfs/cmdline (što uključuje root hash). Alati poput sbupdate-git ili sbctl pomažu u održavanju potpisanih slika i netaknutog lanca pokretanja.
Ako omogućite zaključavanje kernela ili provjeru potpisa modula, DKMS ili moduli izvan stabla moraju biti potpisani ili se neće učitati. Razmislite o prilagođenom kernelu s podrškom za potpisivanje za vaš cjevovod (pogledajte potpisane module kernela).
Šifriranje, TPM i mjerenje
dm-verity štiti integritet, nepovjerljivostMožete ostaviti root nešifriran ako ne sadrži nikakve tajne podatke i ako je lanac pokretanja zaštićen. Ako koristite ključne datoteke iz roota za otključavanje drugih volumena, onda je dobra ideja da ih šifrirate.
Sa TPM 2.0, systemd-cryptenroll omogućava vezivanje ključeva za PCR-ove 0,1,5,7 (firmver, opcije, GPT, status sigurnog pokretanja). Dodajte rd.luks.options=LUKS_UUID=tpm2-device=auto i obavezno uključite podršku za TPM2 u initramfs. systemd-boot mjeri kernel.efi u PCR4, što je korisno za poništavanje ključeva ako se UKI ili njegova cmdline promijene.
Ažuriranja i modeli implementacije
Verifikovani korijenski server samo za čitanje Ne ažurira se pomoću upravitelja paketa na tradicionalan način.Idealno je kreirati nove slike pomoću alata kao što su projekat Yocto i objavite ih. systemd ima systemd-sysupdate i systemd-repart za robusno preuzimanje i flešovanje slika.
Druga strategija je A/B shemaZadržavate dva korijena i dva veritie-a. Kopirajte aktivni korijen u neaktivni korijen, primijenite promjene i ponovite veritie. Vratite se pri sljedećem pokretanju. Ako koristite UKI, ne zaboravite ažurirati root hash u cmd liniji ili ponovo izgraditi potpisani UKI.
Za opcionalnu perzistenciju, koristite OverlayFS na verificiranom korijenu sa gornjim u tmpfs-u ili disku. Također možete proslijediti systemd.volatile=overlay za privremenu perzistenciju. Flatpak olakšava instaliranje aplikacija u /var i /home bez dodirivanja /.
Postoje automatizovani paketi (npr. verity-squash-root u AUR-u) koji grade squashfs root i Potpišite roothash sa kernelom i initramfs-om, što vam omogućava da birate između perzistentnog ili efemernog načina rada i čuvate najnovije rootfs datoteke kao sigurnosnu kopiju. Napomena: dodavanje perzistentnosti verificiranom root direktoriju ima uske slučajeve upotrebe; pokušajte sačuvati podatke aplikacije na odvojenim particijama.
Android: sistem kao root, AVB i preklapanja dobavljača
Od Androida 10, RootFS prestaje s radom na RAM disku i integrira se sa system.img datotekom. (system-as-root). Uređaji koji se pokreću s Androidom 10 uvijek koriste ovu shemu i zahtijevaju ramdisk za dm-linear. BOARD_BUILD_SYSTEM_ROOT_IMAGE je postavljen na false u ovoj verziji kako bi se razlikovalo korištenje ramdiska od direktnog aktiviranja system.img datoteke.
Uključuje Android 10 dinamičke particije i init prve faze što aktivira logičku sistemsku particiju; kernel je više ne montira direktno. OTA-ovi samo za sistem zahtijevaju dizajn "sistem kao root", što je obavezno na Android 10 uređajima.
Ni u jednom A/B slučaju, Odvojite oporavak od pokretanja sistemaZa razliku od A/B, ne postoji sigurnosna kopija boot_a/boot_b, tako da uklanjanje oporavka u ne-A/B može vas ostaviti bez načina oporavka ako ažuriranje pokretanja ne uspije.
Kernel montira system.img u /converity putem dvije putanje: vboot 1.0 (zakrpe za kernel za parsiranje Android metapodataka u /system i izvođenje dm-verity parametara; cmdline uključuje root=/dev/dm-0, skip_initramfs i init=/init sa dm=…) ili vboot 2.0/AVB, gdje bootloader integrira libavb, čita deskriptor hashtree-a (u vbmeta ili system), konstruira parametre i prosljeđuje ih kernelu u cmdline-u, s FEC podrškom i oznakama poput restart_on_corruption.
Sa sistemom kao root-om, Ne koristite BOARD_ROOT_EXTRA_FOLDERS za root foldere specifične za uređaj: oni će nestati prilikom flešovanja GSI-ja. Definišite specifične nosače pod /mnt/vendor/ , koje fs_mgr automatski kreira, i referenciraju ih u fstab-u stabla uređaja.
Android omogućava preklapanje dobavljača iz /product/vendor_overlay/: init će montirati u /vendor poddirektorije koje ispunjavaju SELinux kontekstne zahtjeve i postojanje /vendor/ Zahtijeva CONFIG_OVERLAY_FS=yy, na starijim kernelima, zakrpu override_creds=off.
Tipična implementacija: instalira prekompilirane datoteke u uređaj/ / /vendor_overlay/, dodajte ih u PRODUCT_COPY_FILES sa find-copy-subdir-files u $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, definirajte kontekste u file_contexts za etc i app (npr. vendor_configs_file i vendor_app_file) i dozvolite mounton na tim kontekstima u init.te. Testirajte sa atest vfs_mgr_vendor_overlay_test u userdebug.
Rješavanje problema: poruka o oštećenju dm-verity datoteke na Androidu
Na uređajima sa A/B slotovima, promijenite slotove ili Flešovanje vbmeta/boot-a bez konzistentnosti roothash-a Ovo može pokrenuti upozorenje: dm-verity oštećenje, vaš uređaj nije pouzdan. Komande poput fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img onemogućavaju verifikaciju, ali ostavljaju sistem bez ikakvih garancija integriteta.
Neki bootloaderi podržavaju fastboot oem disable_dm_verity i njegova suprotnost, enable_dm_verity. Radi na nekim modelima, ali ne na drugima; i može zahtijevati kernel/magisk sa podešenim zastavicama. Koristite na vlastitu odgovornost: razuman postupak je poravnaj boot, vbmeta i system, potpišite ili regenerirajte stablo i provjerite da li očekivani korijenski heš odgovara konfiguriranom.
Ako nakon upozorenja možete nastaviti pritiskati dugme za napajanje, sistem će se pokrenuti, ali Više nemaš netaknut lanac povjerenjaDa biste uklonili poruku bez žrtvovanja sigurnosti, vratite originalne potpisane slike ili ponovo izgradite/provjerite vbmeta s ispravnim hashtree-om, umjesto da onemogućavate verity.
i.MX i OpenWrt platforme
Na i.MX6 (npr. sabresd), konfigurišite kernel sa DM_VERITY i FEC podrškom, generirajte stablo pomoću veritysetup-a, sigurno pohranite korijenski hash i proslijedite odgovarajuće parametre u cmd liniji ili integrirajte putem initramfs-a pomoću systemd-veritysetup-a. Ako ne koristite dm-crypt, ne treba vam CAAM za verity; fokus je na integritetu.
U OpenWrt-u i u Ugrađeni Linux sistemi sa OpenEmbedded-om, Postoje napori da se integrišu dm-verity i SELinux (Bootlin poslovi su revidirani s namjerom uključivanja podrške). To je prirodno uklapanje: ruteri i mrežna oprema imaju koristi od nepromjenjivog, verificiranog i MAC-ojačanog korijena.
Ručna konstrukcija stabla i metapodataka (detaljan prikaz)
cryptsetup može generirati stablo za vas, ali ako više volite razumjeti format, definicija linije kompaktne tabele uključuje: naziv mapiranja, uređaj za podatke, veličine blokova podataka i heša, veličina slike u blokovima, hash_start pozicija (slika bloka + 8 ako je spojeno), root hash i salt. Nakon generiranja spojenih slojeva (od vrha do dna, isključujući sloj 0), zapisujete stablo na disk.
Da sve spakujem, sastaviti dm-verity tabelu, potpisati je (tipično RSA-2048) i grupirati potpis+tabelu u metapodacima sa verzioniranim zaglavljem i magičnim brojem. Zatim spaja sliku sistema, verity metapodatke i hash stablo. U fstab-u označava fs_mgr kao verify i postavlja javni ključ u /boot/verity_key za validaciju potpisa.
Optimiziraj sa SHA-2 ubrzanja za vaš CPU i prilagodite unaprijed čitanje/prefetch_cluster. Na ARM hardveru, NEON SHA-2 (ARMv7) i SHA-2 ekstenzije (ARMv8) značajno smanjuju opterećenje verifikacije.
Prilikom bilo kakvog raspoređivanja, imajte na umu da Vrijednost korijenskog heša mora biti zaštićena: bilo da je kompajliran u potpisani UKI, u potpisanu boot particiju ili validiran od strane bootloadera koristeći AVB. Sve nakon te tačke nasljeđuje to povjerenje.
Sa svim gore navedenim na mjestu, dm-verity postaje čvrsta osnova za nepromjenjive, mobilne i ugrađene sisteme, podržavajući transakcijska ažuriranja, konfiguracijske slojeve i moderni sigurnosni model koji smanjuje površinu napada i sprječava upornost napada bez žrtvovanja performansi.
