Mikä on dm-verity ja miten se suojaa järjestelmän eheyttä?

Jos työskentelet Androidin, Linuxin tai sulautettujen järjestelmien parissa, olet luultavasti nähnyt viestejä, kuten "dm-verity corruption", tai kuullut verified bootista, AVB:stä tai Secure Bootista. Kaiken tämän takana on keskeinen ytimen komponentti: dm-verity, mekanismi, joka on suunniteltu varmistamaan, että tiedostojärjestelmää ei ole peukaloitu laitteen ollessa käynnissä tai uudelleenkäynnistysten välillä.

Se saattaa vaikuttaa matalan tason ongelmalta, mutta se vaikuttaa itse asiassa jokapäiväisiin asioihin, kuten estämään puhelimesi järjestelmäosioon piilotettujen haittaohjelmien pääsyn tai varmistamaan, että reititin tai "suljettu" palvelin käynnistyy aina samaan luotettavaan tilaan. dm-verity käyttää SHA-256-hajautuspuuta ja kryptografisia allekirjoituksia varmistaakseen lohko lohkolta, että levyllä olevat tiedot ovat edelleen sitä, mitä niiden pitäisi olla . Jos jokin ei täsmää, ydin voi palauttaa lukuvirheitä, käynnistää tietokoneen uudelleen tai jopa panikoida välttääkseen epäilyttävän koodin suorittamisen.

Mikä on dm-verity ja minkä ongelman se ratkaisee?

`dm-verity` on Linux-ytimen `device-mapper`-alijärjestelmän kohde, joka mahdollistaa lohkolaitteen eheyden reaaliaikaisen tarkistamisen. Tämä lohkolaite on tyypillisesti juuritiedostojärjestelmän tai kriittisen osion (esim. `/system` Androidilla) sisältävä osio tai levykuva. Sen sijaan, että levyä luettaisiin "sokkoisesti", jokainen käytetty lohko tarkistetaan kryptografisesti ennalta laskettua hajautuspuuta vasten.

Androidissa versiosta 4.4 lähtien ja monissa nykyaikaisissa Linux-jakeluissa dm-verity on ollut verified bootin perusta : se varmistaa, että järjestelmäosio on täsmälleen sama kuin levykuvan luontihetkellä. Tämä vaikeuttaa rootkitin tai muun haittaohjelman pysymistä järjestelmässä uudelleenkäynnistyksen jälkeen lisäämällä siihen haitallisia tiedostoja tai binäärejä.

Yksi tämän lähestymistavan eduista on, että dm-verity-laitteet näkyvät normaaleina lohkolaitteina /dev/mapper-hakemistossa , jolloin ne voidaan liittää kuten mikä tahansa muu levy. Pohjana olevalle tiedostojärjestelmälle (ext4, EROFS, squashfs jne.) kaikki näyttää vakiolta, mutta jokainen lukutoiminto suodatetaan verityn kryptografisen suodattimen läpi.

Miksi se on tarpeen: ​​haittaohjelmat pääkäyttäjänä ja luotettavalla käynnistyksellä

Androidin kaltaisissa järjestelmissä pääkäyttäjän oikeudet saaneet sovellukset tai binäärit voivat piiloutua paremmin kuin tunnistusjärjestelmät . Jos niillä on enemmän käyttöoikeuksia kuin virustorjunta- tai tietoturvatyökaluilla, ne voivat "valehtella" tiedostoista, prosesseista tai määrityksistä, mikä vaikeuttaa niiden havaitsemista ja poistamista.

Ilman dm-verityn kaltaista mekanismia hyökkääjä voi muokata järjestelmän binäärejä, kirjastoja tai käynnistysskriptejä pysyvyyden saavuttamiseksi , mikä estää tiedostojen eheyden tarkistustyökaluja havaitsemasta muutoksia. Toisin sanoen tiedostot säilyvät, vaikka laite sammutettaisiin ja käynnistetään uudelleen. Tämä on pysyvien rootkit-hyökkäysten klassinen painajainen.

dm-verity toimii järjestelmän perustan vartijana: ydin hyväksyy kelvollisiksi vain ne lohkot, jotka vastaavat odotettua tarkistuspuun hajautusarvoa . Jos joku on muuttanut järjestelmäosiota ilman lupaa, tiivisteet eivät enää täsmää, ja ydin havaitsee tämän heti, kun se yrittää lukea muokattua dataa.

Miten dm-verity toimii sisäisesti

Perusajatuksena on yksinkertainen mutta tehokas: laitteen kaikkien lohkojen päälle rakennetaan hierarkkisesti tiivisteiden (yleensä SHA-256) kryptografinen puu. Tämä puu tallennetaan levylle ja normaalikäytössä sitä käytetään jokaisen luetun lohkon validointiin.

Hajautuspuun rakenne

Vahvistuspuu on rakennettu tasoihin. Taso 0 sisältää varsinaisen datan (esim. ext4/EROFS-järjestelmäkuvan), joka on jaettu 4 kt:n lohkoihin . Jokaiselle näistä lohkoista lasketaan SHA-256-tiiviste (yleensä satunnaisella suola-arvolla suojaamaan laskentaa edeltäviltä hyökkäyksiltä).

Kerroksen 0 tiivisteet ketjutetaan yhteen muodostaen kerroksen 1. Kerros 1 ryhmitellään sitten 4 kilotavun lohkoihin ja jokaiselle tuloksena olevalle lohkolle lasketaan SHA-256-tiiviste , jolloin syntyy kerros 2. Prosessi toistetaan kerros kerrokselta, kunnes koko tiivistejoukko mahtuu yhteen lohkoon; viimeisen lohkon tiiviste on juuritiiviste, joka edustaa koko puuta.

Kun taso ei täytä koko lohkoa, se täytetään nollilla, kunnes se saavuttaa 4 kt:n rajan . Tämä välttää epäselvyyksiä ja mahdollistaa puun "trimmaamis"yritysten havaitsemisen korvaamalla osia mielivaltaisella tiedolla: odotettu rakenne sisältää tämän tunnetun nollien täydennyksen.

Levyllä puu tallennetaan yhdistämällä tasoja ylimmästä kerroksesta alaspäin (lukuun ottamatta tietokerrosta 0) . Puun kokonaiskoko vaihtelee tarkistettavan osion koon mukaan, mutta käytännössä se on yleensä melko pieni, tyypillisesti alle 30 Mt jopa suurilla järjestelmäosioilla.

Formaattiversiot ja hash-algoritmit

Tiivistelohkojen tallennusmuoto on kehittynyt. Alun perin Chromium OS:n käyttämässä muodossa versio 0 lisäsi suolan loppuun laskettaessa tiivistettä ja tallennti tiivisteet jatkuvasti täyttäen loput lohkosta nollilla.

Versio 1, jota suositellaan uudemmille järjestelmille, lisää tiivisteeseen suolaa ennen dataa ja täydentää jokaisen tiivisteen kahden potenssiin. Tämä parantaa yhdenmukaisuutta ja kestävyyttä tietyntyyppisiä hyökkäyksiä tai korruptiota vastaan. dm-verity-taulukko osoittaa myös käytetyn algoritmin (sha1, sha256 jne.), vaikka nykyään on järkevää käyttää SHA-256:ta.

Juurihajautuksen vaiheittainen laskeminen

Jos haluat rakentaa puun manuaalisesti, yleinen kaava on selkeä. Ensin valitset satunnaisen suola-algoritmin heksadesimaalimuodossa, jaat kuvan 4 kt:n lohkoihin ja lasket kullekin lohkolle sen suolatun SHA-256:n . Nämä tiivisteet muodostavat ensimmäisen "loogisen" tason datan yläpuolella.

Seuraavaksi tiivisteitä ketjutetaan, kunnes 4 kt lohkoa on täytetty ; jos tilaa ei ole riittävästi, lisätään nollia. Jokainen tuloksena oleva lohko tiivistetään myös SHA-256-algoritmilla puun seuraavan tason muodostamiseksi. Tätä "tiiviste tiivisteiden päälle" -prosessia toistetaan, kunnes jäljellä on vain yksi tiiviste: juuritiiviste.

Käytännön toteutuksissa työkalut, kuten cryptsetup/veritysetup, hoitavat kaikki nämä laskelmat ja luovat suoraan puutiedoston (verity.bin) ja juurihajautusarvon (roothash) , jotka ovat valmiita käytettäväksi dm-verity-taulukossa tai allekirjoitetuissa metatiedoissa.

dm-verity-taulukko: kuvaus siitä, mitä ja miten tarkistetaan

Jotta ydin voisi käyttää dm-verity-metodia, se tarvitsee tarkan kuvauksen datan sijainnista, hajautuspuun sijainnista ja käytettävistä parametreista. Tämä kuvaus on dm-verity-taulukko, parametririvi, jonka laitekartoittaja tulkitsee luodessaan varmennettua loogista laitetta.

Tyypillisessä yksinkertaistetussa versiossa määritelmä voidaan nähdä seuraavasti:

<kartoituksen nimi> <tietolaite> <tietolohkon koko> <hajautuslohkon koko> <kuvan koko lohkoina> <hajautusaloitus> <root-hajautus> <salt>

Dm-verity-taulukon tärkeimmät kentät ovat yleensä:

• dev: laite, joka sisältää tarkistettavat tiedot (esimerkiksi /dev/sdXN-osio tai major:minor-pari).
• hash_dev: laite, joka tallentaa hajautuspuun; se voi olla sama kuin dev, kunhan hash_start osoittaa varmennetun datan alueen ulkopuolelle.
• datalohkon_koko: datalohkon koko tavuina, tyypillisesti 4096.
• hash_block_size: tiivisteiden lohkokoko, se on yleensä myös 4096.
• datalohkojen_määrä: suojattavien datalohkojen lukumäärä.
• hash_aloituslohko: lohkoina mitattu siirtymä laitteen alusta hajautuspuun alkuun.
• algoritmihajautusalgoritmi (sha256 on tosiasiallinen standardi).
• tiiviste (juurihajautus): puun juurilohkon tiiviste (hash) heksadesimaalimuodossa; se on luotettu ”ankkuri”.
• suolaa: suola, jota käytetään tiivisteiden laskennassa, myös heksadesimaalimuodossa.

Näiden peruskenttien lisäksi on olemassa valinnaisia ​​parametreja, jotka säätävät järjestelmän reaktioita vioittumiseen tai virheisiin . Voit esimerkiksi määrittää, että vioittumisen sattuessa järjestelmä käynnistyy uudelleen, aiheuttaa paniikkitilan, ohitetaan ja vain kirjataan lokiin tai että FEC-palautus aktivoidaan ennen vikaa.

Taulukon lisäasetukset: korruptio, FEC ja suorituskyky

dm-verity sisältää joukon merkintöjä profilointikäyttäytymistä varten. ignore_corruption sallii lukemisen jatkumisen, vaikka vioittumista havaittaisiin, mutta jättää jäljen lokeihin , mikä on hyödyllinen ympäristöissä, joissa saatavuus on etusijalla tiukkaan eheyteen nähden.

Tiukemman valvonnan saavuttamiseksi `restart_on_corruption` tai `panic_on_corruption` pakottavat uudelleenkäynnistyksen tai paniikin, kun lohkon vahvistus epäonnistuu . Samanlaisia ​​​​muunnelmia on olemassa I/O-virheille (`restart_on_error`, `panic_on_error`). Käytettävissä on myös `ignore_zero_blocks`-asetus, joka välttää nolliksi odotettujen lohkojen varmentamisen ja palauttaa nollia suoraan.

Järjestelmissä, joissa on käytössä eteenpäin korjaus, `use_fec_from_device` yhdessä `fec_roots`-, `fec_blocks`- ja `fec_start`-muuttujien kanssa mahdollistavat Reed-Solomon-koodien käytön . FEC:n avulla varmennusvirheen sattuessa lohko voidaan yrittää rekonstruoida käyttämällä redundantteja tietoja ennen sen hylkäämistä.

Muut asetukset, kuten `check_at_most_once`, sallivat jokaisen lohkon tarkistamisen vain ensimmäisellä käyttökerralla , mikä vähentää yleiskuluja mutta jättää reaaliaikaiset muutokset havaitsematta. Kyseessä on kompromissi turvallisuuden ja suorituskyvyn välillä. `root_hash_sig_key_desc`-kaltaiset liput mahdollistavat ytimen validoida juurihajautuksen PKCS7-allekirjoituksen käyttämällä avainrenkaassa tallennettuja avaimia.

Allekirjoitus, metatiedot ja verity magic -numero

Jotta kaikki olisi järkevää, juurihajautusarvon on oltava luotettava. Klassisessa Androidissa käynnistysosioon sisältyy julkinen avain, ja valmistaja on vastuussa sen ulkoisesta varmentamisesta . Tätä avainta käytetään juurihajautusarvon tai dm-verity-taulukon allekirjoituksen validointiin varmistaen, että hajautuspuuta ei ole muutettu.

Verityn metatiedot kiteyttävät nämä tiedot. 32 kilotavun lohko sisältää taikanumeron, version, allekirjoituksen, taulukon pituuden ja sisällön sekä tyhjän täyttöalueen . Tämä hallittu rakenne mahdollistaa metatietojen paikantamisen ja validoinnin yksiselitteisesti.

Tyypillisiä tämän metadatan kenttiä ovat:

• Maaginen numeroKiinteä arvo 0xb001b001, jota komponentit, kuten fs_mgr, käyttävät tunnistaakseen, että kyseessä on kelvollinen verity-lohko.
• versio: tällä hetkellä 0, sitä käytetään muotomuutosten tekemiseen tulevaisuudessa.
• Yritysdm-verity-taulukon allekirjoitus, yleensä PKCS1.5 ja RSA-2048 (256 tavua) -avain.
• Pöydän pituusAlla olevan dm-verity-taulukon koko tavuina.
• Tabla: itse sarjoitettu dm-verity-taulukko.
• täytenollia, kunnes lohkon 32 000 tavua on suoritettu.

Jos taikalukua ei löydy järjestelmäkuvan loppua analysoitaessa, oletetaan, että osio ei ole valmis varmennukseen, eikä varmennusprosessia ole aktivoitu . Tämä estää esimerkiksi osion käsittelyn varmennettuna, vaikka se ei ole.

Androidissa fs_mgr ja fstab-tiedosto ohjaavat, mitkä osiot vahvistetaan . Lisää vain vahvistuslippu (esimerkiksi "verify" fs_mgr-lippuihin) ja sijoita sopiva julkinen avain kansioon /boot/verity_key aktivoidaksesi kokonaisvaltaisen vahvistusprosessin.

Miten se linkittyy vahvistettuun startup-yritykseen

dm-verity-komennosta ei olisi juurikaan hyötyä, jos hyökkääjä voisi lisätä muokatun ytimen tai käynnistyslataimen, joka hyväksyy mitä tahansa. Siksi mobiililaitteilla ja suojatuilla alustoilla juurihajautus ja dm-verity-taulukko ovat osa luottamusketjua, joka alkaa laitteistotasolla.

Yleensä valmistaja polttaa julkisen avaimen laitteeseen. Tämä avain vahvistaa ensimmäisen käynnistyslataimen allekirjoituksen, joka puolestaan ​​vahvistaa seuraavan tason, sovelluksen käynnistyslataimen , ja lopuksi kernel-kuvan . Tästä eteenpäin vahvistettu kernel ottaa hallinnan ja käyttää dm-verity-komentoa laajentaakseen luottamusta järjestelmäosioon.

Nykyaikaisissa AVB:tä (Android Verified Boot 2.0) käyttävissä Android-järjestelmissä käynnistyslatain sisältää libavb:n ja lukee hashtree-kuvaukset osioista tai vbmeta- tiedostosta. Näiden tietojen avulla se muodostaa dm-verity-parametrit ja välittää ne ytimelle komentorivin kautta yhdessä ohjeiden kanssa, kuten onko FEC läsnä, mitä tehdä vioittumisen sattuessa ja niin edelleen.

dm-verity Androidilla: järjestelmä root-käyttäjänä, AVB ja vioittumisviestit

Android on luottanut dm-verity-komennon käyttöön vuosia. Android 4.4:stä lähtien sitä on käytetty varmennetun käynnistyksen perustana, ja Android 10:stä eteenpäin system-as-root-rakenne integroi rootfs:n suoraan system.img-tiedostoon , mikä poistaa monia klassisia liitäntöjä ja vaatii dm-verityn käsittelyn ensimmäisen vaiheen käynnistyksestä.

Järjestelmä-root- ja nykyaikaisissa OTA-päivityksissä järjestelmäosio on tyypillisesti vain luku -tilassa ja suojattu varmennetulla hashtree-tiedostolla . Ydin tarkastelee sitä dm-verity-laitteen kautta, läpinäkyvästi Androidin ylemmälle kerrokselle.

Paikat A/B, vbmeta ja “dm-verity corruption” -virheet

A/B-järjestelmää käyttävissä laitteissa on melko helppo mennä pieleen. Jos flash-käynnistys tai vbmeta-tiedostot päivitetään ilman, että ne vastaavat roothash-tiedostoa ja varsinaista järjestelmäosiopuuta, tyypillinen tulos on pelätty viesti ”dm-verity corruption, your device is not trusted”.

Vahvistuksen voi ohittaa komennoilla, kuten `fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img` tai joillakin valmistajilla `fastboot oem disable_dm_verity`. Ole kuitenkin varovainen: tämä poistaa käytöstä varmennetun käynnistyksen ja eliminoi eheystakuut , vaikka onnistuisitkin käynnistymään ilman ärsyttäviä viestejä.

"Puhdas" tapa korjata tämä on varmistaa, että järjestelmä-, käynnistys- ja vbmeta-kuvat ovat yhdenmukaisia ​​keskenään , luoda (tai palauttaa) verity-puu uudelleen ja päivittää allekirjoitukset tai deskriptorit siten, että odotettu juurihajautus vastaa todellista. Vain tällä tavoin voit ylläpitää luottamusketjua turvautumatta vaarallisiin temppuihin.

Suhde TWRP:hen, lukitsemattomaan käynnistyslataimeen ja modeihin

Todellisessa maailmassa monet ihmiset kohtaavat dm-verity-komennon asentaessaan ROMeja, muokaillessaan ytimiä tai roottaaessaan laitteitaan. TWRP:n, flash-laiteohjelmiston tai modien asentamisen kokeilemiseen tarvitaan yleensä lukitsematon käynnistyslataaja, koska vahvistettu käynnistys estää käynnistyksen allekirjoittamattomista käynnistyskuvista.

Joissakin menetelmissä suositellaan esimerkiksi ensin tietyn laiteohjelmiston flash-asennusta, uudelleenkäynnistystä käynnistyslataajatilassa ja komentojen, kuten ”fastboot oem disable_dm_verity”, suorittamista, ja sen jälkeen ”fastboot oem enable_dm_verity” , ja sen jälkeen uudemman laiteohjelmiston asentamista. Näiden vaiheiden tarkoituksena on ”nollata” Verity-tila, jotta uudet levykuvat hyväksytään ilman vioittumisvirheitä.

Jos kaatumisten tai vilkkuvien virheiden jälkeen alat nähdä "dm-verity corruption" -ilmoituksia joka uudelleenkäynnistyksen yhteydessä, on viisasta tarkistaa, että osiojärjestelmä ei ole fyysisesti vaurioitunut ja että käyttämäsi levykuvat ovat oikeita mallillesi . Joskus yksinkertainen ero modeemin, käynnistyksen ja järjestelmän laiteohjelmiston välillä voi sotkea varmennetun käynnistysprosessin.

dm-verity Linux-työasemilla ja -palvelimilla (systemd, veritysetup)

dm-verity ei ole vain Android-käyttöjärjestelmä. Nykyaikaisissa Linux-jakeluissa, erityisesti systemd:n ​​kanssa, siitä on tulossa suosittu pohjana korkean luotettavuuden omaaville, vain luku -tilassa oleville juurijärjestelmille , aivan kuten jotkut reitittimet, laitteet tai mediasovittimet toimivat.

Tyypillinen dm-verity-komentoa käyttävä juuriliitos sisältää: juurilevynkuvan tai -osion, tiedoston, joka sisältää verity-puun (verity.bin), juuritiedoston tiivistearvon, systemd-veritysetup-yksiköt ja sopivat ytimen riviparametrit . Valinnaisesti järjestelmään lisätään allekirjoitettu UKI (Unified Kernel Image) ja Secure Boot -ominaisuus järjestelmän suojaamiseksi entisestään.

Osiointijärjestelmä ja tiedostojärjestelmä

Yleinen suositus on varata tietty osio tiivisteille. Yleinen asettelu koostuu: EFI-osiosta (ESP), XBOOTLDR-osiosta UKI-osioille, juuriosiosta (salauksella tai ilman), VERITY-osiosta puulle ja valinnaisesti kirjoitettavista /home- ja /var-osioista.

Klassisen ext4-tiedostojärjestelmän sijaan root-käyttäjänä EROFS on erittäin mielenkiintoinen vaihtoehto : se on rakenteensa puolesta vain luku -tilassa, sillä on erinomainen suorituskyky flash- ja SSD- levyillä ja se tukee lz4-pakkausta suoraan pakkauksesta. Ei ole sattumaa, että sitä käytetään laajalti Android-puhelimissa yhdessä dm-verityn kanssa.

Kirjoittamista vaativat tiedostot ja yleisiä vinkkejä

Jos juurihakemisto on liitetty vain luku -tilassa, sinun on harkittava huolellisesti, mitkä tiedostot on voitava olla muokattavissa. Monet ohjelmat odottavat voivansa kirjoittaa hakemistoon /etc, /var tai vastaaviin polkuihin . Sen sijaan, että /etc olisi täysin kirjoitettava, on tehokkaampaa siirtää vain tarvittavat tiedostot hakemistoon /var/etc ja linkittää niihin symbolisesti hakemistosta /etc.

Esimerkiksi NetworkManager-yhteydet voidaan siirtää hakemistoon /var/etc/NetworkManager/system-connections ja jättää symbolinen linkki hakemistoon /etc/NetworkManager/system-connections. Tämä ei riko muuttumatonta juurirakennetta, mutta muutettavia kokoonpanoja voidaan silti muokata.

Voit selvittää, mitä käynnistyksen ja suorituksen aikana todellisuudessa kirjoitetaan, käyttämällä `dracut-overlayroot`-komentoa, joka liittää tmpfs-päällekkäistiedoston juurihakemiston päälle ja kirjaa kaikki todelliset kirjoitukset `/run/overlayroot/u`-hakemistoon . Kun järjestelmää on käytetty jonkin aikaa, tarkista kyseinen hakemisto nähdäksesi, mitä varmennetusta juurihakemistosta on siirrettävä.

Arch Linuxissa on myös yleistä siirtää pacman-tietokanta hakemistoon /usr/lib/pacman ja välimuisti hakemistoon /var/lib/pacman , jotta juuritiedosto heijastaa aina järjestelmän "sinetöityä" tilaa, kun taas synkronointi ja päivitystoiminnot tehdään kirjoitettavilla alueilla.

Verityn luominen ja käynnistysprosessin määrittäminen systemd:llä

Tyypillinen työnkulku Linux-järjestelmässä, jossa halutaan käyttää dm-verity-komentoa pääkäyttäjänä, olisi seuraava:

• Käynnistä live-ympäristöstä ja liitä juurihakemisto vain luku -tilassa., kun järjestelmä on jätetty täsmälleen haluamaasi tilaan "jäädytettynä".
• Suorita `veritysetup format root-device verity-device` luodaksesi tiivistepuun ja juuritiivisteen.Komento yleensä tulostaa rivin, jossa on juurihajautus (Root Hash), joka on tallennettu tiedostoon (esimerkiksi roothash.txt).
• Testaa yhdistämismääritystä veritysetup-komennolla, luomalla varmennetun /dev/mapper/root-tiedoston ja liittämällä sen varmistaaksesi, että kaikki toimii.

Seuraavaksi meidän on muutettava ytimen komentoriviä. systemd:n ​​kanssa käytämme parametreja, kuten systemd.verity=1, roothash=…, systemd.verity_root_data=… ja systemd.verity_root_hash=… , sekä asetuksia, kuten systemd.verity_root_options=restart-on-corruption tai panic-on-corruption halutusta kovuudesta riippuen.

Jos käytetään UKI:tä, kaikki nämä parametrit integroidaan kernel.efi-tiedostoon, joka allekirjoitetaan ja käynnistetään Secure Bootilla . Tämä estää ketään muuttamasta roothashia komentorivillä mitätöimättä allekirjoitusta, säilyttäen siten luottamusmallin.

Secure Boot, salaus ja TPM: palasten yhdistäminen

dm-verity takaa vain eheyden, ei luottamuksellisuutta. Tietoja voidaan tarkastella, jos niitä ei ole salattu, mutta niitä ei voida muuttaa havaitsematta . Siksi sitä käytetään usein yhdessä salauksen (LUKS) ja TPM:n kanssa avainten suojaamiseksi.

Yleinen strategia on ankkuroida LUKS-salausavaimet tiettyihin TPM-PCR-avaimiin systemd-cryptenroll-komennolla (esimerkiksi PCR-avaimet 0, 1, 5 ja 7), jolloin laiteohjelmiston, osioasettelun tai Secure Boot -tilan muuttaminen mitätöi avaimet. Tämä estää hyökkääjää poistamasta Secure Boot -toimintoa käytöstä ja asentamasta totuusarvot ohittavaa ydintä katkaisematta samalla salauksen purkuketjua.

Jos systemd-boot-käskyä käytetään, käynnistyslataaja mittaa kernel.efi-kuvan PCR 4:ssä. Jos tämä mittaustulos muuttuu, siihen liittyviä avaimia ei vapauteta eikä salattua osiota avata. Tämä on toinen linkki sen varmistamisessa, että ydintä, initramfs:ää ja cmdline-komentosarjaa (mukaan lukien roothash) ei ole muutettu.

Käyttö juuren ulkopuolella: muut osiot, päällekkäisrakenteet ja päivitykset

Vaikka juuriosion suojaaminen on yleisin käytäntö, dm-verity -komentoa voidaan soveltaa muihin käynnistyksen yhteydessä liitettävään osioon . Systemd:tä käyttävissä järjestelmissä nämä lisäosiot on kuvattu tiedostossa /etc/ veritytab ja ne konfiguroidaan automaattisesti.

Vahvistettu ei-root-osio on kuitenkin vähemmän turvallinen: sitä voidaan lukea/kirjoittaa root-osioon suhteellisen helposti, ja root-käyttäjä voi poistaa Verityn käytöstä siinä . Silti se on hyödyllinen datalle, jota haluat valvoa, tai muualle asennetuille vain luku -tilassa oleville levykuville.

Päivitysten osalta vahvistettu, vain luku -oikeuksilla varustettu pääkäyttäjä muuttaa ajattelutapaa. Ylläpitäjän ei enää odoteta suorittavan "pacman -Syu"- tai vastaavia komentoja tuotantopääkäyttäjällä ; sen sijaan uudet järjestelmäkuvat luodaan vastaavine Verity-puineen ja otetaan käyttöön transaktionaalisesti.

Tähän on useita strategioita: käyttää työkaluja, kuten systemd-sysupdate ja systemd-repart, uusien levykuvien lataamiseen ja flash-asentamiseen tai tukea A/B-järjestelmää, jossa on kaksi juuriosiota ja kaksi Verity-osiota, joissa päivität passiivisen osion ja vaihdat sitten rooleja.

Suuremman joustavuuden saavuttamiseksi voit liittää varmennetun juurikansion alemmaksi hakemistoksi OverlayFS:ään ja ylemmän kerroksen tmpfs-kansioon tai levylle . Tällä tavoin muutokset otetaan käyttöön ylemmässä kerroksessa, mutta peruskerroksena pysyy varmennettu levykuva. Voit jopa valita valinnaisen tai tilapäisen säilyvyyden (esim. systemd.volatile=overlay), jos haluat käyttää "kertakäyttöisiä istuntoja".

Työpöytämaailmassa Flatpakin kaltaiset teknologiat sopivat hyvin tähän filosofiaan , sillä ne asentavat ja päivittävät sovelluksia /var- ja /home-hakemistoihin koskematta Verityn suojaamaan juurihakemistoon. Tämä ylläpitää muuttumatonta perusjärjestelmää ja mahdollistaa sovellusten itsenäisen hallinnan.

Koko tämä ekosysteemi tekee dm-veritystä paljon enemmän kuin vain ytimen kuriositeetin: se on muuttumattomien, mobiilien ja sulautettujen järjestelmien kulmakivi, joiden on aina käynnistyttävä tunnettuun tilaan ja havaittava kaikki tallennustilan manipuloinnit . Se integroituu myös varmennettuun käynnistykseen, suojattuun käynnistykseen, salaukseen ja TPM:ään tarjotakseen modernin tietoturvamallin tinkimättä liikaa suorituskyvystä tai joustavuudesta.