Шта је dm-verity и како штити интегритет система?

Ако радите са Андроидом, Линуксом или уграђеним системима, вероватно сте видели поруке попут „dm-verity corruption“ или сте чули за verified boot, AVB или Secure Boot. Иза свега тога стоји кључни део језгра: dm-verity, механизам дизајниран да осигура да систем датотека није неовлашћено мењанни док је уређај укључен нити између поновних покретања.

Можда делује као мали проблем, али заправо утиче на свакодневне ствари, попут тога што ваш телефон не одржава малваре скривен у системској партицији или да је рутер или „затворени“ сервер увек почиње у истом поузданом стању. dm-verity се ослања на SHA-256 хеш стабло и криптографске потписе како би проверио, блок по блок, да ли су подаци на диску и даље онакви какви би требало да буду.А ако нешто не пође по злу, језгро може вратити грешке читања, поново покренути рачунар или чак паничити како би избегло даље извршавање сумњивог кода.

Шта је dm-verity и који проблем решава?

dm-verity је циљ подсистема за мапирање уређаја у Линуксовом кернелу који омогућава проверу интегритета блок уређаја у реалном времену.Ово је обично партиција или слика која садржи коренски фајл систем или критичну партицију (нпр. /system на Андроиду). Уместо „слепо“ читања диска, сваки приступљени блок се криптографски проверава у односу на унапред израчунато хеш стабло.

На Андроиду од верзије 4.4 и на многим модерним Линукс дистрибуцијама, dm-verity је основа верификованог покретањаОво осигурава да је системска партиција потпуно иста као када је слика креирана. Због тога је руткиту или другој врсти злонамерног софтвера тешко да опстане након поновног покретања система убризгавањем злонамерних датотека или бинарних датотека у систем.

Једна од предности овог приступа је то што dm-verity уређаји се појављују као нормални блок уређаји у /dev/mapperОво им омогућава да се монтирају као да су само још један диск. За горе наведени фајл систем (ext4, EROFS, squashfs, итд.) све делује стандардно, али свака операција читања пролази кроз Verity криптографски филтер.

Зашто је то неопходно: злонамерни софтвер са root приступом и поузданим покретањем система

У системима као што је Андроид, апликације или бинарне датотеке које добијају привилегије корен Могу се боље сакрити него сами системи за детекцију.Имајући више дозвола него антивирусни или безбедносни алати, могу да „лажу“ о датотекама, процесима или конфигурацијама, што их чини тежим за откривање и брисање.

Без механизма као што је dm-verity, Нападач може да измени системске бинарне датотеке, библиотеке или скрипте за покретање система како би постигао перзистентност.и тиме спречити алате који омогућавају проверите интегритет датотеке Они детектују промену; то јест, остају чак и ако искључите и поново укључите уређај. То је класична ноћна мора упорних руткитова.

dm-verity делује као чувар у основи система: Језгро прихвата као валидне само оне блокове који испуњавају очекивани хеш стабла провереАко је неко ручно изменио системску партицију, хешеви се више неће подударати, а језгро ће то детектовати чим покуша да прочита измењене податке.

Како dm-verity функционише интерно

Основна идеја је једноставна, али моћна: Криптографско хеш стабло (обично SHA-256) је изграђено преко свих блокова уређаја.хијерархијски. Ово стабло се чува на диску и, током нормалне употребе, користи се за валидацију сваког прочитаног блока.

Структура хеш стабла

Верификационо стабло је формирано по нивоима. Слој 0 садржи стварне податке (нпр. ext4/EROFS слику система), подељене на блокове од 4K.За сваки од ових блокова, израчунава се SHA-256 хеш (обично са случајном сољу како би се ојачали напади пре израчунавања).

Хешеви у слоју 0 су спајани да би формирали слој 1. Слој 1 се прегруписује у блокове од 4K и за сваки резултујући блок се израчунава SHA-256 хеш.производећи слој 2. Процес се понавља слој по слој док се цео скуп хешева не уклопи у један блок; хеш тог последњег блока је коренски хеш, који представља цело стабло.

Када слој не попуњава цео блок, Попуњава се нулама док не достигне 4KОво избегава двосмислености и омогућава откривање покушаја „сечења“ стабла заменом делова произвољним подацима: очекивана структура укључује то познато попуњавање нулама.

На диску, Стабло се чува спајањем нивоа од највишег слоја надоле (искључујући слој података 0)Укупна величина стабла варира у зависности од величине проверене партиције, али у пракси је обично прилично мала, типично мања од 30 MB чак и за велике системске партиције.

Верзије формата и хеш алгоритми

Формат у којем се чувају хеш блокови се развијао. Верзија 0 формата, коју је првобитно користио Chromium OS, додавала је со на крају приликом израчунавања хеша и континуирано чувала дајџесте., попуњавајући остатак блока нулама.

Верзија 1, препоручена за нове системе, ставља сол испред података приликом израчунавања хеша и допуњује сваки дајџ на степен два. Ово побољшава поравнање и робусност против одређених врста напада или оштећења. Табела dm-verity такође показује коришћени алгоритам (sha1, sha256, итд.), иако је данас разумно користити SHA-256.

Корак-по-корак израчунавање коренског хеша

Ако желите да направите дрво ручно, општа шема је јасна. Прво, бира се случајна со у хексадецималном формату, слика се дели на блокове од 4K, и за сваки блок се израчунава његов SHA-256 алгоритм.Ови хешеви формирају први „логички“ ниво на врху података.

Онда, Хешеви се спајају док се не попуне 4K блоковиАко нема довољно простора, попуњава се нулама. Сваки резултујући блок се такође хешира помоћу SHA-256 алгоритма да би се формирао следећи ниво стабла. Овај процес „хеширања хешева“ се понавља све док не остане један хеш: коренски хеш.

У практичним имплементацијама, алати попут cryptsetup/veritysetup обрађују сва ова прорачуна и директно генеришу датотека стабла (verity.bin) и вредност коренског хеша (roothash), спреман за употребу у dm-verity табели или у потписаним метаподацима.

dm-verity табела: опис шта и како проверити

Да би језгро могло да користи dm-verity, потребан му је тачан опис где се налазе подаци, где се налази хеш стабло и које параметре треба користити. Тај опис је dm-verity табела, линија параметара које мапер уређаја интерпретира приликом креирања верификованог логичког уређаја..

Ин а типична поједностављена верзијаДефиниција се може посматрати као:

Најважнија поља dm-verity табела обично укључује:

• дев: уређај који садржи податке које треба верификовати (на пример, партиција /dev/sdXN или пар major:minor).
• хеш_развој: уређај који чува хеш стабло; може бити исто што и dev, све док hash_start показује ван опсега верификованих података.
• величина_блока_података: величина блока података у бајтовима, обично 4096.
• величина_хеш_блока: величина блока за хешеве, обично је такође 4096.
• број_блокова_податакаброј блокова података које треба заштитити.
• хеш_почетни_блок: помак у блоковима од почетка уређаја до места где почиње хеш стабло.
• алгоритам: хеш алгоритам (sha256 је де факто стандард).
• дајџест (коренски хеш): хеш коренског блока стабла, изражен у хексадецималном систему; то је поуздано „сидро“.
• соСо се користи при израчунавању хешева, такође у хексадецималном облику.

Поред ових основних области, Постоје опциони параметри који подешавају како систем реагује на оштећења или грешкеНа пример, можете навести да у случају оштећења систем треба поново покренути, да се покрене паника или да се проблем игнорише, само се евидентира на систем. трупциили да је опоравак FEC-а активиран пре квара.

Напредне опције табеле: корупција, FEC и перформансе

dm-verity укључује скуп заставица за понашање профилисања. ignore_corruption омогућава наставак читања чак и ако се открије оштећење, али оставља траг у логовима., корисно у окружењима где је доступност приоритетнија од строгог интегритета.

Ако тражите чврсту руку, `restart_on_corruption` или `panic_on_corruption` приморавају рестарт или панику када блок не успе да се провери.Сличне варијанте постоје за И/О грешке (restart_on_error, panic_on_error). Постоји и опција ignore_zero_blocks која избегава проверу блокова за које се очекује да буду нула и директно враћа нуле.

За системе који интегришу корекцију унапред, `use_fec_from_device` заједно са `fec_roots`, `fec_blocks` и `fec_start` омогућавају употребу Рид-Соломонових кодова.Са FEC-ом, у случају неуспеха верификације, могуће је покушати реконструисати блок користећи редундантне информације пре него што се сматра изгубљеним.

Друге опције, као што је check_at_most_once, Они дозвољавају да се сваки блок верификује само при првом приступу.Ово смањује оптерећење по цену неоткривања активних измена; то је компромис између безбедности и перформанси. Заставице попут `root_hash_sig_key_desc` омогућавају језгру да валидира PKCS7 потпис коренског хеша користећи кључеве сачуване у привеску кључева.

Потпис, метаподаци и магични број верити

Да би све имало смисла, вредност коренског хеша мора бити поуздана. У класичном Андроиду, јавни кључ је укључен у партицију за покретање, а произвођач је одговоран за његову екстерну верификацију.Овај кључ се користи за валидацију потписа коренског хеша или dm-verity табеле, осигуравајући да хеш стабло није измењено.

Веритијеви метаподаци обухватају те информације. Блок од 32 КБ садржи магични број, верзију, потпис, дужину табеле и садржај, плус попуњавање нулама.Ова контролисана структура омогућава лоцирање и валидацију метаподатака без двосмислености.

Типична поља Ови метаподаци укључују:

• Магични број: фиксна вредност 0xb001b001, коју користе компоненте као што је fs_mgr да би препознале да је у питању валидан блок верити.
• Версион: тренутно 0, користи се за увођење промена формата у будућности.
• Компанија: dm-verity потпис табеле, обично PKCS1.5 са RSA-2048 (256 бајтова) кључем.
• Дужина столаВеличина dm-verity табеле сачуване испод у бајтовима.
• Табла: сама серијализована dm-verity табела.
• Пуњено: нуле док се не заврши 32.000 бајтова блока.

Ако се магични број не пронађе приликом анализе краја системске слике, Претпоставља се да партиција није припремљена за верификацију и да процес верификације није активиран.Ово спречава, на пример, третирање партиције као верификоване када она то није.

На Андроид-у, fs_mgr и fstab датотека контролишу које партиције се проверавајуЈедноставно додајте ознаку за потврду (на пример, „verify“ у заставицама fs_mgr) и поставите одговарајући јавни кључ у /boot/verity_key да бисте покренули ток верификације од почетка до краја.

Како се повезује са верификованим стартапом

dm-verity не би био од велике користи ако би нападач могао да убаци модификовано језгро или покретачки програм који прихвата било шта. Стога у мобилни и безбедних платформи, коренски хеш и dm-verity табела су део ланца поверења који почиње у хардвер.

Обично произвођач уграђује јавни кључ на уређај. Тај кључ потврђује потпис првог покретачког програма, који затим проверава следећи ниво, покретачки програм... апликације и коначно, слика језграОдатле, језгро, сада верификовано, преузима контролу и користи dm-verity да прошири то поверење на системску партицију.

На модерном Андроиду са AVB (Android Verified Boot 2.0), Покретач система укључује libavb и чита дескрипторе хеш стабла у партицијама или у vbmetaСа тим информацијама, конструише dm-verity параметре и прослеђује их језгру на линији команде, заједно са упутствима као што су да ли постоји Федерална изборна комисија (FEC), шта треба учинити у случају корупције итд.

dm-verity на Андроиду: поруке о системском приступу као root, AVB и оштећењу

Андроид се годинама ослања на dm-verity. Од Андроида 4.4, користи се као основа за верификовано покретање, а од Андроида 10 па надаље, дизајн system-as-root директно интегрише rootfs у system.img.елиминисање многих класичних подешавања и присиљавање да се dm-verity обрађује из иницијализације прве фазе.

Са системом као кореном и модерним OTA-има, Системска партиција је обично само за читање, заштићена је верификованим хеш стаблом.Језгро га види кроз dm-verity уређај, транспарентно за горњи слој Андроида.

Грешке слотова A/B, vbmeta и „dm-verity corruption“

Код уређаја са А/Б шемом, прилично је лако да нешто изађе из поравнања. Ако флешујете boot или vbmeta без подударања roothash-а и стварног стабла системских партиција, типичан резултат је застрашујућа порука „dm-verity оштећење, вашем уређају се не верује“..

Да бисте заобишли верификацију, постоје команде попут fastboot флеш –disable-verity –disable-verification vbmeta vbmeta.imgили, код неких произвођача, `fastboot oem disable_dm_verity`. Али будите опрезни: Ово онемогућава верификовано покретање и елиминише гаранције интегритета.чак и ако успете да га покренете без досадних порука.

„Чист“ начин да се то поправи укључује Уверите се да су системске, boot и vbmeta слике међусобно усклађене.Регенеришите (или вратите) стабло верити и ажурирајте потписе или дескрипторе тако да очекивани коренски хеш одговара стварном. Само на овај начин можете одржати ланац поверења без Трикови пелигросос.

Веза са TWRP-ом, откључаним бутлоудером и модовима

У стварном свету, многи људи се сусрећу са dm-verity приликом инсталирања ROM-ова, модификованих кернела или рутовања. Да бисте користили TWRP, флешовали фирмвер или инсталирали модове, обично вам је потребан откључан бутлоудер.јер верификовани процес покретања спречава покретање слика које није потписао произвођач.

Постоје процедуре које препоручују, на пример, Прво, флешујте одређени фирмвер, поново покрените систем у бутлоудер и извршите команде као што су „fastboot oem disable_dm_verity“, а затим „fastboot oem enable_dm_verity“а затим инсталирајте новији фирмвер. Ови кораци имају за циљ да „ресетују“ стање Verity-ја тако да се нове слике прихватају без порука о оштећењу.

Ако након падова система или грешака са флешовањем почнете да видите упозорења о „dm-verity corruption“ при сваком поновном покретању, Паметно је проверити да систем партиција нема физичких оштећења и да ли су слике које користите исправне за ваш модел.Понекад једноставна неусклађеност између модема, покретачког софтвера и системског фирмвера може да поремети верификовани процес покретања.

dm-verity на Linux рачунарима и серверима (systemd, veritysetup)

dm-verity није ексклузиван за Андроид. У модерним Линукс дистрибуцијама, посебно са systemd, постаје популаран као основа за коренске системе са високим поверењем и приступом само за читање.веома слично начину на који раде неки рутери, уређаји или медијске кутије.

Типично root монтирање са dm-verity укључује: коренска слика или партиција, датотека која садржи verity стабло (verity.bin), вредност коренске хеш партиције, јединице systemd-veritysetup и одговарајуће параметре линије језграОпционо, додају се потписани UKI (Unified Kernel Image) и Secure Boot како би цео систем био добро заштићен.

Шема партиционисања и систем датотека

Уобичајена препорука је да се резервише одређена партиција за хешеве. Уобичајено коришћени аранжман се састоји од: EFI партиције (ESP), XBOOTLDR партиције за UKI-је, коренске партиције (са или без енкрипције), VERITY партиције за стабло и опционо, партиција на које се може писати /home и /var..

Уместо класичног ext4 за root, EROFS је веома занимљива опцијаДизајниран је само за читање, има веома добре флеш перформансе и ССД и подржава LZ4 компресију одмах по инсталацији. Није случајно што се широко користи на Андроид телефонима у комбинацији са dm-verity.

Датотеке које треба писати и уобичајени трикови

Ако је коренски директоријум монтиран само за читање, потребно је пажљиво размотрити које датотеке треба мењати. Многи програми очекују да пишу у /etc, /var или сличне путање.Уместо да /etc буде потпуно доступан за писање, ефикасније је преместити само оно што је неопходно у /var/etc и симболички га повезати из /etc.

Нпр Конекције NetworkManager-а могу се преместити у /var/etc/NetworkManager/system-connections и оставите симболичку везу из /etc/NetworkManager/system-connections. На овај начин непроменљиви коренски дизајн није нарушен, али конфигурације које треба променити и даље могу бити промењене.

Да бисте открили шта се заправо пише током покретања и извршавања, Можете користити dracut-overlayroot, који монтира tmpfs прекривач преко корена и оставља све стварне уписе забележене у /run/overlayroot/uНакон што неко време користите систем, једноставно прегледајте тај директоријум да бисте сазнали шта треба преместити из верификованог коренског директоријума.

Такође је уобичајено у Arch Linux-у Преместите pacman базу података у /usr/lib/pacman, а кеш меморију у /var/lib/pacmanтако да коренска слика увек одражава „запечаћено“ стање система, док се операције синхронизације и ажурирања изводе у областима у које се може писати.

Креирање Verity-ја и конфигурисање процеса покретања помоћу Systemd-а

Типичан ток На Линук систему који жели да користи dm-verity за root приступ, то би било:

• Покрените систем из живог окружења и монтирајте коренски директоријум као само за читање., када је систем остављен тачно онако како желите да буде „замрзнут“.
• Покрените `veritysetup format root-device verity-device` да бисте генерисали хеш стабло и коренски хеш.Команда обично исписује ред са Root Hash-ом, који је сачуван у датотеци (на пример, roothash.txt).
• Тестирајте мапирање са отвореним veritysetup-ом, креирајући верификовани /dev/mapper/root и монтирајући га да би се проверило да ли све ради.

Затим, потребно је да подесите командну линију кернела. Са systemd-ом, користе се параметри као што су systemd.verity=1, roothash=…, systemd.verity_root_data=… и systemd.verity_root_hash=…., поред опција као што су systemd.verity_root_options=restart-on-corruption или panic-on-corruption у зависности од жељене чврстоће.

Ако се користи УКИ, Сви ови параметри су интегрисани у kernel.efi слику, која је потписана и покренута помоћу Secure Boot-а.Ово спречава некога да промени roothash у командној линији без поништавања потписа, чиме се одржава модел поверења.

Безбедно покретање, шифровање и TPM: спајање делова

dm-verity гарантује само интегритет, а не поверљивост. Подаци се могу прегледати ако нису шифровани, али се не могу мењати без откривања.Зато се често комбинује са енкрипцијом (LUKS) и TPM-ом ради заштите кључева.

Уобичајено коришћена стратегија је Причврстите LUKS кључеве за дешифровање на одређене TPM PCR-ове користећи systemd-cryptenroll (PCR 0, 1, 5, 7, на пример), тако да промена фирмвера, распореда партиције или статуса Secure Boot-а поништава кључеве. Ово спречава нападача да онемогући Secure Boot како би убацио језгро које игнорише verity без истовременог прекидања ланца дешифровања.

Ако се користи systemd-boot, Бутлоудер мери kernel.efi слику у PCR 4Ако се та мера промени, повезани кључеви се не отпуштају и шифрована партиција се не отвара. Ово је још једна карика у ланцу како би се осигурало да језгро, initramfs и cmdline (укључујући roothash) нису измењени.

Употреба ван корена: друге партиције, преклапања и ажурирања

Иако је заштита корена најчешћа пракса, dm-verity се може применити на друге партиције које се монтирају при покретању системаУ системима који користе systemd, ове додатне партиције су описане у /etc/veritytab и конфигурисане [емаил заштићен] аутоматски.

Међутим, верификована партиција без root приступа је мање безбедна: Може се релативно лако опоравити за читање/писање, а root корисник чак може и да онемогући Verity на њему.Упркос томе, корисно је за податке које желите да пратите или за слике само за читање монтиране на другим тачкама.

Што се тиче ажурирања, верификовани root само за читање мења ментални модел. Од администратора се не очекује да изврши „pacman -Syu“ или сличну команду на продукцијском root-у.већ да се генеришу нове слике система, са њиховим одговарајућим стаблима истинитости, и да се распоређују на трансакциони начин.

Постоји неколико стратегија за ово: Користите алате као што су systemd-sysupdate и systemd-repart за преузимање и флешовање нових слика, или предложите А/Б шему са два корена и две истинитости, где ажурирате неактивну партицију, а затим замењујете улоге.

Ако желите нешто флексибилније, Верификовани коренски директоријум може се монтирати као нижи директоријум на OverlayFS-у, са горњим слојем на tmpfs-у или диску.Дакле, промене се примењују на горњи слој, али основа остаје верификована слика. Можете чак да се одлучите за опциону или ефемерну перзистентност (на пример, systemd.volatile=overlay) да бисте имали „сесије за једнократну употребу“.

У свету десктоп рачунара, технологије као што су Флатпак се добро уклапа у ову филозофијуОни инсталирају и ажурирају апликације у /var и /home без додиривања коренског директоријума заштићеног Verity-јем. Ово одржава непроменљиви основни систем и омогућава независно управљање апликацијама.

Читав овај екосистем чини dm-verity много више од пуке куриозитета језгра: То је камен темељац непроменљивих, мобилних и уграђених система који увек морају да почну у познатом стању, откривајући сваку манипулацију складиштењеи интегрише се са верификованим покретањем, безбедним покретањем, енкрипцијом и TPM-ом како би понудио модеран безбедносни модел без жртвовања превише перформанси или флексибилности.