M07 · CTF
sandbox extension 與過放 filter 的偵測面
進程 profile 沒有靜態允許 ~/Downloads，使用者卻透過開啟對話框選了一個檔——找出讓這次存取放行的不是改 profile， 而是一張動態 sandbox extension token。接著比較兩個 file-read* 規則：一個用 (subpath) 精確收斂、一個用過寬的 (regex) 配到鄰接路徑，指出過放 filter 屬於規則撰寫邏輯錯誤（profile 過放）而非 kernel 漏洞，並說出在 Sandbox log 裡能看到什麼偵測訊號。
SBPL sandbox 求值器
- (deny default) ← 起點
- #1 (allow file-read* /usr/lib) ← 命中
- #2 (allow file-read* ~/Library/Containers/com.x.app/Data)
- #3 (allow file-write* ~/Library/Containers/com.x.app/Data)
- #4 (allow mach-lookup com.apple.fonts)
- #5 (deny file-read* ~/Library/Containers/com.x.app/Data/secret)
命中規則 #1（allow file-read*）。last-match-wins：後面的規則覆寫前面的。
試 file-read-data ~/Library/Containers/com.x.app/Data/secret/key：先被 allow（Data 子樹）命中、再被後面更specific 的 deny（secret 子樹）覆寫 → 最終 deny。這就是 last-match-wins。SBPL 為教學子集，非完整語言。
過關目標
- 讓 decision.fileRead.userSelected.grantedVia 達到 "sandbox-extension"
- 讓 filter.regexRule.overbroad 達到 true
- 讓 rootCause.overbroadFilter.class 達到 "profile-overgrant"
- 用自己的話解釋：使用者「臨時同意開啟一個檔」如何被翻成 sandbox extension token 而不必改 profile？又：過放 (regex) filter 為什麼算 profile 撰寫邏輯錯誤（而非 kernel 漏洞），在 Sandbox log 裡你會找哪些偵測訊號？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
靜態 profile 沒列的路徑要被放行，靠的是執行期遞交的 sandbox extension token（能力導向授權），不是把 profile 改寬。
走錯方向時
過寬的 (regex) filter 是「規則寫錯」導致 profile 過放，根因在撰寫邏輯；這跟 kernel/MACF 本身的漏洞是不同類別。
想更深入
把過寬 extension 發給低權進程 = confused-deputy 類別（高權者代低權者行使能力，M08 展開）。偵測面：log show 篩 sender == "Sandbox" 的 deny(1) 痕跡，以及哪個 operation 對哪個目標被擋/放行。