在 Day 05，我們介紹過 Linux Capabilities：Linux 將傳統上屬於 root 的特權拆成多個能力，讓程式可以依需求取得權限。當時我們透過 CAP_DAC_OVERRIDE，理解為什麼 root 可以讀取權限為 000 的檔案，卻不一定能直接執行它。

到了 Day 16，我們又看到 --privileged 如何大幅放寬容器的權限與安全限制，進而讓容器存取宿主機的敏感檔案。

那麼，如果沒有啟用 privileged，只額外授予一項 capability，容器就安全了嗎？

今天我們要把焦點放在 CAP_SYS_PTRACE 這項能力，來討論為什麼要重視容器的 Capabilities。

什麼是 CAP_SYS_PTRACE ？

Linux 的 capabilities(7) 手冊對 CAP_SYS_PTRACE 的描述如下：

Linux 的 /proc 是提供核心與行程資訊的虛擬檔案系統。容器內的程式仍由宿主機核心管理，行程的可見範圍則受到 PID namespace 等機制影響。本次實驗使用 --pid=host，讓容器能看見宿主機行程，再搭配 CAP_SYS_PTRACE，驗證在目前安全設定下，是否能跨 UID 讀取指定行程的環境資料。

從容器讀取宿主機行程的敏感資訊

我們在容器裡面先執行以下指令檢查 cap 權限：

grep Cap /proc/self/status
eff=0x$(awk '/CapEff/{print $2}' /proc/self/status)
echo "SYS_PTRACE(bit19) = $(( (eff>>19)&1 ))" 

這邊我們把焦點放在 CapEff 上面，CapEff 表示目前行程的有效能力集合，是核心進行 capability 權限檢查的重要依據。不過，具備某項能力並不代表操作一定成功，仍須考慮命名空間與其他安全機制的限制。

截至今天文章撰寫時，Linux 主線核心定義了 41 項 capabilities，編號為 0～40。實際核心支援的最大編號，可透過 /proc/sys/kernel/cap_last_cap 確認。

本次 CapEff 的值為 00000000a80c25fb，其二進位表示中共有 15 個位元為 1，代表目前有 15 項有效能力。CAP_SYS_PTRACE 對應 bit 19；位元編號從 0 開始，因此是由右向左數的第 20 個位元。檢查結果為 1，表示這項能力目前有效。

本 Lab 建立了一個由 nobody 執行的 sleep 誘餌行程，並以 lab17-secret-holder 作為啟動參數中的識別標記。該行程的環境變數 APP_SECRET 存放的是實驗用假秘密，接著透過行程清單定位它。

ps -eo pid,user,comm,args | grep secret-holder | grep -v grep

這邊有一個細節要注意：
截圖中的 PID 35857 是由 root 執行的 runuser 啟動器。它以 nobody 身分啟動 Bash，由 Bash 設定環境變數，再透過 exec 替換成 sleep。因此，本次要檢查的目標是 PID 35859、使用者為 nobody 的誘餌行程。
※ PID 會隨實驗而改變，讀者要練習請務必自己查詢。

接著利用下面這個指令來看看我們能不能讀到這個環境變數：

cat /proc/35859/environ | tr '\0' '\n' | grep -i secret 

/proc/<PID>/environ 主要呈現程式啟動時的環境區域，存取時會受到核心的 ptrace 權限檢查。因此，即使用的是 cat，CAP_SYS_PTRACE 仍可能影響是否獲准讀取。

結果顯示，容器內成功讀取了指定誘餌行程的 APP_SECRET，對照組保留相同的 host PID 模式與安全選項，並明確移除 SYS_PTRACE。結果顯示，容器仍能列出同一個誘餌行程，讀取其 environ 時卻得到 Permission denied。這說明「看得到行程」與「有權讀取行程資料」是不同的判斷。

今天的主題就到這裡。雖然實驗步驟不多，卻牽涉到 capabilities、行程身分與命名空間等多層權限判斷，也讓我發現容器的權限管理是一門值得深入研究的學問。

透過這次實作，我更清楚地理解：即使沒有啟用 --privileged，不當的能力與隔離設定，仍可能讓容器讀取宿主機上其他行程的敏感資料。若其中包含有效密碼或 token，就可能被進一步利用，形成橫向移動的風險。因此，設計容器時，應確認每一項 capability 是否真的必要，並一併檢查命名空間與其他安全限制，讓服務只取得完成工作所需的權限。

感謝大家今天的收看，我們明天見！