Golden Gate Application Support Protection
Looks like moving the user’s TCC db to /private/var/containers/Data/ProtectedSystem/[UUID]/Data/Library/Application Support/com.apple.TCC/ was not the only change in the whole privacy castle of macOS 27. (What btw was a great move as now attackers with full disk access permissions can’t modify your privacy settings)
macOS 27 quietly ships a new privacy mechanism I hadn’t seen documented anywhere: it extends the
com.apple.maclprotection that has always guarded sandboxed apps’~/Library/Containers/<bundle-id>/Datafolders to a hand-picked set of non-sandboxed apps’~/Library/Application Support/<name>folders too. I noticed it by accident — Firefox’s profile folder was suddenly inaccessible from Terminal, while MacPass, a password manager sitting right next to it, was wide open. That asymmetry didn’t sit well with me, so I pulled the thread. It ends in a hardcoded app allowlist baked into /usr/libexec/sandboxd (thx @ciphwall for the hint), meant to be updated live via XProtect.
Previously:
- Hijacking Apps Using Archive Utility
- Privacy & Security Settings Don’t Show Intent-Based Access
- Resetting TCC
- Persistent File Access via com.apple.macl Xattr
4 Comments RSS · Twitter · Mastodon
For posterity, with SIP disabled, it is still possible to write to the user's TCC database in its new location. The root TCC database is still at the same location that it used to be, and is also writeable with SIP off.
Anyone know how the UUID in the `/private/var/containers/Data/ProtectedSystem/[UUID]/Data/` path is derived? It's not the IOPlatformUUID…
So, what am I supposed to do if I want to do something sensible like use a terminal or a text editor in one of Firefox's profile folders? There's files in there that are *intended* to be human editable!
This is exactly the kind of garbage that's so tiresome with each new release of macOS. I understand why a naive user could benefit from this protection, but there's got to be a way to opt out! It's maddening!
> There's files in there that are *intended* to be human editable!
There are backup files in there (e.g. sessionstore-backups) that you're meant to manually move when something goes wrong. I feel like I must be missing something; preventing users from working with these files makes absolutely no sense.
