Log for Ubuntu 台灣社群
重新探討 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
這篇文章深入介紹了 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
https://aws.amazon.com/tw/message/101925/
AWS us-east-1幾乎全滅，罪魁禍首竟然只是一個 DNS的race condition。
AWS剛為10月19號的世紀災難完成了RCA，起因是DynamoDB 的DNS自動化管理系統上演「左右互搏」，一個 Enactor（執行者）處理得太慢，另一個 Enactor不但搶先完成了新計畫，還順便叫了清潔工（cleanup process）來刪除舊資料。最扯的是，就在清潔工動手前一刻，那個跑得超慢的 Enactor 終於把手上的舊的plan寫了上去，直接覆蓋了正確的設定。於是這個被正在被使用的舊plan當成垃圾刪除，結果的 DNS 紀錄瞬間蒸發，變成一個空值。
DynamoDB一倒，依賴它的EC2管理系統跟著直接癱瘓，導致所有新的EC2實例啟動請求全部失敗。EC2 一死，NLB（網路負載平衡器）也跟著陪葬，因為新EC2網路沒搞定，Health Check大亂，NLB開始瘋狂踢掉健康的節點。
最後就是你看到的，Lambda、EKS、ECS、Fargate，甚至連AWS管理控制台登入全都炸掉，整個 us-east-1 迎來集體崩潰，就造成了2025年最荒謬的雲端事故。
轉自 https://www.threads.com/@brewbytes.ai/post/DQIsu92Efm_?xmt=AQF00QgkjofqDqJ4jU0opUyO8XYvBHOjvD4hrUOYu-AWsQ&slof=1
AWS us-east-1幾乎全滅，罪魁禍首竟然只是一個 DNS的race condition。
AWS剛為10月19號的世紀災難完成了RCA，起因是DynamoDB 的DNS自動化管理系統上演「左右互搏」，一個 Enactor（執行者）處理得太慢，另一個 Enactor不但搶先完成了新計畫，還順便叫了清潔工（cleanup process）來刪除舊資料。最扯的是，就在清潔工動手前一刻，那個跑得超慢的 Enactor 終於把手上的舊的plan寫了上去，直接覆蓋了正確的設定。於是這個被正在被使用的舊plan當成垃圾刪除，結果的 DNS 紀錄瞬間蒸發，變成一個空值。
DynamoDB一倒，依賴它的EC2管理系統跟著直接癱瘓，導致所有新的EC2實例啟動請求全部失敗。EC2 一死，NLB（網路負載平衡器）也跟著陪葬，因為新EC2網路沒搞定，Health Check大亂，NLB開始瘋狂踢掉健康的節點。
最後就是你看到的，Lambda、EKS、ECS、Fargate，甚至連AWS管理控制台登入全都炸掉，整個 us-east-1 迎來集體崩潰，就造成了2025年最荒謬的雲端事故。
轉自 https://www.threads.com/@brewbytes.ai/post/DQIsu92Efm_?xmt=AQF00QgkjofqDqJ4jU0opUyO8XYvBHOjvD4hrUOYu-AWsQ&slof=1
Fedora 核准使用 AI 的政策
Linux 發行版 Fedora 理事會核准了最新版的 AI 協助貢獻（AI-Assisted Contributions）政策，允許開發者使用 AI 協助進行程式撰寫或潤飾文字。開發者必須對自己的貢獻內容負完全責任，無論其中有多少比例是由 AI 產生；若大部分內容是透過 AI 工具產生的，開發者必須揭露所使用的工具情況；若僅使用 AI 進行文法或拼字校正、潤飾文字，則無須揭露。AI 工具可以用來為審核者提供分析與建議，但審核者不得將 AI 的判斷視為最終裁定。
Linux 發行版 Fedora 理事會核准了最新版的 AI 協助貢獻（AI-Assisted Contributions）政策，允許開發者使用 AI 協助進行程式撰寫或潤飾文字。開發者必須對自己的貢獻內容負完全責任，無論其中有多少比例是由 AI 產生；若大部分內容是透過 AI 工具產生的，開發者必須揭露所使用的工具情況；若僅使用 AI 進行文法或拼字校正、潤飾文字，則無須揭露。AI 工具可以用來為審核者提供分析與建議，但審核者不得將 AI 的判斷視為最終裁定。