LWN：針對用戶命名空間的安全模塊hook！

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

A security-module hook for user-namespace creation

By Jonathan Corbet
August 4, 2022
DeepL assisted translation
https://lwn.net/Articles/903580/

Linux 安全模塊（LSM）子系統(tǒng)的基本工作機制就是在內核中各個地方戰(zhàn)略性地選擇放置許多 hook。任何一個安全模塊都可以 attach 到它要管理的行為的相應 hook 上，并在需要做出決定時提供意見。LSM hook 的放置，經常伴隨著一些爭議.開發(fā)人員經常會反對在 hot code path （非常頻繁調用到的代碼路徑）上增加 hook 帶來的額外性能損耗，并且有時開發(fā)人員會對如何整合 LSM 存在誤解。不過，人們在討論創(chuàng)建用戶命名空間（user namesapce）的 security hook 的時候，基于另一種擔憂而產生了爭議。

用戶命名空間，也就是可以由無特權的進程創(chuàng)建，從而讓創(chuàng)建者能完全控制 user ID 和 group ID。在命名空間內，創(chuàng)建者可以以 root 身份運行，但與系統(tǒng)的所有互動都會被映射到創(chuàng)建者的 UID 和 GID 上。它們是無特權容器所需的基本功能。在理論上來說，用戶命名空間是完全安全的；在實踐中，人們長期以來一直擔憂它們會帶來更多的攻擊面，這種擔憂來自于在命名空間內提供了以前只有 root 才能進行的操作。確實有一些漏洞與用戶名字空間有關聯(lián)；最近的一個例子見本報告(https://lwn.net/ml/oss-security/nZdp4o4iHdicJfJwEJ-dtJrhs5aDa-cbvA3psbItS3dkwOwxmzwXanoaslI0T5nXjCNz0Cm5csVgCJxDWPWIaKDbF6mxaYch5xJo3QT-8_0%3D%40protonmail.com/)。不過，用戶命名空間是否真的比內核的其他部分更容易出現(xiàn)漏洞，目前尚還不清楚。

關于用戶名字空間的更多信息，請看這篇文章(https://lwn.net/Articles/532593/)。

正如 Frederick Lawler 在這個 patch set 中所指出的，安全模塊目前對用戶名字空間的創(chuàng)建有一定程度的控制，但這種控制依賴于一個 hook，而這個 hook 實際上并不是為訪問控制決策而準備的。因此，這就使得錯誤碼無法傳播給（可能是正在摸不著頭腦的）用戶。解決方案是創(chuàng)建一個新的 hook（security_create_user_ns()），在創(chuàng)建每一個新的命名空間之前都會被調用，如果它不符合當前的安全策略，就會導致創(chuàng)建失敗。

這是一個相對簡單的 patch set，甚至包括了為 SELinux 添加了一個 self-test 以及相關 hook 的實現(xiàn)的代碼。在四次修訂中經歷了一些調整，似乎已經達到了安全社區(qū)的開發(fā)者都滿意的程度。當然，有一個例外；Eric Biederman 在 7 月下旬發(fā)布第三個修訂版時提出了一些反對意見。其中之一是，只有當內核中大部分可利用的 bug 都被阻止之后，這種阻止對用戶名字空間的訪問來作為減少攻擊面的方式才會有效；否則的話，他說，攻擊者只會去尋找各種 bug 來利用。

不過，他更主要的抱怨基本上是在反對對用戶名字空間進行任何形式的訪問控制。他說，隨著時間的推移，許多新的內核功能被限制在僅有 root 用戶可用，主要是因為它們可能被用來欺騙 setuid 程序。這導致了更多的代碼會以 root 身份運行，這對整體的安全是不利的。用戶命名空間是為了結束這種趨勢：

用戶命名空間的目標之一是避免越來越多的代碼遷移到以 root 身份運行。為了實現(xiàn)這個目標，普通的應用程序開發(fā)人員需要能夠基本確認這一點：典型的用戶命名空間都是在 Linux 上正常可用的。

今天，像 chromium 這樣的常見應用程序已經假設這樣的前提條件是具備的。

你的意圖似乎是要放置一個 capability 檢查，以便只有 root 才能使用用戶名字空間或類似的功能。這樣就打破了用戶名字空間在你們系統(tǒng)上對普通應用程序的普遍可用性。

Biederman 最后用 "Nacked-by" tag 表示拒絕該 patch。

不過，只有他一個人持這種觀點。SELinux 維護者 Paul Moore 回答說，LSM hook 提供的不僅僅是訪問控制；審計和可觀察性也是它們的重要用例。他斷言，"將 LSM 整合到內核的命名空間中是一種自然的契合，而且早就應該這樣做了"，并要求 Biederman 提出替代方案，如果他真的無法接受這里提出的 hook 的話。Ignat Korchagin（和 Lawler 一樣，他是通過 Cloudflare 的電子郵件地址發(fā)布的）說，真正的目標是通過提供對用戶名字空間的更多控制來增加對它們的使用：

所以在某種程度上，我認為這個 hook 首先是允許更好地采用用戶命名空間了，并為發(fā)行版提供商和其他系統(tǒng)維護者提供了一個合理的選擇，而不是僅僅提供一個全局的 "kill" sysctl 而已（這是事實上被許多人使用的方式，從而實際上限制了用戶空間應用程序訪問用戶命名空間）。

Biederman 沒有進一步回應，談話結束了。Moore 建議現(xiàn)在是時候把這個改動合并了。

之前有 Eric 的 NACK，但我相信在他的評論之后的回應已經充分解決了這些問題，而且現(xiàn)在已經過了一個星期，Eric 沒有進一步的評論；那么我們應該繼續(xù)推進這件事。

不過，在 8 月 1 日發(fā)布第四版后，Biederman 明確表示，他不認為他的擔憂已經得到了處理。"Nack Nack Nack"。

接下來會發(fā)生什么，目前尚不完全清楚。Biederman 仍然沒有為這個問題提供什么替代方案，所以開發(fā)者們只能做出一個有點不愉快的選擇：要么從頭開始，希望找到一個 Biederman 不會阻止的解決方案，要么干脆不理會 Biederman，直接合入這個 hook。由于 Biederman 顯然反對對用戶命名空間的創(chuàng)建進行任何形式的訪問控制，因此很難有雙方都能接受的解決方案。在內核社區(qū)中，不顧維護者的反對而合入代碼是很不容易的，但這種情況偶爾也會發(fā)生。Moore 已經表示，這次這個案例可能會出現(xiàn)這樣的過程。

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

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