LWN：Fedora中完整性檢驗的又一個方案！

關(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)的，以及今后它們會如何改變 RPM 包的構(gòu)建過程。同樣，最近一個允許系統(tǒng)進行（可選的）遠程驗證（remote attestation）的新提案也同樣遇到了阻力。在這次的討論中提出了幾個跟之前不同的問題。

Background

按照提出新功能提案的一貫做法，F(xiàn)edora 項目經(jīng)理 Ben Cotton 代表功能負責(zé)人 Roberto Sassu 將其發(fā)布到 Fedora 開發(fā)郵件列表。這個修改建議在 Fedora wiki 上也有一份。此項新功能將會使用 Digest Lists Integrity Module (DIGLIM) 功能（Sassu 創(chuàng)建的對內(nèi)核的完整性測量架構(gòu)(IMA)的一個補充）。IMA 需要負責(zé)確保文件內(nèi)容和元數(shù)據(jù)不發(fā)生意外變化是 IMA 的工作，而 DIGLIM 是對 IMA 的一個優(yōu)化。

IMA 有許多不同功能，但其核心是維護管理文件內(nèi)容以及 metadata 的 "摘要（digest）"；這些摘要都是加密哈希值，可以用來可靠地檢測出文件是否發(fā)生了變動。IMA 還可以使用摘要來與系統(tǒng)的可信平臺模塊（TPM，Trusted Platform Module）配合計算出一個數(shù)值，從而證明系統(tǒng)正在運行的系統(tǒng)確定都是已知版本的軟件。這個值可以用來確保系統(tǒng)已被安全啟動，也可被發(fā)送到其他地方用來遠程確定系統(tǒng)的狀態(tài)。

在 IMA 保護之下的每個文件都需要把它的摘要數(shù)值跟文件存儲在一起，這通常是利用了文件系統(tǒng)中的擴展屬性（extended attributes）來完成的。IMA 可以配置成在訪問每個文件之前都先檢查它的摘要是否仍然與之前存下來的值相匹配。如果不在匹配了就馬上拒絕訪問。在文件被評估的時候，它們的摘要可以被提交給 TPM 來擴展一個 Platform Configuration Register（PCR），得出的最終數(shù)值可以跟此時被測量的文件數(shù)據(jù)有關(guān)，但它同時也會根據(jù)訪問順序不同而受到影響。

根據(jù) DIGLIM 的提議（其中包括 Fedora 的 patch 以及 kernel 的 patch），在這個檢查期間會由于并行執(zhí)行而導(dǎo)致 TPM 提供出不同的結(jié)果。也就是說，哪怕用了相同的代碼也可能會給出不同的結(jié)果。DIGLIM 提供了一種機制來獲取所有安裝上來文件的摘要值，然后用它來計算最終的 attestation value。只會用那些尚未被包括在整個 "installation digest" 中的文件才會被用來進一步擴展 TPM 中的 PCR。

它的實現(xiàn)，是通過提供一種機制將已安裝文件的摘要值注冊到內(nèi)核的 "摘要列表（digest list）"中，然后就可以在訪問文件時查閱該列表了。當(dāng)一個文件的摘要出現(xiàn)在了列表中，那么可以認為此文件是沒有改動過的，它的摘要值也不會被提交給 TPM；否則的話就說明該文件已經(jīng)被修改、或者根本沒有包括在摘要列表中，所以訪問可能會被拒絕，文件的摘要也就會被添加到 attestation value 中。后者很可能意味著系統(tǒng)的認證就失敗了。

人們可能會認為，給系統(tǒng)上所安裝的所有文件都添加摘要，會耗費很多內(nèi)存，但事實證明，這個操作的影響非常小。"Fedora 33 的一個按照最小安裝方式的系統(tǒng)中，可執(zhí)行文件和共享庫的摘要庫占用了不到 800k 的內(nèi)存。"

比起為每個文件都計算摘要值，DIGLIM for Fedora 方案會使用那些已經(jīng)計算出來并存儲在 RPM 頭文件中的值來安裝軟件包。這些值都是用 Fedora release 的 GPG 密鑰簽名過的，所以它們可以被信任。內(nèi)核需要能夠驗證 GPG 簽名，這也是 DIGLIM 內(nèi)核功能的一部分。Fedora release 的 GPG 公鑰可以被添加到內(nèi)核鑰匙圈（keyring）從而用來進行驗證。RPM header 數(shù)據(jù)將在啟動過程中很早起的時候就被用來進行處理。"會有一個運行在用戶空間的解析器，在系統(tǒng)啟動早期階段由內(nèi)核發(fā)起執(zhí)行，用來解析 initial ram disk 的/etc/diglim（由一個定制過的 dracut 腳本來包含進來的）中所找到的 RPM header，并將它們上傳給內(nèi)核。"

在某種程度上來說，DIGLIM 的目標(biāo)還是為系統(tǒng)提供一種處理完整性管理的方法，這樣就不再需要發(fā)行版提供商來密切參與這一過程。對于需要 remote attestation （遠程驗證）的系統(tǒng)來說，就可以有辦法實現(xiàn)這個功能，而不需要 Fedora（或任何其他發(fā)行版）來直接管理這個過程。DIGLIM 也可以用來檢測出對已安裝文件的篡改，就像 IMA 一樣，但是根據(jù) kernel patch 中的描述，它完成這個功能的時候性能比起標(biāo)準的 IMA 機制更加好。

這里會需要維護一個相當(dāng)長的 kernel 先決條件清單，"從而有可能讓它們被上游內(nèi)核所接受"。事實上，正如郵件討論中可以看出，除非這些 patch 能夠進入 upstream，否則 Fedora 不太可能采用這個方案。這里有一些額外的工作需要在 Fedora 中完成，從而能在那些希望啟用此功能的系統(tǒng)中正確處理 RPM header，這也是該提案中的另外一半的工作。

Reaction

因為該功能是可選的，并且使用場景相當(dāng)局限，這就意味著它對絕大多數(shù) Fedora 用戶基本沒有影響。這也意味著它對這些用戶是沒有多少作用的，甚至可以說是毫無用處的。一些有顧慮、或者提出了反對意見的人似乎誤解了一點，那就是它只能由用戶來選擇，而不是由發(fā)行方?jīng)Q定。例如，Kevin Kofler 說。"[……]我不明白這個改動所實現(xiàn)的'功能'具體提供了什么不違背自由軟件定義的價值。" 他擔(dān)心會無法安裝由第三方或用戶自己 build 出來的軟件。

但是，正如 Mattia Verga 所說，這個方案的意圖完全不是這樣："它并不拒絕用戶安裝任何他們想要的軟件，它是為了防止那些不需要的、不請自來的、惡意的軟件在未經(jīng)用戶（管理員）批準的情況下就被安裝進來。" 然而，Kofler 擔(dān)心這樣做會慢慢變成 iOS 式的軟件來源集中控制的情況，這顯然與自由軟件的理想是相悖的。但似乎很少有人贊同這種想法。Michel Alexandre Salim 看到的是與 Fedora 的目標(biāo)更加一致：

如果有這樣的東西被發(fā)布和提供的話，我希望 Fedora 能對自己設(shè)個規(guī)定，就像是 SELinux 的 "targeted" policy 一樣：保護 Fedora 提供的 RPM 不被篡改，并可以讓用戶在此基礎(chǔ)上做任何事情。有一個選項可以完全關(guān)閉它，或者更嚴格地執(zhí)行。

事實上，Sassu 說他在 DIGLIM 上的工作已經(jīng)提供了一個如何處理第三方代碼的例子：

我自己正在使用一個 COPR[Cool Other Package Repo]倉庫來構(gòu)建帶有 DIGLIM patch 的 kernel package。該 kernel 里還包括了由 COPR 為我生成的我個人的 GPG 密鑰。

盡管還沒有決定下來，但很可能 Fedora 內(nèi)核會要包含 Fedora 的官方密鑰，而用戶自己將可以添加新的密鑰（包括來自 COPR 的密鑰）。

在一個比較長的回復(fù)之中，Sassu 試圖減輕對該功能的一些擔(dān)憂和恐懼。"[……]它的主要目標(biāo)是幫助用戶滿足他們的安全需求，并讓他們自己決定要如何做"。他指出，該功能已經(jīng)在基于 Fedora 的 openEuler 發(fā)行版中得到了產(chǎn)品化使用（already in production use），但他也認識到很有必要能讓該功能進入 upstream。Neal Gompa 同意 Fedora 通常 "不在其 Linux 內(nèi)核 build 中包括那些不是來自 upstream 的功能"，但也指出 DIGLIM 可能會是有用的：

我也同意這個功能不太可能影響到人們，因為這個功能在默認情況下不會被啟用。它對于構(gòu)建基于 Fedora 的設(shè)備的人來說會非常有用，這些設(shè)備由于各種原因需要防止篡改。而 Fedora 的衍生產(chǎn)品（如 RHEL/CentOS、Amazon Linux、openEuler 等）也可以從我們集成進來的這個功能中受益，即使我們并沒有默認啟用此功能。

DRM

顯然，TPM 和遠程驗證（remote attestation）可以用在各種數(shù)字版權(quán)管理（DRM）。DRM 在某種程度上被人們稱為 digital restrictions management。Nico Kadel-Garcia 確信，該功能 "除了數(shù)字版權(quán)管理外沒有任何用途"。但 Sassu 指出其實是有其他用途的：

如果你想強制執(zhí)行 IMA measurement policy，那么每次對文件的訪問都會被允許，無論 hash list 有簽名與否。在這種情況下，IMA 將會直接記錄這些未知文件的執(zhí)行情況，而不光是記錄你生成的摘要列表。

IMA measurement list 仍然會保存在你的系統(tǒng)中，除非你決定你的系統(tǒng)需要由一個遠程驗證方來進行遠程驗證。

Kadel-Garcia 堅稱這都是給 DRM 用的，但 Gompa 試圖進一步澄清：

IMA/verity 和 DRM 的區(qū)別在于，前者是在系統(tǒng)所有者的控制之下（在這種情況下，是?你?來控制），而后者則不是。

[……]如果用戶能控制這種能力，會有非常重要的好處。而且，這一切都不是默認開啟的，而是由?你?來自己決定開啟的。

Implementation questions

Zbigniew J?drzejewski-Szmek 對該功能及其實現(xiàn)有一些疑問。具體來說，有人質(zhì)疑是否需要一個由內(nèi)核來運行的用戶空間解析器，但 Sassu 說，這個解析器需要在 init 進程之前運行從而能對 init（及其所有的依賴文件）也利用摘要列表來進行完整性檢查。這是一個雞生蛋蛋生雞的問題，這也從而導(dǎo)致 Sassu 需要確保這個 helper 程序是靜態(tài)鏈接的，這樣在用它添加所有其他的摘要之前，只需要添加這一個文件的摘要就好了。

Lennart Poettering 認為，摘要信息應(yīng)該簡單地提取到一個特殊的 initrd 中，然后傳遞給內(nèi)核。這就會避免把摘要 "上傳" 到內(nèi)核的做法，但是，正如 Sassu 指出的，這就會把內(nèi)核與特定的摘要列表格式綁定起來。Sassu 說，這個功能的最初版本差不多就是這樣實現(xiàn)的：解析器在內(nèi)核中，它從 RPM 頭文件中讀取信息，但每當(dāng)有新的格式需要支持時（例如 Debian deb 文件），內(nèi)核就必須進行改動。

Poettering 也對靜態(tài)鏈接的這個 helper 程序感到不太滿意（他說 "static linking is a mess."），但 Sassu 解釋說這樣可以更容易來啟動完整性檢查：

我認為這種方法是可以自成一體的：啟動 DIGLIM 所需的一切都包含在 kernel-tools-diglim 這個 package 中。在動態(tài)鏈接的情況下，你就還需要處理好所有的共享庫。由于解析器尚未發(fā)揮作用（內(nèi)核還處于 enforcing mode），這樣就需要為每個希望加載的共享庫都生成一個本地格式（在 spec 文件中）的摘要列表。

我喜歡這個事實：只要你有了修改過的內(nèi)核和恰當(dāng)?shù)?GPG 密鑰，以及 kernel-tools-diglim，你就能夠運行 IMA appraisal（評估），而不需要為對其進行管理而做更多的工作。

在 1 月 3 日的 Fedora 工程指導(dǎo)委員會（FESCo）會議上有提出一個問題，就是 DIGLIM 功能跟最近討論的 fs-verity 提案之間的關(guān)系。Sassu 說，主要區(qū)別在于 DIGLIM 是可以直接用現(xiàn)有的 RPM 包及其格式就可以工作了，而 fs-verity 的支持則需要在 RPM header 中為每個文件都增加額外信息：

DIGLIM 采用了 RPM 的現(xiàn)有方案，用一個簽名來驗證 RPM 中所包含的全部文件。由于這種數(shù)據(jù)格式不適合在 Linux 內(nèi)核中使用，因此為了確保 integrity policy，DIGLIM 會提取摘要并將它們添加到存儲在內(nèi)核內(nèi)存中的哈希表中。Enforcement（這里如果說是 security decision 會更加恰當(dāng)）是通過在哈希表中進行查找來實現(xiàn)的。

主要的優(yōu)點是，DIGLIM 不需要對現(xiàn)有的 RPM 做任何改變就可以實現(xiàn)目標(biāo)，提供出參考值。

RPM 的開發(fā)者 Panu Matilainen 很喜歡這個方案：

除了不再需要為每個文件增加數(shù)據(jù)從而使 RPM 變得臃腫之外，這也回避了與 IMA 和 fs-verity 相關(guān)的一些其他問題：那兩個方案都需要一個額外的簽名步驟來提供文件簽名，這也是一個不可忽略的開銷以及復(fù)雜工作，這個方案跟他們不同，文件的哈希值也已經(jīng)用正常的 rpm 級別的簽名就可以覆蓋了（從而受到保護）。

很明顯，DIGLIM 功能不會被 Fedora 采用，除非 DIGLIM 本身被合并到 mainline kernel 中。甚至也許到那時也不會被 Fedora 采用。對 locked-down system 以及 DRM 的擔(dān)憂在某種程度上確實是合理的，但這根本不是 DIGLIM 的目標(biāo)。另一方面，盡管它看起來是一個小眾功能，但它對大多數(shù) Fedora 用戶的影響是可以忽略不計的，這有點像一把雙刃劍。它不會影響大多數(shù)用戶，因為它也不會幫助到他們，以及他們的使用場景。

但是有一些使用場景確實會受益，而 Fedora 中完整性管理（integrity management）的其他競爭方案似乎都更加復(fù)雜。DIGLIM 和 fs-verity 都在 FESCo 的關(guān)注之中，所以我們應(yīng)該很快可以知道結(jié)果。鑒于 fs-verity 方案的侵擾性（intrusiveness），以及 DIGLIM 在 mainline 中的未來命運尚不明確，我們可以基本確定這兩個方案都會至少被推遲到 Fedora 37 的時候。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～