M09 · CTF
層間借力與 confused-deputy——找出根因，設計防禦
一個低權第三方 actor 自己過不了 SIP 閘（無 restricted entitlement），但情境中放了多個特權 helper 作為干擾項；其中某個帶 heritable com.apple.rootless.* entitlement 的 platform helper，會在「只看 執行者身分、不驗請求發起者」時被借力代為操作。任務是：(1) 指出哪個 helper 是可被借力的 deputy 與 其根因類別（attribution 錯置 / 介面過泛 / entitlement 可繼承），(2) 選出能擋住此類問題的防禦。 全程停留在根因與防禦層級，不含任何可操作的利用步驟。
此關卡對應的模擬器（sixgate）尚未提供。
過關目標
- 讓 analysis.identifiedDeputy.isPlatformBinary 達到 true
- 讓 analysis.rootCauseCategory 達到 "attribution-misplacement"
- 讓 defense.verifyResponsibleViaAuditToken 達到 true
- 用自己的話解釋：為什麼「驗證請求發起者（audit token）而非只看動作執行者」能擋住 confused-deputy？ 為什麼以 PID 歸屬不夠、entitlement 可繼承會讓能力外溢？這整個過程沒有任何一道閘被「打破」， 問題出在哪裡？（只談根因與防禦，不談攻擊步驟。）
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
閘是依「動作執行者的身分」判的。低權 actor 過不了 Gate 4，但若能讓帶 restricted entitlement 的 platform helper 代為發起，閘看到的是 helper 身分就放行——沒有閘被打破，是責任歸屬被錯置。
走錯方向時
干擾項裡的第三方 helper 即使以 root 跑也拿不到 restricted entitlement，過不了 SIP；真正的 deputy 是 platform 簽署、帶 heritable com.apple.rootless.* 的那個。判定來源是 kernel csflags 的 is_platform_binary，不是 uid。
想更深入
正確防禦是「驗證責任方而非執行方」——特權服務用 audit token（接 M08）確認發起 client 是誰、收斂介面、收緊/去除可繼承的 entitlement、加 Launch Constraints。不要尋找或描述任何提權步驟。