雖然看起來可以使用幾個普通的應用程式來達成此目的，但為了讓演示更簡單清晰，我編寫了一個名為 Insent 的小應用程式來達成此目的，可在此處取得：insent11
我目前在 macOS Tahoe 26.4 上進行測試，但我懷疑任何從 macOS 13.5 開始的版本，只要 Insent 支援，都會看到類似的結果。
對於這次的魔術演示，我只會使用 Insent 的六個按鈕中的兩個：
下載 Insent 並從其封存檔中解壓縮後，將應用程式從該資料夾拖曳到你的「應用程式」資料夾之一，然後依照以下步驟操作：
你也可以證明這種行為是針對一次一個受保護資料夾的。如果你使用「從資料夾開啟」按鈕選擇不同的受保護資料夾，例如「桌面」或「下載」，Insent 仍然無法列出「文件」資料夾的內容，因為其 TCC 設定會如預期般運作。
Insent 是一個經過標準化處理的應用程式，它不會在沙盒中運行，也不會耍任何花招。然而，當系統完整性保護 (SIP) 啟用時，它的一些操作會被沙盒化，包括嘗試列出或存取受 TCC 保護的位置內容。
當你點擊其「透過同意開啟」按鈕時，sandboxd 會攔截「檔案管理員」列出「文件」這個受保護資料夾內容的呼叫。然後，它會向 TCC 請求授權，如下列日誌條目所示：1.204592 Insent sendAction: 1.205160 Insent: trying to list files in ~/Documents 1.205828 sandboxd request approval 1.205919 sandboxd tcc_send_request_authorization() IPC
TCC 沒有 Insent 的存取授權，無論是透過「完整磁碟存取」還是對「文件」的特定存取，因此它會提示使用者同意。如果同意，下列日誌條目顯示這會傳回沙盒，並將變更通知 com.apple.chrono，然後 Insent 會執行原始請求：3.798770 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent 3.802225 com.apple.chrono appAuth:co.eclecticlight.Insent] tcc authorization(s) changed 3.809558 Insent: trying to look in ~/Documents for text files 3.809691 Insent: trying to read from: /Users/hoakley/Documents/asHelp.text 3.842101 Insent: read from: /Users/hoakley/Documents/asHelp.text
如果你隨後透過「開啟與儲存」面板意圖存取「文件」，sandboxd 將不再攔截請求，因此 TCC 也就不會授予或拒絕存取：0.897244 Insent sendAction: 0.897318 Insent: trying to list files in ~/Documents 0.900828 Insent: trying to look in ~/Documents for text files 0.901112 Insent: trying to read from: /Users/hoakley/Documents/T2M2_2026-01-06_13_03_00.text 0.904101 Insent: read from: /Users/hoakley/Documents/T2M2_2026-01-06_13_03_00.text
大多數想要存取「文件」等受保護資料夾的應用程式，似乎會在初始化時就尋求存取權，並在任何可能導致意圖覆蓋同意需求的用戶互動之前。然而，許多用戶回報說，應用程式似乎可以存取「文件」，但卻未列在「檔案與資料夾」中，這表明在某些時候，這種事件序列確實會發生。
要有效地利用這一點，需要仔細的步驟排序，並且使用者必須在「開啟與儲存」面板中選擇受保護的資料夾，從而引起對這種操作的注意。
我非常感謝 Richard 引起我對此的注意。
在步驟 6 之後，`com.apple.macl` xattr 會被添加到 `~/Documents`，我相信這就是讓 Documents 能夠被 Insent 存取的關鍵。
我不確定 `tccutil reset All co.eclecticlight.Insent` 是否會移除 MACL 授予的存取權，但在恢復模式下執行 `xattr -d com.apple.macl path/to/Documents` 則肯定可以。
是的，我相信 macl xattr 是逃脫沙盒化的關鍵。我仍然沒有看到如何實現這一點的解釋，儘管它肯定不是透過 TCC，而是在更低的層級上運作。我懷疑 tccutil 指令會清除 macl 資料庫條目，從而保留預設的沙盒化。然而，需要完全重新啟動才能生效，這很令人惱火，而且 TCC 不會改變「檔案與資料夾」的列表，這簡直是瘋狂的。Howard。
我在此確認了問題：儘管 tccutil reset 確實會從資料庫（無論在哪裡）中移除該 macl，但 xattr 仍然存在。因此，即使你知道是什麼打開了沙盒，你仍然無法確定該應用程式是否對該受保護資料夾擁有自由存取權。而且由於 macl xattrs 受 SIP 保護，移除它們並非易事。Howard。
你是否知道在「1.093533 com.apple.TCC AUTHREQ_RESULT: msgID=440.109, authValue=0, authReason=4, authVersion=1, desired_auth=0, error=(null)」日誌中，authReason 可能的值是什麼？（只是好奇；這有助於更深入地理解這個主題）
我無法判斷這是一個安全漏洞還是一個普通錯誤。儘管利用需要多個步驟和特定順序，正如你所提到的，但感覺上這是一個漏洞。
謝謝。關鍵步驟是讓使用者在「開啟 [與儲存]」面板中選擇受保護的資料夾。一旦他們這樣做了，該保護就會在一段時間內消失，即使他們注意到了。由於這涉及到明確的使用者意圖，我認為它不太可能在現實世界中被利用。在撰寫本文之前，我閱讀了 Apple 的 TCC 獎勵計畫細節，它絕對不屬於這些範圍，所以我懷疑 Apple 會將其視為漏洞。我也確信 Apple 的工程師一定很清楚這一點，也許有一天他們會著手解決。我如何來到這裡的歷史可能也與此相關。我甚至不是一個業餘安全研究員，但我想更清楚地了解這些保護是如何工作的。最好的方法是編寫一個應用程式來評估獲得受保護資料夾存取權的不同方法，這引起了我對這種特殊行為的注意。在正常的應用程式使用中，許多人會遇到後果，但整個系統太複雜了，無法弄清楚原因。Howard。
我看到了一個明顯的安全漏洞。存取權的撤銷應該是清晰的、持久的且即時的。但它都不是。
Apple 在這裡的語言和實施都清楚地表明，他們希望顯示所有具有存取權限的應用程式，並賦予我們管理存取權限的能力。上述情況未能以可重現的方式運作，可以合理地視為錯誤或功能，但安全漏洞應該被明確說明。希望一旦處理安全性的程式碼得到修正，這一切都能以顯然的方式運作。
我以前也遇到過類似的情況，涉及「完整磁碟存取」。Apple 並不認為這是個錯誤。當我報告時，他們告訴我：「感謝您的報告。我們已得出結論，這是預期的行為，因為 TCC 不會保護檔案免受先前已獲得存取權的攻擊者侵害。」我不太同意這種說法，如果他們想要能夠在系統設定中「移除」存取權的話。但/聳肩，我沒有精力去反駁，而且這也無濟於事。
即使是處理我報告的人，起初似乎也認為這是一個有效問題，因為我看到狀態變更為表示他們重現了問題並計劃在關閉報告前進行修復，然後才給出上述回應。
尋找：一種可靠的方法來清除所有這些隱藏的權限授予，例如 xattrs 等等。無論何種形式的權限授予，都會堆積起來。偶爾清除它們並重新添加你仍然需要的權限，這會很好。當你對你可能想說「不」的內容有更好的理解時，尤其如此！
恐怕對於使用 MACL 的情況沒有辦法做到這一點，因為它們受到 SIP 的保護。要移除所有這些，你必須禁用 SIP，然後剝離所有 MACL xattrs。但這絕對不是個好主意，因為它們也用於其他存取控制目的，所以你的 Mac 會處於非常混亂的狀態。tccutil 確實允許你完全重設所有 TCC 設定，但同樣，除非你有幾天的時間來恢復它們，否則你真的不想去那裡。Howard。