LWN：Fedora中完整性檢驗(yàn)的又一個(gè)方案！
關(guān)注了就能看到更多這么棒的文章哦～
Another Fedora integrity-management proposal
By Jake Edge
January 4, 2022
DeepL assisted translation
https://lwn.net/Articles/880263/
在過去一年多里，F(xiàn)edora 發(fā)行版中的文件完整性管理（File-integrity management）是許多不同功能的提案的主要主題?？傮w來說，這些提案都受到了挑戰(zhàn)，人們懷疑這些功能是否是符合 Fedora 的目標(biāo)的，以及今后它們會(huì)如何改變 RPM 包的構(gòu)建過程。同樣，最近一個(gè)允許系統(tǒng)進(jìn)行（可選的）遠(yuǎn)程驗(yàn)證（remote attestation）的新提案也同樣遇到了阻力。在這次的討論中提出了幾個(gè)跟之前不同的問題。
Background
按照提出新功能提案的一貫做法，F(xiàn)edora 項(xiàng)目經(jīng)理 Ben Cotton 代表功能負(fù)責(zé)人 Roberto Sassu 將其發(fā)布到 Fedora 開發(fā)郵件列表。這個(gè)修改建議在 Fedora wiki 上也有一份。此項(xiàng)新功能將會(huì)使用 Digest Lists Integrity Module (DIGLIM) 功能（Sassu 創(chuàng)建的對(duì)內(nèi)核的完整性測量架構(gòu)(IMA)的一個(gè)補(bǔ)充）。IMA 需要負(fù)責(zé)確保文件內(nèi)容和元數(shù)據(jù)不發(fā)生意外變化是 IMA 的工作，而 DIGLIM 是對(duì) IMA 的一個(gè)優(yōu)化。
IMA 有許多不同功能，但其核心是維護(hù)管理文件內(nèi)容以及 metadata 的 "摘要（digest）"；這些摘要都是加密哈希值，可以用來可靠地檢測出文件是否發(fā)生了變動(dòng)。IMA 還可以使用摘要來與系統(tǒng)的可信平臺(tái)模塊（TPM，Trusted Platform Module）配合計(jì)算出一個(gè)數(shù)值，從而證明系統(tǒng)正在運(yùn)行的系統(tǒng)確定都是已知版本的軟件。這個(gè)值可以用來確保系統(tǒng)已被安全啟動(dòng)，也可被發(fā)送到其他地方用來遠(yuǎn)程確定系統(tǒng)的狀態(tài)。
在 IMA 保護(hù)之下的每個(gè)文件都需要把它的摘要數(shù)值跟文件存儲(chǔ)在一起，這通常是利用了文件系統(tǒng)中的擴(kuò)展屬性（extended attributes）來完成的。IMA 可以配置成在訪問每個(gè)文件之前都先檢查它的摘要是否仍然與之前存下來的值相匹配。如果不在匹配了就馬上拒絕訪問。在文件被評(píng)估的時(shí)候，它們的摘要可以被提交給 TPM 來擴(kuò)展一個(gè) Platform Configuration Register（PCR），得出的最終數(shù)值可以跟此時(shí)被測量的文件數(shù)據(jù)有關(guān)，但它同時(shí)也會(huì)根據(jù)訪問順序不同而受到影響。
根據(jù) DIGLIM 的提議（其中包括 Fedora 的 patch 以及 kernel 的 patch），在這個(gè)檢查期間會(huì)由于并行執(zhí)行而導(dǎo)致 TPM 提供出不同的結(jié)果。也就是說，哪怕用了相同的代碼也可能會(huì)給出不同的結(jié)果。DIGLIM 提供了一種機(jī)制來獲取所有安裝上來文件的摘要值，然后用它來計(jì)算最終的 attestation value。只會(huì)用那些尚未被包括在整個(gè) "installation digest" 中的文件才會(huì)被用來進(jìn)一步擴(kuò)展 TPM 中的 PCR。
它的實(shí)現(xiàn)，是通過提供一種機(jī)制將已安裝文件的摘要值注冊(cè)到內(nèi)核的 "摘要列表（digest list）"中，然后就可以在訪問文件時(shí)查閱該列表了。當(dāng)一個(gè)文件的摘要出現(xiàn)在了列表中，那么可以認(rèn)為此文件是沒有改動(dòng)過的，它的摘要值也不會(huì)被提交給 TPM；否則的話就說明該文件已經(jīng)被修改、或者根本沒有包括在摘要列表中，所以訪問可能會(huì)被拒絕，文件的摘要也就會(huì)被添加到 attestation value 中。后者很可能意味著系統(tǒng)的認(rèn)證就失敗了。
人們可能會(huì)認(rèn)為，給系統(tǒng)上所安裝的所有文件都添加摘要，會(huì)耗費(fèi)很多內(nèi)存，但事實(shí)證明，這個(gè)操作的影響非常小。"Fedora 33 的一個(gè)按照最小安裝方式的系統(tǒng)中，可執(zhí)行文件和共享庫的摘要庫占用了不到 800k 的內(nèi)存。"
比起為每個(gè)文件都計(jì)算摘要值，DIGLIM for Fedora 方案會(huì)使用那些已經(jīng)計(jì)算出來并存儲(chǔ)在 RPM 頭文件中的值來安裝軟件包。這些值都是用 Fedora release 的 GPG 密鑰簽名過的，所以它們可以被信任。內(nèi)核需要能夠驗(yàn)證 GPG 簽名，這也是 DIGLIM 內(nèi)核功能的一部分。Fedora release 的 GPG 公鑰可以被添加到內(nèi)核鑰匙圈（keyring）從而用來進(jìn)行驗(yàn)證。RPM header 數(shù)據(jù)將在啟動(dòng)過程中很早起的時(shí)候就被用來進(jìn)行處理。"會(huì)有一個(gè)運(yùn)行在用戶空間的解析器，在系統(tǒng)啟動(dòng)早期階段由內(nèi)核發(fā)起執(zhí)行，用來解析 initial ram disk 的/etc/diglim（由一個(gè)定制過的 dracut 腳本來包含進(jìn)來的）中所找到的 RPM header，并將它們上傳給內(nèi)核。"
在某種程度上來說，DIGLIM 的目標(biāo)還是為系統(tǒng)提供一種處理完整性管理的方法，這樣就不再需要發(fā)行版提供商來密切參與這一過程。對(duì)于需要 remote attestation （遠(yuǎn)程驗(yàn)證）的系統(tǒng)來說，就可以有辦法實(shí)現(xiàn)這個(gè)功能，而不需要 Fedora（或任何其他發(fā)行版）來直接管理這個(gè)過程。DIGLIM 也可以用來檢測出對(duì)已安裝文件的篡改，就像 IMA 一樣，但是根據(jù) kernel patch 中的描述，它完成這個(gè)功能的時(shí)候性能比起標(biāo)準(zhǔn)的 IMA 機(jī)制更加好。
這里會(huì)需要維護(hù)一個(gè)相當(dāng)長的 kernel 先決條件清單，"從而有可能讓它們被上游內(nèi)核所接受"。事實(shí)上，正如郵件討論中可以看出，除非這些 patch 能夠進(jìn)入 upstream，否則 Fedora 不太可能采用這個(gè)方案。這里有一些額外的工作需要在 Fedora 中完成，從而能在那些希望啟用此功能的系統(tǒng)中正確處理 RPM header，這也是該提案中的另外一半的工作。
Reaction
因?yàn)樵摴δ苁强蛇x的，并且使用場景相當(dāng)局限，這就意味著它對(duì)絕大多數(shù) Fedora 用戶基本沒有影響。這也意味著它對(duì)這些用戶是沒有多少作用的，甚至可以說是毫無用處的。一些有顧慮、或者提出了反對(duì)意見的人似乎誤解了一點(diǎn)，那就是它只能由用戶來選擇，而不是由發(fā)行方?jīng)Q定。例如，Kevin Kofler 說。"[……]我不明白這個(gè)改動(dòng)所實(shí)現(xiàn)的'功能'具體提供了什么不違背自由軟件定義的價(jià)值。" 他擔(dān)心會(huì)無法安裝由第三方或用戶自己 build 出來的軟件。
但是，正如 Mattia Verga 所說，這個(gè)方案的意圖完全不是這樣："它并不拒絕用戶安裝任何他們想要的軟件，它是為了防止那些不需要的、不請(qǐng)自來的、惡意的軟件在未經(jīng)用戶（管理員）批準(zhǔn)的情況下就被安裝進(jìn)來。" 然而，Kofler 擔(dān)心這樣做會(huì)慢慢變成 iOS 式的軟件來源集中控制的情況，這顯然與自由軟件的理想是相悖的。但似乎很少有人贊同這種想法。Michel Alexandre Salim 看到的是與 Fedora 的目標(biāo)更加一致：
如果有這樣的東西被發(fā)布和提供的話，我希望 Fedora 能對(duì)自己設(shè)個(gè)規(guī)定，就像是 SELinux 的 "targeted" policy 一樣：保護(hù) Fedora 提供的 RPM 不被篡改，并可以讓用戶在此基礎(chǔ)上做任何事情。有一個(gè)選項(xiàng)可以完全關(guān)閉它，或者更嚴(yán)格地執(zhí)行。
事實(shí)上，Sassu 說他在 DIGLIM 上的工作已經(jīng)提供了一個(gè)如何處理第三方代碼的例子：
我自己正在使用一個(gè) COPR[Cool Other Package Repo]倉庫來構(gòu)建帶有 DIGLIM patch 的 kernel package。該 kernel 里還包括了由 COPR 為我生成的我個(gè)人的 GPG 密鑰。
盡管還沒有決定下來，但很可能 Fedora 內(nèi)核會(huì)要包含 Fedora 的官方密鑰，而用戶自己將可以添加新的密鑰（包括來自 COPR 的密鑰）。
在一個(gè)比較長的回復(fù)之中，Sassu 試圖減輕對(duì)該功能的一些擔(dān)憂和恐懼。"[……]它的主要目標(biāo)是幫助用戶滿足他們的安全需求，并讓他們自己決定要如何做"。他指出，該功能已經(jīng)在基于 Fedora 的 openEuler 發(fā)行版中得到了產(chǎn)品化使用（already in production use），但他也認(rèn)識(shí)到很有必要能讓該功能進(jìn)入 upstream。Neal Gompa 同意 Fedora 通常 "不在其 Linux 內(nèi)核 build 中包括那些不是來自 upstream 的功能"，但也指出 DIGLIM 可能會(huì)是有用的：
我也同意這個(gè)功能不太可能影響到人們，因?yàn)檫@個(gè)功能在默認(rèn)情況下不會(huì)被啟用。它對(duì)于構(gòu)建基于 Fedora 的設(shè)備的人來說會(huì)非常有用，這些設(shè)備由于各種原因需要防止篡改。而 Fedora 的衍生產(chǎn)品（如 RHEL/CentOS、Amazon Linux、openEuler 等）也可以從我們集成進(jìn)來的這個(gè)功能中受益，即使我們并沒有默認(rèn)啟用此功能。
DRM
顯然，TPM 和遠(yuǎn)程驗(yàn)證（remote attestation）可以用在各種數(shù)字版權(quán)管理（DRM）。DRM 在某種程度上被人們稱為 digital restrictions management。Nico Kadel-Garcia 確信，該功能 "除了數(shù)字版權(quán)管理外沒有任何用途"。但 Sassu 指出其實(shí)是有其他用途的：
如果你想強(qiáng)制執(zhí)行 IMA measurement policy，那么每次對(duì)文件的訪問都會(huì)被允許，無論 hash list 有簽名與否。在這種情況下，IMA 將會(huì)直接記錄這些未知文件的執(zhí)行情況，而不光是記錄你生成的摘要列表。
IMA measurement list 仍然會(huì)保存在你的系統(tǒng)中，除非你決定你的系統(tǒng)需要由一個(gè)遠(yuǎn)程驗(yàn)證方來進(jìn)行遠(yuǎn)程驗(yàn)證。
Kadel-Garcia 堅(jiān)稱這都是給 DRM 用的，但 Gompa 試圖進(jìn)一步澄清：
IMA/verity 和 DRM 的區(qū)別在于，前者是在系統(tǒng)所有者的控制之下（在這種情況下，是?你?來控制），而后者則不是。
[……]如果用戶能控制這種能力，會(huì)有非常重要的好處。而且，這一切都不是默認(rèn)開啟的，而是由?你?來自己決定開啟的。
Implementation questions
Zbigniew J?drzejewski-Szmek 對(duì)該功能及其實(shí)現(xiàn)有一些疑問。具體來說，有人質(zhì)疑是否需要一個(gè)由內(nèi)核來運(yùn)行的用戶空間解析器，但 Sassu 說，這個(gè)解析器需要在 init 進(jìn)程之前運(yùn)行從而能對(duì) init（及其所有的依賴文件）也利用摘要列表來進(jìn)行完整性檢查。這是一個(gè)雞生蛋蛋生雞的問題，這也從而導(dǎo)致 Sassu 需要確保這個(gè) helper 程序是靜態(tài)鏈接的，這樣在用它添加所有其他的摘要之前，只需要添加這一個(gè)文件的摘要就好了。
Lennart Poettering 認(rèn)為，摘要信息應(yīng)該簡單地提取到一個(gè)特殊的 initrd 中，然后傳遞給內(nèi)核。這就會(huì)避免把摘要 "上傳" 到內(nèi)核的做法，但是，正如 Sassu 指出的，這就會(huì)把內(nèi)核與特定的摘要列表格式綁定起來。Sassu 說，這個(gè)功能的最初版本差不多就是這樣實(shí)現(xiàn)的：解析器在內(nèi)核中，它從 RPM 頭文件中讀取信息，但每當(dāng)有新的格式需要支持時(shí)（例如 Debian deb 文件），內(nèi)核就必須進(jìn)行改動(dòng)。
Poettering 也對(duì)靜態(tài)鏈接的這個(gè) helper 程序感到不太滿意（他說 "static linking is a mess."），但 Sassu 解釋說這樣可以更容易來啟動(dòng)完整性檢查：
我認(rèn)為這種方法是可以自成一體的：啟動(dòng) DIGLIM 所需的一切都包含在 kernel-tools-diglim 這個(gè) package 中。在動(dòng)態(tài)鏈接的情況下，你就還需要處理好所有的共享庫。由于解析器尚未發(fā)揮作用（內(nèi)核還處于 enforcing mode），這樣就需要為每個(gè)希望加載的共享庫都生成一個(gè)本地格式（在 spec 文件中）的摘要列表。
我喜歡這個(gè)事實(shí)：只要你有了修改過的內(nèi)核和恰當(dāng)?shù)?GPG 密鑰，以及 kernel-tools-diglim，你就能夠運(yùn)行 IMA appraisal（評(píng)估），而不需要為對(duì)其進(jìn)行管理而做更多的工作。
在 1 月 3 日的 Fedora 工程指導(dǎo)委員會(huì)（FESCo）會(huì)議上有提出一個(gè)問題，就是 DIGLIM 功能跟最近討論的 fs-verity 提案之間的關(guān)系。Sassu 說，主要區(qū)別在于 DIGLIM 是可以直接用現(xiàn)有的 RPM 包及其格式就可以工作了，而 fs-verity 的支持則需要在 RPM header 中為每個(gè)文件都增加額外信息：
DIGLIM 采用了 RPM 的現(xiàn)有方案，用一個(gè)簽名來驗(yàn)證 RPM 中所包含的全部文件。由于這種數(shù)據(jù)格式不適合在 Linux 內(nèi)核中使用，因此為了確保 integrity policy，DIGLIM 會(huì)提取摘要并將它們添加到存儲(chǔ)在內(nèi)核內(nèi)存中的哈希表中。Enforcement（這里如果說是 security decision 會(huì)更加恰當(dāng)）是通過在哈希表中進(jìn)行查找來實(shí)現(xiàn)的。
主要的優(yōu)點(diǎn)是，DIGLIM 不需要對(duì)現(xiàn)有的 RPM 做任何改變就可以實(shí)現(xiàn)目標(biāo)，提供出參考值。
RPM 的開發(fā)者 Panu Matilainen 很喜歡這個(gè)方案：
除了不再需要為每個(gè)文件增加數(shù)據(jù)從而使 RPM 變得臃腫之外，這也回避了與 IMA 和 fs-verity 相關(guān)的一些其他問題：那兩個(gè)方案都需要一個(gè)額外的簽名步驟來提供文件簽名，這也是一個(gè)不可忽略的開銷以及復(fù)雜工作，這個(gè)方案跟他們不同，文件的哈希值也已經(jīng)用正常的 rpm 級(jí)別的簽名就可以覆蓋了（從而受到保護(hù)）。
很明顯，DIGLIM 功能不會(huì)被 Fedora 采用，除非 DIGLIM 本身被合并到 mainline kernel 中。甚至也許到那時(shí)也不會(huì)被 Fedora 采用。對(duì) locked-down system 以及 DRM 的擔(dān)憂在某種程度上確實(shí)是合理的，但這根本不是 DIGLIM 的目標(biāo)。另一方面，盡管它看起來是一個(gè)小眾功能，但它對(duì)大多數(shù) Fedora 用戶的影響是可以忽略不計(jì)的，這有點(diǎn)像一把雙刃劍。它不會(huì)影響大多數(shù)用戶，因?yàn)樗膊粫?huì)幫助到他們，以及他們的使用場景。
但是有一些使用場景確實(shí)會(huì)受益，而 Fedora 中完整性管理（integrity management）的其他競爭方案似乎都更加復(fù)雜。DIGLIM 和 fs-verity 都在 FESCo 的關(guān)注之中，所以我們應(yīng)該很快可以知道結(jié)果。鑒于 fs-verity 方案的侵?jǐn)_性（intrusiveness），以及 DIGLIM 在 mainline 中的未來命運(yùn)尚不明確，我們可以基本確定這兩個(gè)方案都會(huì)至少被推遲到 Fedora 37 的時(shí)候。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～