Podman 無根容器與 Copy Fail 利用：分析衝擊範圍

CVE-2026-31431（俗稱「Copy Fail」）的披露在 Linux 社群中掀起波瀾。此漏洞允許本地非特權使用者透過利用核心處理特定檔案操作的方式取得 root shell，實質上讓使用者能覆寫本應僅具唯讀權限的檔案。

對於使用容器化的使用者而言，影響相當重大。容器常被用來隔離面向公眾的服務、CI/CD 工作以及開發環境。若攻擊者透過遠端程式碼執行（RCE）取得立足點，Copy Fail 可能被用來在容器內提升權限。本文專注於 Podman 的無根容器環境，探討不同設定如何影響此類攻擊的「衝擊範圍」。

了解無根容器

要了解 Copy Fail 的影響，首先必須了解 Podman 如何實作無根容器。與傳統的 Docker daemon 模型（由具 root 權限的 daemon 產生容器）不同，Podman 採用 fork/exec 模型。容器的行程是 podman run 行程的直接子代，意味著它繼承啟動它的使用者的 UID。

使用者命名空間與 UID 映射

Podman 利用 Linux 使用者命名空間提供隔離。這允許一個行程在容器內擁有一個 UID，而在主機上則是另一個 UID。例如，在無根容器內以 root（UID 0）執行的行程，會映射到主機上的非特權使用者（例如 UID 1001）。

此映射受 /etc/subuid 管理，該檔案定義了非特權使用者可分配給命名空間行程的 UID 範圍。即使行程在容器內是 root，從主機的觀點看仍是非特權使用者，極大限制其對主機系統的破壞能力。

Linux 能力

Linux 的 root 權限並非單一塊，而是分解為多個「能力」。Podman 使用這些能力來授予容器行程細粒度的權限。例如，透過 apt 安裝套件需要 CAP_CHOWN、CAP_SETUID 等能力。

預設情況下，無根具 root 容器（在命名空間內以 root 身份執行）會被授予大量能力，擴大攻擊面。較安全的做法是執行「無根非 root」容器，讓行程在容器內外皆以非特權使用者執行，並移除所有不必要的能力。

測試 Copy Fail 利用

在實作測試中，Copy Fail 被用來嘗試在各種 Podman 設定下提升權限。此利用通常會下載一個 Python 腳本，使 su 命令在不需要密碼提示的情況下執行，從而取得 root shell。

無根具 root 容器

在容器內行程已以 root 身份執行的配置中，Copy Fail 顯得多餘。使用者已具備利用欲提供的權限。然而，該行程仍映射到主機上的非特權使用者，意味著主機的 root 檔案仍不可存取。

無根非 root 容器

這是利用發揮威力的情境。於以非特權使用者（例如 foo）執行的容器中，Copy Fail 成功將行程提升為容器內的 root。

雖然攻擊者現在在容器內部取得了 root 權限，並能存取命名空間 root 所擁有的檔案，但仍受限於主機使用者的權限，無法存取主機實際 root 使用者擁有的檔案。

緩解升級

兩個主要的 Podman 旗標可用來阻止 Copy Fail 利用的即時效果：

--security-opt=no-new-privileges：此旗標防止行程取得額外權限。啟用後，Copy Fail 利用無法產生 root shell，使用者仍為 foo。
--cap-drop=all：移除所有能力同樣可防止利用成功提升至具特權的 root shell。

需要注意的是，雖然這些旗標可阻止 su 利用，但根本漏洞——在頁快取中覆寫唯讀檔案的能力——仍然存在。必須更新核心才能徹底解決此問題。

深入防禦：限制衝擊範圍

由於沒有單一的安全邊界是萬無一失的，採取防禦深度（defense‑in‑depth）策略對於限制受損容器可能造成的損害至關重要。

唯讀檔案系統

使用 --read-only 旗標（搭配 --read-only-tmpfs=false）將容器的根檔案系統以唯讀方式掛載。這可防止攻擊者在利用後寫入惡意二進位或修改系統設定，儘管仍無法阻止利用透過管道指令在記憶體中執行。

資源限制

利用 cgroup 限制記憶體、CPU 與 PID 數量，可確保受損容器無法用來對主機或其他容器發動拒絕服務（DoS）攻擊。

最小化映像檔

減少攻擊者可使用的工具集是關鍵步驟。以 ubuntu 作為基礎映像會提供大量二進位（如 curl、python3），有助於利用。改用 -slim 映像、Alpine Linux 或「distroless」映像可移除 shell 與套件管理器，讓攻擊者難以自行建構利用。

網路防火牆

透過 iptables 或 nftables 限制進出連線，可防止受損容器與指揮與控制（C2）伺服器通訊，或在內部網路中進行橫向移動。

批判性觀點與反論點

雖然主要的利用範例聚焦於透過 su 取得 root shell，社群討論卻指出 Copy Fail 的真正危險更為廣泛。

"此漏洞使得原本應與容器共享且唯讀的各種資源實際上變得可寫，因此在許多情境下衝擊範圍將會非常龐大，即使不像 'su' 範例那樣普遍且易於利用。"

此外，有研究者指出 Copy Fail 可用於容器之間的橫向攻擊。若兩個容器共用同一基礎映像層，惡意容器可能覆寫該共享層中的檔案，進而危及以相同非特權使用者執行的第二個容器。

亦有越來越多的聲音認為 Linux 核心的隔離機制（命名空間、seccomp）在高安全性環境中可能不足，因而有人主張使用 MicroVM 作為更強的安全邊界。

結論

Podman 的無根架構相較於傳統具 root 權限的 Docker 安裝，提供了顯著更好的安全姿態，因為容器內的 root 永遠不會等同於主機的 root。然而，正如 Copy Fail 所示，容器並非不可逾越的牆壁。結合無根執行、移除不必要的能力、使用 no‑new‑privileges 選項以及最小化映像檔，管理者可大幅降低妥協後的衝擊範圍。最終，最有效的防禦仍是及時的核心修補與層次化的安全措施，前提是假設容器邊界最終會被突破。