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

關(guān)注了就能看到更多這么棒的文章哦～

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

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

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

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

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

不過，他更主要的抱怨基本上是在反對對用戶名字空間進(jìn)行任何形式的訪問控制。他說，隨著時間的推移，許多新的內(nèi)核功能被限制在僅有 root 用戶可用，主要是因?yàn)樗鼈兛赡鼙挥脕砥垓_ setuid 程序。這導(dǎo)致了更多的代碼會以 root 身份運(yùn)行，這對整體的安全是不利的。用戶命名空間是為了結(jié)束這種趨勢：

用戶命名空間的目標(biāo)之一是避免越來越多的代碼遷移到以 root 身份運(yùn)行。為了實(shí)現(xiàn)這個目標(biāo)，普通的應(yīng)用程序開發(fā)人員需要能夠基本確認(rèn)這一點(diǎn)：典型的用戶命名空間都是在 Linux 上正?？捎玫?。

今天，像 chromium 這樣的常見應(yīng)用程序已經(jīng)假設(shè)這樣的前提條件是具備的。

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

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

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

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

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

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

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

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

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

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