Omarchy 爆提權漏洞　桌面上任何程式都能無密碼變 root

編按：本文綜合整理自資安研究者於 0xcc.io 發表的漏洞揭露報告、Hacker News 討論串（story 49499854，335 分／332 則留言）與 Docker 官方文件說明，並加入 Siami 編輯部觀點與分析。

由 Ruby on Rails 之父 DHH（David Heinemeier Hansson）主導、近年在開發者圈快速竄紅的 Arch Linux 桌面環境 Omarchy，日前被揭露存在一個嚴重的權限提升問題：在預設安裝下，使用者桌面工作階段中幾乎每一個執行中的程序，都能夠在不輸入密碼、不經過 sudo、也沒有任何權限提示的情況下取得 root 權限。

研究者透過專案的責任揭露流程私下通報，設定問題已於 4.0.1 版修補完成，細節才對外公開。若你正在使用 Omarchy，最重要的一件事很單純：立刻升級到 4.0.1。

漏洞成因：一行 docker 群組設定

問題的根源出在 Omarchy 把預設使用者加入了 Linux 的 docker 群組。這讓使用者可以不打 sudo 就直接執行 docker run ...。

但在 Arch 上，Docker daemon 是以 root 身分執行，並且監聽 /var/run/docker.sock。任何屬於 docker 群組的成員都能與這個 socket 通訊——而 Docker 官方文件其實早已明文警告：加入 docker 群組等同於授予該使用者 root 等級權限。

具備 Docker socket 存取權的程序，可以要求那個以 root 執行的 daemon 啟動一個 root 容器、把主機檔案系統的任意部分掛載進去、以 root 身分操作那些檔案，並執行任意程式碼。

概念驗證非常直白。一般使用者原本讀不到 /etc/shadow：

• cat /etc/shadow → Permission denied
• 但 id 會顯示群組包含 967(docker)
• 接著 docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow → 整份影子密碼檔直接吐出來

指令由一個普通使用者程序發起，實際的檔案系統存取卻是透過一個以 root 執行的 daemon 完成的。

影響範圍：整個桌面工作階段

Linux 的補充群組（supplementary groups）會被子程序繼承，因此這個問題影響的是整個使用者工作階段。研究者實際走訪使用者 systemd --user 底下的程序樹，發現 docker 群組幾乎出現在該工作階段的每一個正常程序上。

換句話說，幾乎所有可能執行到不受信任程式碼的地方，都能取得 root：

1. AI 編碼代理與 agent harness（這在 2026 年格外要命）
2. 網頁瀏覽器
3. 編輯器與 IDE
4. npm 腳本
5. 各種隨手裝的開發工具與背景程序

結論很殘酷：一個普通使用者應用程式被攻破，就等於整台機器被完全攻破。

受影響版本為 4.0.1 之前的所有版本；研究者實測最新的 3.x ISO（3.8.4）同樣中招。從 git 提交歷史看，docker 群組成員資格早在 2025 年 6 月 1 日就被引入，中間一度停用又於 6 月 17 日重新啟用，直到 2026 年 8 月 24 日才從預設設定中移除——問題實際存在了超過十四個月。

🚨 為什麼這件事重要

這則新聞的重量，遠遠不只是「某個小眾發行版改錯一行設定」。

第一，這是「opt-out 而非 opt-in」的安全預設值問題。 使用者根本不需要真的用到 Docker，這個安全取捨就已經替他做好了、套用在預設帳號上，而且從未向他解釋。安全敏感的預設值之所以關鍵，正是因為多數使用者合理地假設「作業系統預設是安全的」，若要降低安全等級，系統應該主動提示、由使用者明確選擇加入。Omarchy 打破了這個假設。

第二，官方文件的描述具有誤導性。 Omarchy 的開發工具文件寫著它會做「讓你以一般使用者而非 root 執行 Docker 所需的使用者群組變更」。這句話的安全意涵幾乎與現實相反——讀者很容易推論成 Omarchy 把 Docker 配置成了某種 rootless 模式，但它並沒有。一句聽起來像在強調安全的行銷式文案，實際上描述的是一個把 root 交出去的設定。

第三，也是 2026 年最尖銳的一點：開發者機器已成為供應鏈攻擊的第一線。 隨著 AI 大量產出針對核心基礎設施的高危 CVE，安全必須是所有開發者的優先考量，對於「以開發者為目標客群的發行版作者」更是如此。近期關於開發者機器被入侵、進而被用來污染軟體供應鏈或滲透正式環境的報告層出不窮。開發者是高價值目標，因為他們手上握有大量存取權；而開發者機器的典型樣貌卻是——為了方便關掉安全護欄、把憑證明文存在 dotfiles、長年累積各種系統存取權。當你的 AI coding agent 在這樣一台機器上跑起來，docker 群組就是它從「寫錯程式碼」升級成「接管整台機器」的那道門。

值得肯定的是，研究者形容專案方的回應速度令人驚豔，這是健康的訊號。但他也直言，這並非他第一次在 Omarchy 上遇到安全問題，坦白說他並不信任目前這套決策流程能提供他對發行版所期待的安全水準。

🚨 數據解讀與質疑

把時間軸攤開看，幾個數字很值得咀嚼。

• 14 個月：從 2025 年 6 月引入到 2026 年 8 月移除，這個預設值存在的時間跨度。中間曾在 6 月 2 日短暫停用、6 月 17 日又重新啟用——這代表當時有人注意到了什麼，但最終仍選擇把它加回去。
• 335 分／332 則留言：Hacker News 上的討論熱度幾乎是 1:1 的分數留言比，這在 HN 屬於高度爭議性的訊號，而非單純的「好文分享」。
• 另一則 295 分的相關討論：標題直接寫著「Omarchy 的開發實務導致可預期的安全問題」，累積 451 則留言。這意味著社群的不滿並非針對這單一漏洞，而是針對模式。

社群反應中最值得注意的，是有人引述 DHH 在 Lex Fridman 節目上的說法，稱這次發佈的內容大多是「vibe coded」、他並未逐行審閱程式碼。Siami 認為這一點需要謹慎看待——這是節目談話的轉述，並非正式聲明，不應直接等同於「這個漏洞是 AI 寫出來的」。從 git 歷史來看，把使用者加入 docker 群組是一個非常常見的傳統便利性做法，在無數教學文與 dotfiles 專案裡都能找到，它更像是沿襲慣例的疏忽，而非 AI 產物。

但這正是真正該質疑的地方：當一個發行版把「用 AI 快速迭代、隨心所欲改任何東西」當成核心賣點時，誰來為安全預設值把關？漏洞本身是可以修的，十四個月後也確實修了；但一個不逐行審閱、以速度為優先的開發流程，能不能承接住「數萬台開發者機器的信任」這個責任，是完全不同層級的問題。

也別忘了另一個未被充分討論的殘留風險：修掉 ISO 很容易，修好已經裝出去的系統很難。移除預設設定只影響新安裝，那些過去十四個月間裝好、且已把使用者加入 docker 群組的機器，如果只是照常滾動更新，群組成員資格未必會被自動撤銷。這才是漏洞真正的長尾。

使用者該怎麼做

1. 立即升級至 Omarchy 4.0.1 或更新版本。
2. 手動檢查自己的群組：執行 id，看看輸出裡還有沒有 docker。如果有，而你並不需要，就把自己移出該群組。
3. 考慮改用 Podman。研究者明確推薦：Podman 是 daemonless 的，容器以你自己的一般子程序身分、在各自的 user namespace 中執行，完全不需要任何 root 存取。他表示自己已使用 Podman 數月，並完全取代了所有 Docker 工作流程。HN 上也有留言指出，Compose 檔案在 Podman 上運作良好，兩者的功能差距基本已經填平，而少數行為不同之處，恰恰就是「Docker 本來就不該做的那些事」。
4. 保護你的啟動檔案。針對 .bashrc、.profile 以及 $PATH 中的所有目錄採取防護措施——留意單用 chattr +i 並不足夠，因為攻擊者能以同等權限先執行 chattr -i 解除。

對於在機器上執行 AI coding agent 的使用者，這件事的教訓格外具體：agent 的爆炸半徑，等於你桌面工作階段的權限邊界。把那道邊界畫在哪裡，是你自己的責任，不能外包給發行版的預設值。

後續觀察重點

Siami 會持續關注三個面向：Omarchy 是否會為既有安裝提供主動的群組清理機制、專案是否建立起更正式的安全審查流程，以及 2026 年這波「AI 加速開發 vs. 安全把關」的張力，會不會在更多面向開發者的工具鏈上以類似形式重演。

畢竟正如研究者所說，沒有任何發行版能在安全決策上做到完美——真正的差別在於，出事之後你改的是那一行設定，還是那套流程。