M06 · CTF
一次相機授權，tccd 看的是什麼
在判定管線裡，給定一個 client 對 kTCCServiceCamera 發起存取，找出 tccd 是用「裸 PID」還是 「audit token」做責任歸屬，並說出為什麼這個選擇能避免把另一個程序誤認成原請求者。
TCC 判定實驗室
情境
雙層 db：~/Library/.../TCC.db（user）先於 /Library/.../TCC.db（system）。此服務無 limited。
tccd 判定提示授權
- attribution用 audit token 歸屬到責任 client：com.example.app（非看 PID）。
- lookup雙層 tcc.db 都查無 (service, client) 紀錄 → 視為 unknown。
- prompt無紀錄 → 由系統跳出授權提示（若無 UI 環境則視為拒絕）。
查無紀錄 → 提示使用者授權（首次請求）。
試試：把「目前簽章符合 DR」關掉（模擬冒名/重簽）→ 既有 allowed 紀錄作廢、重新提示。把 audit token 關掉 → 連歸屬都失敗。
模型邊界：tccd 判定為**教學決策模型**（audit token 歸屬 → 雙層查表 → csreq DR → auth_value），非逐欄位實作。TCC.db 受 SIP/FDA 保護，本實驗室用合成資料。驗證於 macOS 26.3.1。
過關目標
- 讓 decision.kTCCServiceCamera.attribution.source 達到 "auditToken"
- 讓 decision.kTCCServiceCamera.pidReuseSafe 達到 true
- 用自己的話解釋：為什麼 tccd 用 audit token（pid + pidversion）而非裸 PID 做責任歸屬？這擋掉了哪一類混淆？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
tccd 要的是 responsible process（誰該負責），不是「哪個 PID 問的」。它取的是 audit token。
走錯方向時
裸 PID 會被重用——A 結束後 PID 可能被 B 拿走。audit token 帶 pid + pidversion，能釘住「就是當時那個程序實例」。
想更深入
這就是 M08 confused-deputy 的根因類別：用可重用的 PID 做信任驗證 = PID 重用混淆。防禦是改用 audit-token 基礎的介面。
相關指令
codesignlog