重新探討 Linux 權能（Capabilities） （★ 100 分）
這篇文章深入介紹了 Linux 中的「Capabilities（權能）」機制，說明它如何取代傳統以 `root` 使用者為核心的全權模型。傳統上，超級使用者能執行所有高權限操作，但 Capabilities 將這些權限拆分為細項獨立單元，讓程式僅能取得所需的最小權限。例如，一個服務可能只需綁定受限通訊埠，而無需取得其他系統級指令權限。藉由這種方式，系統能更精細地管控安全風險，降低權限濫用或入侵後的危害範圍。
作者示範了如何透過 `setcap` 指令將 `cap_setuid` 權能加到 Python 執行檔上，這讓攻擊者可以在不變更檔案 suid 位元的情況下，以低權限使用者執行 Python 命令來切換至 `UID 0`，也就是取得 root 權限。這等於替可執行檔建立了一個強大的後門。因此，除了傳統追查 `SUID/SGID` 檔案外，現代安全審查也必須檢查具備權能設定的檔案。使用 `getcap -r /` 便能遞迴列出整個系統中啟用的權能，輔以 `capsh` 或 `getpcaps` 解析特定程序的能力位元。若要移除權能，可使用 `setcap -r`。像 LinPEAS 這樣的滲透測試工具，也內建對 `setcap` 權能檔案的搜尋偵測。
文章同時介紹了 Elastic Security 的偵測規則，透過監控 `setcap` 的執行情形辨識權限設定行為，並說明 `security.capability` 屬性如何以二進位格式儲存在檔案 inode 中，而 `getcap` 會將其轉譯成人類可讀的權能名稱。作者最後強調，有效的安全審查應兼顧傳統 suid 檢查與權能檔案追蹤，因為這些細粒度權限若未被監控，會造成潛在的隱匿風險。像 `getcap` 這類工具能協助全面檢視系統權限配置，強化滲透防禦與稽核工作。
Hacker News 上的討論延伸至權能模型的哲學層面與實作困難。多位開發者認為，Linux Capabilities 雖改善了過去全權 root 模式，但仍只是從單一超級權限分割出一組旗標，與真正的「物件導向權能安全模型（Capability-based Security）」不同。部分留言比較了 OpenBSD 的 `pledge` 與 FreeBSD 的 `capsicum`，指出前者的設計更簡潔易用，而 Linux 的 `seccomp`、`SELinux` 與 `AppArmor` 等安全層則過於複雜、難以維護。也有參與者認為這些系統過於外掛化，導致開發者容易忽略或錯誤配置。
另一派則認為 `pledge` 模式的問題在於它需各應用主動採用（opt-in），多數應用不會花時間整合，反而讓安全落實率降低；但支持者反駁指出，願意加入 `pledge` 呼叫的開發者本身就重視安全，應該鼓勵而非懷疑。亦有意見提到，細粒度存取控制雖能強化隔離，卻擴大攻擊面，因為某些權能可能被鏈接利用進而提升權限。另一位討論者建議 Linux 應提供集中化管理權能設定的機制，如統一檔案或版本比對，免除目前分散於多個 ACL 與檔案系統層的不便。整體而言，社群肯定權能制度在實務安全上的重要性，但普遍認為現行機制仍欠直覺與整合度，需要在簡化與實效之間取得更好的平衡。
👥 16 則討論、評論 💬
https://news.ycombinator.com/item?id=45669142