Kas yra „dm-verity“ ir kaip ji apsaugo sistemos vientisumą?

Jei dirbate su „Android“, „Linux“ ar įterptinėmis sistemomis, tikriausiai matėte tokius pranešimus kaip „dm-verity corruption“ arba girdėjote apie patikrintą įkrovą, AVB arba saugų įkrovą. Už viso to slypi pagrindinis branduolio komponentas: „dm-verity“ – mechanizmas, skirtas užtikrinti, kad failų sistema nebūtų pakeista nei įjungiant įrenginį, nei tarp perkrovimų.

Tai gali atrodyti kaip žemo lygio problema, tačiau iš tikrųjų ji veikia kasdienius dalykus, pavyzdžiui, apsaugo jūsų telefoną nuo sistemos skaidinyje paslėptos kenkėjiškos programos arba užtikrina, kad maršrutizatorius ar „uždaras“ serveris visada būtų paleidžiamas toje pačioje patikimoje būsenoje. „dm-verity“ remiasi SHA-256 maišos medžiu ir kriptografiniais parašais, kad blokas po bloko patikrintų, ar diske esantys duomenys vis dar yra tokie, kokie turėtų būti . Jei kažkas nesutampa, branduolys gali pateikti skaitymo klaidas, paleisti kompiuterį iš naujo arba net panikuoti, kad išvengtų tolesnio įtartino kodo vykdymo.

Kas yra dm-verity ir kokią problemą jis išsprendžia?

„dm-verity“ yra „Linux“ branduolio „device-mapper“ posistemio taikinys, leidžiantis realiuoju laiku patikrinti blokinio įrenginio , paprastai skaidinio arba atvaizdo, kuriame yra šakninė failų sistema arba kritinis skaidinys (pvz., „/system“ „Android“ sistemoje), vientisumą. Užuot skaitęs diską „aklai“, kiekvienas pasiekiamas blokas yra kriptografiškai tikrinamas pagal iš anksto apskaičiuotą maišos medį.

„Android“ sistemoje nuo 4.4 versijos ir daugelyje šiuolaikinių „Linux“ distribucijų „dm-verity“ yra patikrinto paleidimo pagrindas : jis užtikrina, kad sistemos skaidinys būtų toks pat, koks buvo sukurtas sukuriant atvaizdą. Tai apsunkina rootkit ar kitokio tipo kenkėjiškų programų išlikimą po perkrovimo, į sistemą įterpiant kenkėjiškus failus ar dvejetainius failus.

Vienas iš šio metodo privalumų yra tas, kad „dm-verity“ įrenginiai rodomi kaip įprasti blokiniai įrenginiai aplanke „/dev/mapper“ , todėl juos galima prijungti kaip ir bet kurį kitą diską. Pagrindinėje failų sistemoje (ext4, EROFS, squashfs ir kt.) viskas atrodo standartiškai, tačiau kiekviena skaitymo operacija filtruojama per „verity“ kriptografinį filtrą.

Kodėl tai būtina: kenkėjiška programa su root ir patikimu paleidimu

Tokiose sistemose kaip „Android“ programos ar dvejetainiai failai, įgiję root teises , gali geriau pasislėpti nei aptikimo sistemos . Turėdami daugiau leidimų nei antivirusinės ar saugos priemonės, jie gali „meluoti“ apie failus, procesus ar konfigūracijas, todėl juos sunkiau aptikti ir pašalinti.

Neturėdamas tokio mechanizmo kaip „dm-verity“, užpuolikas gali modifikuoti sistemos dvejetainius failus, bibliotekas ar įkrovos scenarijus, kad užtikrintų failų išlikimą , taip neleisdamas failų vientisumo tikrinimo įrankiams aptikti pakeitimų; kitaip tariant, jie išliks net ir išjungus bei vėl įjungus įrenginį. Tai klasikinis nuolatinių rootkit'ų košmaras.

„dm-verity“ veikia kaip sistemos pamatų sargas: branduolys priima kaip galiojančius tik tuos blokus, kurie atitinka laukiamą maišą iš patvirtinimo medžio . Jei kas nors pakeitė sistemos skaidinį be leidimo, maišos nebeatitiks, ir branduolys tai aptiks, kai tik bandys nuskaityti pakeistus duomenis.

Kaip dm-verity veikia viduje

Pagrindinė idėja paprasta, bet veiksminga: įrenginyje hierarchiškai visiems blokams kuriamas kriptografinis maišos kodais (dažniausiai SHA-256) pagrįstas medis . Šis medis saugomas diske ir įprasto naudojimo metu naudojamas kiekvienam nuskaitytam blokui patvirtinti.

Maišos medžio struktūra

Patvirtinimo medis yra suskirstytas į sluoksnius. 0 sluoksnyje yra faktiniai duomenys (pvz., ext4/EROFS sistemos atvaizdas), suskirstyti į 4K blokus . Kiekvienam iš šių blokų apskaičiuojama SHA-256 maišos reikšmė (paprastai naudojant atsitiktinę druską, kad būtų apsaugota nuo išankstinio skaičiavimo atakų).

0 sluoksnio maišos yra sujungiamos, kad būtų suformuotas 1 sluoksnis. Tada 1 sluoksnis sugrupuojamas į 4K blokus ir kiekvienam gautam blokui apskaičiuojama SHA-256 maiša , taip sukuriant 2 sluoksnį. Procesas kartojamas sluoksnis po sluoksnio, kol visas maišų rinkinys telpa į vieną bloką; to paskutinio bloko maiša yra šakninė maiša, kuri žymi visą medį.

Kai sluoksnis neužpildo viso bloko, jis papildomas nuliais, kol pasiekia 4K . Taip išvengiama dviprasmybių ir galima aptikti bandymus „apkarpyti“ medį pakeičiant dalis savavališkais duomenimis: numatoma struktūra apima šį žinomą nulių papildymą.

Diske medis saugomas sujungiant lygius nuo viršutinio sluoksnio žemyn (išskyrus 0 duomenų sluoksnį) . Bendras medžio dydis priklauso nuo tikrinamo skaidinio dydžio, tačiau praktiškai jis paprastai yra gana mažas, net ir dideliems sistemos skaidiniams paprastai mažesnis nei 30 MB.

Formato versijos ir maišos algoritmai

Maišos blokų saugojimo formatas pasikeitė. 0 formato versijoje, kurią iš pradžių naudojo „Chromium OS“, skaičiuojant maišą, pabaigoje buvo pridėtas „salt“ elementas, o santraukos buvo saugomos nuolat , likusią bloko dalį užpildant nuliais.

1 versija, rekomenduojama naujesnėms sistemoms, prieš duomenis prideda druskos ir kiekvieną santrauką papildo dviejų laipsniu. Tai pagerina suderinamumą ir atsparumą tam tikrų tipų atakoms ar iškraipymams. „dm-verity“ lentelėje taip pat nurodomas naudojamas algoritmas (sha1, sha256 ir kt.), nors šiais laikais pagrįstai galima naudoti SHA-256.

Žingsnis po žingsnio šakninio maišos skaičiavimas

Jei norite medį kurti rankiniu būdu, bendra schema aiški. Pirmiausia pasirenkate atsitiktinę druskos reikšmę šešioliktainiu formatu, padalijate vaizdą į 4K blokus ir kiekvienam blokui apskaičiuojate jos druskos SHA-256 . Šios maišos sudaro pirmąjį „loginį“ lygį virš duomenų.

Toliau maišos kodai jungiami, kol užpildomi 4K blokai ; jei nepakanka vietos, pridedami nuliai. Kiekvienas gautas blokas taip pat maišomas naudojant SHA-256, kad būtų suformuotas kitas medžio lygis. Šis „maišos ant maišų“ procesas kartojamas tol, kol lieka tik viena maiša: šakninė maiša.

Praktiškai tokie įrankiai kaip „cryptsetup/veritysetup“ atlieka visus šiuos skaičiavimus ir tiesiogiai generuoja medžio failą („verity.bin“) ir šakninę maišos reikšmę („roothash“) , paruoštus naudoti „dm-verity“ lentelėje arba pasirašytuose metaduomenyse.

dm-verity lentelė: aprašymas, ką ir kaip tikrinti

Kad branduolys galėtų naudoti „dm-verity“, jam reikia tikslaus aprašymo, kur yra duomenys, kur yra maišos medis ir kokius parametrus naudoti. Šis aprašymas yra „dm-verity“ lentelė – parametrų eilutė, kurią įrenginių žymėtojas interpretuoja kurdamas patikrintą loginį įrenginį.

Tipinėje supaprastintoje versijoje apibrėžimą galima suprasti taip:

<atspindėjimo pavadinimas> <duomenų įrenginys> <duomenų bloko dydis> <maišos bloko dydis> <vaizdo dydis blokais> <maišos_pradžia> <šakninė maiša> <salt>

Svarbiausi laukai dm-verity lentelėje paprastai yra:

• dev: įrenginys, kuriame yra tikrinami duomenys (pavyzdžiui, /dev/sdXN skaidinys arba pagrindinė: antrinė failų pora).
• maišos_devĮrenginys, kuriame saugomas maišos medis; jis gali būti toks pat kaip „dev“, jei tik „hash_start“ nurodo už patikrintų duomenų diapazono ribų.
• duomenų_bloko_dydisduomenų bloko dydis baitais, paprastai 4096.
• maišos_bloko_dydisMaišos bloko dydis, jis taip pat paprastai yra 4096.
• duomenų_blokų_skaičius: apsaugotų duomenų blokų skaičius.
• maišos_pradžios_blokas: poslinkis blokais nuo įrenginio pradžios iki maišos medžio pradžios.
• algoritmasmaišos algoritmas (sha256 yra faktinis standartas).
• santrauka (šakninė maiša): medžio šakninio bloko maišos kodas, išreikštas šešioliktainiu formatu; tai patikimas „inkaras“.
• druska: druska, naudojama skaičiuojant maišas, taip pat šešioliktainiu formatu.

Be šių pagrindinių laukų, yra ir pasirenkamų parametrų, kurie reguliuoja, kaip sistema reaguoja į gedimus ar klaidas . Pavyzdžiui, galite nurodyti, kad gedimo atveju sistema turėtų būti paleista iš naujo, sukelti paniką, būti ignoruojama ir tik registruojama arba kad FEC atkūrimas būtų aktyvuotas prieš gedimą.

Išplėstinės lentelės parinktys: iškraipymas, FEC ir našumas

„dm-verity“ apima profiliavimo elgsenos žymių rinkinį. „ignore_corruption“ leidžia tęsti skaitymą net ir aptikus sugadinimą, tačiau palieka pėdsaką žurnaluose , o tai naudinga aplinkose, kuriose prieinamumas yra svarbesnis už griežtą vientisumą.

Griežtesnio vykdymo užtikrinimo tikslais „restart_on_corruption`“ arba „panic_on_corruption`“ priverčia sistemą paleisti iš naujo arba sukelti paniką, kai bloko patikra nepavyksta . Panašūs variantai egzistuoja ir įvesties/išvesties klaidoms („restart_on_error`“, „panic_on_error`“). Taip pat yra parinktis „ignore_zero_blocks“, kuri netikrina blokų, kurie turėtų būti lygūs nuliui, ir grąžina nulius tiesiogiai.

Sistemose, kuriose įdiegta tiesioginė korekcija, „use_fec_from_device“ kartu su „fec_roots“, „fec_blocks“ ir „fec_start“ leidžia naudoti Reed-Solomon kodus . Naudojant FEC, nepavykus patikrinimui, galima bandyti atkurti bloką naudojant perteklinę informaciją prieš jį atsisakant.

Kitos parinktys, pvz., „check_at_most_once“, leidžia kiekvieną bloką patikrinti tik pirmą kartą prie jo prisijungus , taip sumažinant išlaidas, tačiau neaptinkant realių modifikacijų; tai kompromisas tarp saugumo ir našumo. Tokios žymės kaip „root_hash_sig_key_desc“ leidžia branduoliui patvirtinti šakninės maišos PKCS7 parašą naudojant raktų žiede saugomus raktus.

Parašas, metaduomenys ir „Verity Magic“ numeris

Kad viskas būtų logiška, šakninės maišos reikšmė turi būti patikima. Klasikinėje „Android“ versijoje viešasis raktas yra įtrauktas į įkrovos skaidinį, o gamintojas yra atsakingas už jo išorinį patikrinimą . Šis raktas naudojamas šakninės maišos arba „dm-verity“ lentelės parašui patvirtinti, užtikrinant, kad maišos medis nebuvo pakeistas.

„Verity“ metaduomenys apibendrina šią informaciją. 32K bloke yra magiškasis skaičius, versija, parašas, lentelės ilgis ir turinys bei nulinis užpildymas . Ši kontroliuojama struktūra leidžia vienareikšmiškai rasti ir patvirtinti metaduomenis.

Tipiniai šių metaduomenų laukai apima:

• Magiškas skaičiusFiksuota reikšmė 0xb001b001, naudojama tokių komponentų kaip fs_mgr, kad atpažintų, jog tai galiojantis „Verity“ blokas.
• VersijaŠiuo metu 0, jis naudojamas formato pakeitimams įvesti ateityje.
• Įmonė: „dm-verity“ lentelės parašas, paprastai PKCS1.5 su RSA-2048 (256 baitų) raktu.
• Stalo ilgisŽemiau saugomos „dm-verity“ lentelės dydis baitais.
• Tabla: pati serializuota „dm-verity“ lentelė.
• Pildymasnuliai, kol bus užbaigti 32 000 bloko baitų.

Jei analizuojant sistemos atvaizdo pabaigą magiškasis skaičius nerandamas, laikoma, kad skaidinys nėra paruoštas tikrinimui, ir tikrinimo procesas neaktyvuojamas . Tai neleidžia, pavyzdžiui, laikyti skaidinio patikrintu, kai jis nėra patikrintas.

„Android“ sistemoje „fs_mgr“ ir „fstab“ failas kontroliuoja, kurie skaidiniai yra tikrinami . Tiesiog pridėkite patvirtinimo žymę (pvz., „verify“ „fs_mgr“ žymėse) ir įdėkite atitinkamą viešąjį raktą į /boot/verity_key, kad suaktyvintumėte visapusišką patvirtinimo srautą.

Kaip tai susiję su patvirtintu startuoliu

„dm-verity“ būtų mažai naudingas, jei užpuolikas galėtų įterpti modifikuotą branduolį arba įkrovos tvarkyklę, kuri priima bet ką. Štai kodėl mobiliuosiuose įrenginiuose ir saugiose platformose šakninis maišos kodas ir „dm-verity“ lentelė yra pasitikėjimo grandinės, kuri prasideda aparatinės įrangos lygmeniu, dalis.

Paprastai gamintojas įrenginyje įrašo viešąjį raktą. Šis raktas patvirtina pirmojo įkrovos įkroviklio parašą, kuris savo ruožtu patvirtina kitą lygį – programos įkrovos įkroviklį ir galiausiai branduolio atvaizdą . Tada patvirtintas branduolys perima valdymą ir, naudodamas „dm-verity“, išplečia šį pasitikėjimą sistemos skaidiniui.

Šiuolaikinėse „Android“ sistemose su AVB („Android Verified Boot 2.0“) įkrovos įkrovos programa integruoja „libavb“ ir nuskaito maišos medžio aprašus iš skirsnių arba „vbmeta“ . Naudodama šią informaciją, ji sukuria „dm-verity“ parametrus ir perduoda juos branduoliui per komandinę eilutę kartu su instrukcijomis, pavyzdžiui, ar yra FEC, ką daryti sugadinimo atveju ir pan.

„dm-verity“ sistemoje „Android“: sistemos kaip root, AVB ir gedimų pranešimai

„Android“ jau daugelį metų naudoja „dm-verity“. Nuo „Android 4.4“ versijos jis naudojamas kaip patvirtinto paleidimo pagrindas, o nuo „Android 10“ ir vėlesnių versijų „system-as-root“ dizainas tiesiogiai integruoja „rootfs“ į „system.img“ , taip panaikinant daugelį klasikinių prijungimo būdų ir reikalaujant, kad „dm-verity“ būtų tvarkoma nuo pirmojo etapo inicijavimo.

Naudojant sistemos kaip root ir šiuolaikinius OTA atnaujinimus, sistemos skaidinys paprastai yra skirtas tik skaitymui ir apsaugotas patvirtintu maišos medžiu . Branduolys jį mato per „dm-verity“ įrenginį, skaidriai „Android“ viršutiniam sluoksniui.

A/B lizdų, vbmeta ir „dm-verity corruption“ klaidos

Įrenginiuose su A/B schema gana lengva suklysti. Jei atliekate „flash“ įkrovos arba „vbmeta“ atkūrimą nesuderindami šakninės maišos ir tikrojo sistemos skaidinio medžio, tipiškas rezultatas yra baisus pranešimas „dm-verity sugadinimas, jūsų įrenginys nepatikimas“.

Norint apeiti patvirtinimą, yra tokių komandų kaip „fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img“ arba, kai kuriems gamintojams, „fastboot oem disable_dm_verity“. Tačiau būkite atsargūs: tai išjungia patvirtintą paleidimą ir panaikina vientisumo garantijas , net jei jums pavyksta paleisti sistemą be jokių erzinančių pranešimų.

„Švarus“ būdas tai išspręsti – užtikrinti, kad sistemos, įkrovos ir „vbmeta“ atvaizdai būtų suderinti vienas su kitu , iš naujo generuoti (arba atkurti) „verity“ medį ir atnaujinti parašus arba deskriptorius taip, kad numatoma šakninė maiša atitiktų faktinę. Tik tokiu būdu galima išlaikyti pasitikėjimo grandinę nesigriebiant pavojingų gudrybių.

Ryšys su TWRP, atrakinta įkrovos įkrovos programa ir modifikacijomis

Realiame pasaulyje daugelis žmonių susiduria su „dm-verity“ diegdami ROM, modifikuotus branduolius arba suteikdami root teises savo įrenginiams. Norint eksperimentuoti su TWRP, „flash“ programine įranga arba įdiegti modifikacijas, paprastai reikalingas atrakintas įkrovos tvarkytuvas, nes patikrintas paleidimas neleidžia paleisti iš nepasirašytų įkrovos atvaizdų.

Kai kurios procedūros rekomenduoja, pavyzdžiui, pirmiausia įdiegti konkrečią programinę-aparatinę įrangą, paleisti kompiuterį iš naujo į įkrovos tvarkyklės režimą ir vykdyti tokias komandas kaip „fastboot oem disable_dm_verity“, po to „fastboot oem enable_dm_verity“ , o tada įdiegti naujesnę programinę-aparatinę įrangą. Šių veiksmų tikslas – „atstatyti“ „verity“ būseną, kad nauji atvaizdai būtų priimami be iškraipymo klaidų.

Jei po gedimų ar mirksinčių klaidų po kiekvieno perkrovimo pradedate matyti pranešimus „dm-verity corruption“, patartina patikrinti, ar skaidinių sistema nėra fiziškai pažeista ir ar naudojami atvaizdai atitinka jūsų modelį . Kartais paprastas modemo, įkrovos ir sistemos programinės įrangos neatitikimas gali sutrikdyti patikrintą įkrovos procesą.

„dm-verity“ „Linux“ staliniuose kompiuteriuose ir serveriuose („systemd“, „veritysetup“)

„dm-verity“ nėra išskirtinė „Android“ sistema. Šiuolaikinėse „Linux“ distribucijose, ypač su „systemd“, ji tampa populiari kaip didelio patikimumo, tik skaitymui skirtų šakninių sistemų pagrindas , panašiai kaip veikia kai kurie maršrutizatoriai, įrenginiai ar medijos įrenginiai.

Įprastas šakninio serverio prijungimas naudojant „dm-verity“ apima: šakninį atvaizdą arba skaidinį, failą, kuriame yra „verity“ medis (verity.bin), šakninio serverio maišos reikšmę, „systemd-veritysetup“ vienetus ir atitinkamus branduolio eilutės parametrus . Pasirinktinai, siekiant dar labiau apsaugoti sistemą, pridedamas pasirašytas UKI (vieningas branduolio atvaizdas) ir saugus paleidimas.

Padalijimo schema ir failų sistema

Įprasta rekomendacija yra rezervuoti konkretų skaidinį maišos kodams. Įprastą išdėstymą sudaro: EFI skaidinys (ESP), XBOOTLDR skaidinys UKI, šakninis skaidinys (su šifravimu arba be jo), VERITY skaidinys medžiui ir pasirinktinai rašomi /home ir /var skaidiniai.

Vietoj klasikinio „ext4“ root teisėms, EROFS yra labai įdomus pasirinkimas : jis sukurtas tik skaitymui, puikiai veikia su „flash“ ir SSD diskais ir iš karto palaiko lz4 glaudinimą. Neatsitiktinai jis plačiai naudojamas „Android“ telefonuose kartu su „dm-verity“.

Failai, kuriuos reikia įrašyti, ir įprasti gudrybės

Jei šakninis katalogas prijungtas kaip skirtas tik skaitymui, reikia atidžiai apsvarstyti, kuriuos failus reikia redaguoti. Daugelis programų tikisi rašyti į /etc, /var ar panašius kelius . Užuot padarius /etc visiškai rašomą, efektyviau perkelti tik būtinus failus į /var/etc ir simboliškai susieti su jais iš /etc.

Pavyzdžiui, „NetworkManager“ ryšius galima perkelti į /var/etc/NetworkManager/system-connections ir palikti simbolinę nuorodą /etc/NetworkManager/system-connections. Tai nepažeidžia nekintamo šakninio katalogo dizaino, tačiau konfigūracijas, kurias reikia pakeisti, vis tiek galima modifikuoti.

Norėdami sužinoti, kas iš tikrųjų rašoma paleidimo ir vykdymo metu, galite naudoti „dracut-overlayroot“, kuris prijungia „tmpfs“ perdangą prie šakninio katalogo ir registruoja visus faktinius įrašus aplanke „/run/overlayroot/u“ . Panaudoję sistemą kurį laiką, tiesiog patikrinkite tą katalogą, kad pamatytumėte, ką reikia perkelti iš patvirtinto šakninio katalogo.

„Arch Linux“ sistemoje taip pat įprasta perkelti „pacman“ duomenų bazę į /usr/lib/pacman, o talpyklą – į /var/lib/pacman , kad šakninis atvaizdas visada atspindėtų „uždarytą“ sistemos būseną, o sinchronizavimo ir atnaujinimo operacijos būtų atliekamos rašymo srityse.

„Verity“ kūrimas ir įkrovos proceso konfigūravimas naudojant „systemd“

Tipinė darbo eiga Linux sistemoje, kurioje norima naudoti „dm-verity“ root teisėmis, būtų tokia:

• Paleiskite iš gyvos aplinkos ir prijunkite šakninį katalogą kaip skirtą tik skaitymui., kai sistema bus palikta tiksliai tokioje būsenoje, kokią norite „užšaldyti“.
• Paleiskite komandą `veritysetup format root-device verity-device`, kad sugeneruotumėte maišos medį ir šakninę maišą.Komanda paprastai atspausdina eilutę su šakniniu maišos kodu, kuris išsaugomas faile (pavyzdžiui, roothash.txt).
• Patikrinkite susiejimą atidarydami „veritysetup“, sukurdami patikrintą /dev/mapper/root ir jį prijungdami, kad patikrintumėte, ar viskas veikia.

Toliau reikia pakoreguoti branduolio komandinę eilutę. Su „systemd“ naudojame tokius parametrus kaip „systemd.verity=1“, „roothash=…“, „systemd.verity_root_data=…“ ir „systemd.verity_root_hash=…“ , taip pat tokias parinktis kaip „systemd.verity_root_options=restart-on-corruption“ arba „panic-on-corruption“, priklausomai nuo norimo kietumo lygio.

Jei naudojamas UKI, visi šie parametrai integruojami į kernel.efi atvaizdą, kuris pasirašomas ir paleidžiamas naudojant „Secure Boot“ . Tai neleidžia niekam keisti roothash'o komandinėje eilutėje nepažeidžiant parašo, taip išlaikant pasitikėjimo modelį.

Saugus įkrovimas, šifravimas ir TPM: kaip suderinti dalis

„dm-verity“ garantuoja tik vientisumą, o ne konfidencialumą. Duomenis galima peržiūrėti, jei jie nėra užšifruoti, tačiau jų negalima pakeisti neaptikus . Todėl jis dažnai derinamas su šifravimu (LUKS) ir TPM, siekiant apsaugoti raktus.

Įprasta strategija – susieti LUKS iššifravimo raktus su konkrečiais TPM PKR naudojant „systemd-cryptenroll“ (pavyzdžiui, PKR 0, 1, 5 ir 7), kad pakeitus programinę-aparatinę įrangą, skaidinio išdėstymą arba saugaus įkrovimo būseną raktai taptų negaliojantys. Tai neleidžia užpuolikui išjungti saugaus įkrovimo, kad būtų įdiegtas branduolys, ignoruojantis tikrumą, tuo pačiu metu nenutraukiant iššifravimo grandinės.

Jei naudojama „systemd-boot“, įkrovos įkrovos programa išmatuoja kernel.efi atvaizdą PCR 4. Jei šis matavimas pasikeičia, susiję raktai neatskleidžiami ir užšifruotas skaidinys neatidaromas. Tai dar viena grandis, užtikrinanti, kad branduolys, initramfs ir cmdline (įskaitant roothash) nebuvo pakeisti.

Naudojimas už šakninio katalogo ribų: kiti skaidiniai, perdangos ir atnaujinimai

Nors šakninio skaidinio apsauga yra labiausiai paplitusi praktika, „dm-verity“ galima taikyti ir kitiems skaidiniams, kurie prijungiami paleidžiant sistemą . Sistemose, naudojančiose „systemd“, šie papildomi skaidiniai aprašomi /etc/ veritytab faile ir konfigūruojami automatiškai.

Tačiau patvirtintas nešakninis skaidinys yra mažiau saugus: jį galima gana lengvai nuskaityti/įrašyti į šakninį skaidinį, o šakninis vartotojas gali jame išjungti „Verity“ . Nepaisant to, jis naudingas duomenims, kuriuos norite stebėti, arba kitur įdiegtiems tik skaitymui skirtiems atvaizdams.

Kalbant apie atnaujinimus, patvirtintas tik skaitymui skirtas šakninis vartotojas keičia požiūrį. Administratorius nebeturi vykdyti „pacman -Syu“ ar panašių komandų gamybinėje šakninėje sistemoje ; vietoj to generuojami nauji sistemos atvaizdai kartu su atitinkamais „verity“ medžiais ir diegiami transakciniu būdu.

Tam yra kelios strategijos: naudoti tokius įrankius kaip „systemd-sysupdate“ ir „systemd-repart“, kad būtų galima atsisiųsti ir įdiegti naujus atvaizdus , ​​arba sukurti A/B schemą su dviem šakniniais ir dviem „Verity“ skaidiniais, kur atnaujinate neaktyvų skaidinį, o tada apsikeičiate vaidmenimis.

Norėdami didesnio lankstumo, galite prijungti patvirtintą šakninį katalogą kaip žemesnį „OverlayFS“ kataloge, o viršutinį sluoksnį – „tmpfs“ arba diske . Tokiu būdu pakeitimai taikomi viršutiniam sluoksniui, tačiau bazinis sluoksnis išlieka patvirtintas atvaizdas. Galite netgi pasirinkti pasirenkamą arba laikiną išsaugojimą (pvz., systemd.volatile=overlay), kad turėtumėte „vienkartinius seansus“.

Darbalaukio pasaulyje tokios technologijos kaip „Flatpak“ puikiai atitinka šią filosofiją , nes jos įdiegia ir atnaujina programas /var ir /home aplankuose neliesdamos šakninio katalogo, apsaugoto „Verity“. Tai palaiko nekintamą bazinę sistemą ir leidžia programas valdyti nepriklausomai.

Visa ši ekosistema paverčia „dm-verity“ daug daugiau nei branduolio retenybę: tai yra nekintamų, mobilių ir įterptųjų sistemų, kurios visada turi būti paleidžiamos žinomoje būsenoje, aptikdamos bet kokį atminties manipuliavimą, kertinis akmuo , ir integruojasi su patikrintu paleidimu, saugiu paleidimu, šifravimu ir TPM, kad pasiūlytų modernų saugumo modelį neprarandant per daug našumo ar lankstumo.