Edmondo's Vault

macOS Security - SIP and TCC

May 18, 20263 min read

macOS Security — SIP and TCC

macOS has two independent security mechanisms that restrict file access. People conflate them constantly, but they are orthogonal.

SIPTCC / FDA
Full nameSystem Integrity ProtectionTransparency, Consent, and Control / Full Disk Access
Enforced byKernel (AppleMobileFileIntegrity / AMFI)Userspace daemon (tccd)
AffectsSystem paths, kernel operationsUser-sensitive paths in home directories
Bypass requiresRecovery Mode bootUser grants permission in System Settings
Root bypasses it?NoYes (root ignores TCC)

SIP — System Integrity Protection

SIP is a kernel-enforced security policy introduced in OS X El Capitan (10.11). It restricts what operations can be performed on certain filesystem paths and kernel interfaces, regardless of whether the process is root.

What SIP protects

Filesystem paths (kernel-enforced, even against root):

  • /System/ — the entire System volume. On modern macOS, this is also the SSV, which is read-only regardless of SIP.
  • /usr/ except /usr/local/ — system binaries
  • /bin/, /sbin/ — core utilities
  • /System/Library/Caches/ — includes the DYLD shared library cache (the dynamic linker’s pre-built cache of system frameworks)

Kernel interfaces:

  • Loading unsigned kernel extensions (kexts) — on Intel
  • Attaching debuggers to system processes
  • Modifying NVRAM variables (partially)

What SIP does NOT protect

  • /private/var/ — where logs, diagnostics, swap, etc. live
  • /Library/ — third-party software installs here
  • ~/Library/ — user application data
  • /Applications/ (the Data volume version via firmlink)
  • /nix/ — Nix store
  • /cores/ — core dumps

This distinction matters for disk accounting: the large mysterious files are almost never in SIP-protected paths. SIP-protected paths are on the SSV, which is sealed, fixed in size, and doesn’t grow.

Checking SIP status

csrutil status
# Output: System Integrity Protection status: enabled.
 
csrutil authenticated-root status
# Output: Authenticated Root status: enabled.

The second command checks the SSV seal. If authenticated-root is disabled, the SSV seal is broken.

TCC — Transparency, Consent, and Control

TCC is macOS’s privacy permission system, implemented by the tccd daemon. It controls which applications can access sensitive user data: contacts, calendar, location, photos, and — relevant for disk accounting — certain filesystem paths.

TCC is a userspace policy. It is enforced by tccd when an application tries to open a protected path. It has nothing to do with filesystem permissions. The files themselves are often readable by root; TCC prevents specific non-root processes from accessing them unless the user has granted permission.

Full Disk Access (FDA)

FDA is a TCC permission category that grants an application access to paths that are otherwise TCC-protected. Without FDA, even a Terminal running as your own user cannot read:

  • ~/Library/Mail/ — Mail message store
  • ~/Pictures/Photos Library.photoslibrary/ — Photos library internals
  • ~/Library/Application Support/MobileSync/Backup/ — iOS device backups
  • Other users’ home directories

Granting FDA (System Settings → Privacy & Security → Full Disk Access → add Terminal or your tool) removes the TCC barrier.

Root bypasses TCC entirely. sudo du -sh ~/Library/Mail/ works without FDA because the process is root.

Which one matters for disk accounting?

When DaisyDisk (or any scanner) reports it cannot see certain paths:

  • If the reason is SIP → the path is on the read-only SSV, its size is fixed and not a source of disk growth, and FDA won’t help
  • If the reason is TCC/FDA → granting FDA will let the scanner see it, and it may contain significant data

For finding large hidden space, the relevant paths are TCC-gated, not SIP-gated. SIP-protected paths don’t grow. TCC-gated paths absolutely can.

See also

Graph View

Backlinks