LWN：能在Fedora 36中加入fs-verity嗎？

關注了就能看到更多這么棒的文章哦～

Adding fs-verity support for Fedora 36?

By Jake Edge
December 14, 2021
DeepL assisted translation
https://lwn.net/Articles/878281/

Fedora 開發(fā)郵件列表中最近在討論向 Fedora 36 的 RPM 包中添加 fs-verity 文件完整性信息的事情。這個功能提供了一種方法來將 RPM 包中的文件安裝為只讀文件，如果這些文件中的數(shù)據(jù)發(fā)生了變化，就不再允許讀取或進行其他操作。該提案的主要應用場景目前并不是很清晰，這也引發(fā)了一些疑問以及討論參與者的質(zhì)疑。

fs-verity and RPM

Fs-verity 是在一些文件系統(tǒng)已經(jīng)支持的一個內(nèi)核功能。它提供了一種方法來讓人可以確認磁盤上的文件的內(nèi)容不會改變。它為每個被保護的文件創(chuàng)建了 Merkle 樹，這個樹中包含了文件中每個數(shù)據(jù)塊的 hash 值。當一個文件被 fs-verity 保護時，它會被標記為只讀屬性，每個讀操作都會檢查讀取的數(shù)據(jù)塊是否與樹中存儲的 hash 值可以匹配得上。如果不匹配的話操作就會失敗。此外，樹本身也可以采用密鑰簽名，從而確保文件系統(tǒng)不會有任何改變，也就是不會發(fā)生直接對塊設備進行操作或者修改映像文件等操作。

Fedora 項目經(jīng)理 Ben Cotton 代表這個功能的作者 Davide Cavalca, Boris Burkov, Filipe Brandenburger, Michel Alexandre Salim, 和 Matthew Almond 來發(fā)布了增加 fs-verity 支持的 Fedora 修改提案。該提案有幾個要點。首先，Koji build system 需要能夠為 RPM 包中的每個文件創(chuàng)建 Merkle 樹并簽名。樹本身不會被添加到 RPM 包中，只有每個文件的簽名過的 top-level hash 數(shù)據(jù)會放在 RPM 包中。

在安裝的時候，RPM 有一個可選的 fs-verity 插件，可以確保安裝 Fedora key，并為其安裝的每個文件都啟用 fs-verity。然后，文件系統(tǒng)將重新計算并建立 Merkle 樹，比對 RPM metadata 中的簽名數(shù)據(jù)來進行檢查，并將這個樹與文件一起存儲下來。此后，對文件的每一次訪問都將根據(jù)這個樹來進行核對，這意味著各種操作（如 read()、mmap()、execve()等）要能正常執(zhí)行的話，磁盤上的數(shù)據(jù)塊就一定沒有變化過。

該提案主要集中在 build 方面。"具體來說，默認安裝和啟用 fs-verity rpm 插件明確不包含在這個提案之內(nèi)。" 在安裝時創(chuàng)建 Merkle 樹的開銷，"根據(jù)經(jīng)驗性測試中沒有看到軟件包的安裝速度有什么顯著降低"，但為每一個 Koji build 都創(chuàng)建 Merkle 樹當然會有一些（不確定的）成本。Merkle 樹只有在啟用 RPM fs-verity 插件的情況下才會被存儲下來，并且使得安裝文件大小增加大約 1/127（0.8%）。如果提案最終被采納的話，所有的 RPM 包都會增加這些額外的簽名過的元數(shù)據(jù)，但是整體來說這個開銷也是基本可以忽略的。"在絕大多數(shù)情況下，我們預計 RPM header packing 的 size 只會增加一點甚至完全沒有增加"。

Reaction

Kevin Fenzi 對該提案有一些問題。他想知道在 build 時會用哪些密鑰來給 Merkle 樹簽名，以及誰會負責修改 RoboSignatory 組件（該組件為 Koji 提供簽名）來完成這些功能。此外，目前只有 ext4、F2FS、以及 Linux 5.15 開始的 Btrfs 才支持 fs-verity。其他文件系統(tǒng)如 XFS 該怎么辦？

Cavalca 回答說，功能開發(fā)者計劃負責 RoboSignatory 的修改，但在代碼 review、testing 和部署（deployment）方面需要大家的一些幫助和建議。他們將研究是否可以使用 Fedora package-signing key：

fs-verity 在軟件包簽名時需要一個 RSA 密鑰/證書對（key/cert pair）來進行文件簽名。在軟件包安裝時，該證書會被加載到相應的內(nèi)核 keyring （密鑰庫）中。在測試的時候，我們一直使用一個專用的密鑰對。我實際上也不確定軟件包簽名密鑰是否被利用來做這個事情，因為它是一個 GPG 密鑰，但這是我們后面打算調(diào)查的方向。

除此之外，如果文件系統(tǒng)本身不支持 fs-verity，那么該插件就會失敗，也就不會具有這個保護功能了。他說，如果有需要的話，也可以針對 XFS 增加 fs-verity 支持。

Josh Boyer 詢問了為 Fedora 添加 fs-verity 支持跟另一個類似的功能（為 RPM 添加 IMA 簽名的提案，被拒絕的部分原因就是因為它對 RPM 大小有影響）。完整性測量架構(IMA，Integrity Measurement Architecture ) 是一個內(nèi)核機制，可用于檢測文件是否被篡改，但 Salim 說，fs-verity 對 RPM size 的影響要比 IMA 小很多。并且我們希望那些不安裝 RPM 插件的用戶也 "基本上不會被這個改動所影響"。該提案中比較了這兩種完整性機制，還認為運行時的影響也更加小一些：

因為 fsverity 是在 block read 操作時進行的，所以它的 runtime cost 運行成本會很?。ㄒ驗樗恍枰炞C正在被訪問的 block 就好），而且它可以確保在任何時間都沒有進行過文件改動。

IMA 的工作方式是將文件作為一個整體進行測量，并在文件被讀取或執(zhí)行時跟簽名進行比較。它的運行時間成本比 fsverity 高（因為它需要一次性驗證整個文件），而且它不能檢測在此之后修改此文件的情況。

該提案還說，IMA 提供了一個很豐富的策略系統(tǒng)（policy system），可以與其他安全機制（如 SELinux）結合起來。在未來將兩者結合起來可能會是有意義的。但是 Boyer 以及其他一些人很希望了解 fs-verity 會給 Fedora 及其使用場景帶來什么好處。Boyer 說，提案中列出的好處在很大程度上都可以由 IMA 來實現(xiàn)，所以他想再聽到更多的解釋。Cavalca 說，這個具體提案 "主要是關于建立必要的基礎設施的"。此外他描述了一個潛在的使用場景：

例如，假如我們將一個應用設備放在了一個不可靠的地方，你可能無法阻止惡意訪問者能觸碰到這臺設備（這可能是一臺服務器，也可能是互聯(lián)網(wǎng)接入點或?qū)W校的一個多媒體信息亭）。在這種情況下，fs-verity 可以用來確保并且保持系統(tǒng)可靠（system trust）性。

Cavalca 繼續(xù)說，與大多數(shù)安全解決方案一樣，fs-verity 不是一個一擊必殺的武器，但它會是一個有價值的方案的一個組成部分：

一旦為某個特定文件啟用了 fs-verity（在 RPM 的情況下，這個動作在軟件包安裝的時候就完成了），它就不能再被禁用，并且該文件就變得無法再進行修改了。人們?nèi)匀豢梢赃M行 rename() 或者 unlink() 等操作（這也是 rpm 在對這個 package 進行升級時用來替換這些文件的必需 API），但其實際內(nèi)容無法被篡改了。

這在哪些情況會有用呢？例如，fs-verity 可以發(fā)現(xiàn)攻擊者在對存儲設備進行 out-of-band 訪問（例如他們從 colo'd 服務器上取出一個硬盤，或從嵌入式設備上取出 SD 卡，或他們采用 liveusb 光盤啟動，或者直接從 host 上來訪問虛擬機的鏡像文件）。

假設這種情況出現(xiàn)了，攻擊者改變了設備上的/bin/ls 文件的幾個 block 數(shù)據(jù)，使其運行惡意代碼。當你再次啟動你的系統(tǒng)時，它將在 exec() 的時候報錯，因為 Merkle 樹的數(shù)據(jù)匹配不上了。

但是，由于攻擊者可以簡單地替換這些文件，或者添加新的文件，所以設計中仍然缺失一部分，正如 Zbigniew J?drzejewski-Szmek 指出的：

如果 fs-verity 驗證使得我無法直接修改或替換 /usr/bin/foo 或 /usr/lib/systemd/system/foo.service，那么如果我直接添加 /etc/systemd/system/foo.service 來做我想做的操作，難道也會被阻止嗎？

他問，是否有 Linux 安全模塊（LSM）可以強制執(zhí)行一些 policy 來確保系統(tǒng)完整性。除此之外，如果攻擊者能夠替換像 /bin/ls 這樣的二進制文件，那么他們也可能會在內(nèi)核 keyring 中添加新的密鑰，使他們的二進制文件能夠通過 fs-verity 檢查：

如果密鑰是從文件系統(tǒng)中加載的，那么我是否可以直接放入一個惡意密鑰，就像每次發(fā)行版升級時也都會發(fā)布一些新的密鑰？

Florian Weimer 提出了另外兩個問題，他認為是 "無法解決的（unsolvable）"。攻擊者可以把來自不相關的 Fedora 軟件包的二進制文件拿進來用，這些文件是已經(jīng)被正確簽名的。或者他們也可以改變系統(tǒng)配置從而在啟動時禁用這個功能。他基于這些問題認為，真正想要這種類型的保護的人不太可能會使用添加到 RPM 文件中的簽名：

在我看來，這兩個無法解決的問題的結合表明，任何想要部署這種功能的人最好使用他們自己的信任根，而這種方法也將包括他們特定版本的密鑰管理。但這也意味著，預先計算的文件簽名對他們來說并不[特別]有用。反正他們在部署前就必須丟棄它們。

Burkov 同意目前功能尚不完善，但他提到 Roberto Sassu 的一封郵件中有提到正在進行一些將 fs-verity 與 IMA 整合的工作，這可能會最終解決其中一些問題。但是，Lennart Poettering 同樣指出了一些當前的 threat model 還完全不清晰的地方，也就是這些保護措施并沒有真正針對 Fedora 用戶可能遇到的問題來設計：

這保護的是文件內(nèi)容，而不是[metadata]，對嗎？如果我今天看到一個啟用了 fs-verity 的 inode，里面有 libssl.so 的數(shù)據(jù)，而且是一個有漏洞的版本，我給它做了一個 hardlink，然后它被替換成一個 fix 版本（名字稍有變化）。那么你打算如何來確保我無法欺騙你用新的名字來加載我的舊文件副本？

[……]對 RPM 包版本之間的 downgrade 操作有任何保護嗎？是否會用什么方式來保護二進制文件和庫文件的組合？我的意思是，我們發(fā)布的程序幾乎全部都是由大量的 ELF 對象組成的，你可能需要對它們的組合進行簽名，但這個 model 看起來完全沒有提供這個功能？

有一些領域需要進一步研究，Burkov 說，但 threat model 并沒有真正確定，因為這個提案只是希望實現(xiàn)基礎功能：

簡短的回答是，這個提案本身并沒有提供 practical threat model （實際針對的威脅模型），我們把它看作是一個支持過程中的一個步驟，也就是需要一個現(xiàn)實 path 來對 rpm 內(nèi)容進行廣泛地簽名驗證。另外，它確實給了水平很高的用戶們一個機會可以自己搭建這樣的東西。

Poettering 對這一提案進一步表示了疑惑，他指出："經(jīng)驗告訴我們，沒有使用者的基礎設施功能通常是行不通的。"。但是，即使解決了這一點，它所提供的保護也不是特別有用。"如果我可以讓 'ping' 和 'poweroff' 的二進制文件都由 Fedora 簽名，但然后交換這兩者那么簽名機制就無法檢測出來了，那為什么還要這樣做？"

還有人提出了其他擔憂。例如，Stephen John Smoogen 出于一些事務性的理由來表示反對。任何改動提案都需要在 Fedora 36 的大規(guī)模 rebuild 之前完成，目前計劃日期是 1 月 19 日。由于假期即將到來，那些需要 review 和對這類更改進行簽字認證的人甚至都不太可能有足夠時間完成這些工作。"即使這些改動是微不足道的，但是這么短的時間窗口要完成這些內(nèi)容還是太緊張了。" 他建議，F(xiàn)edora 37 可能是一個更加現(xiàn)實的目標。

在這個改動的 wiki 頁面中已經(jīng)更新了更多的內(nèi)容，包括對討論中受到的許多問題和擔憂的回應。但是，如果沒有一個真正的使用案例能確保 Fedora 某些實際用戶集受益，那么這看起來像是一個很快就會消失的功能。也許現(xiàn)在需要的是和那些致力于 IMA 工作的人聯(lián)合起來，提出一個綜合的計劃，能確保提供一個 threat model 以及真正的使用案例。例如，IMA 提案指出 Fedora IoT 版可能會需要用到該功能，這與 Android 中現(xiàn)有的 fs-verity 的使用更為一致。Boyd 明確表示，Red Hat 很有興趣能在 Fedora 中看到 IMA 支持，因此如果配合起來合作，可能可以更加發(fā)揮協(xié)作作用。這種方法可能會在 Fedora 社區(qū)得到更多贊同票。

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

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