Skip to content

TCC & Sandboxing

macOS employs a layered security architecture to restrict application behavior and protect user data. Two critical components are Transparency, Consent, and Control (TCC) and sandboxing. These mechanisms work together to enforce strict access controls, limit privilege escalation, and prevent unauthorized system modifications. Understanding their roles is essential for both defensive hardening and red teaming operations.

TCC: Managing Access to Protected Resources

TCC is a framework that enforces user consent for access to sensitive system resources. It tracks application usage of protected domains (e.g., camera, microphone, location) and ensures apps comply with user permissions.

Key Concepts

  • Domains: TCC defines access categories (e.g., Accessibility, Camera, Location). Apps must explicitly request access to these domains.
  • User Consent: Users grant permissions via system dialogs (e.g., "Allow [App] to access your camera").
  • TCC Database: Permissions are stored in the com.apple.TCC preference file (~/Library/Preferences/com.apple.TCC.plist).

Example: Checking TCC Permissions

# List TCC domains and their access status  
tccutil query -a

# Check if an app has access to a specific domain  
tccutil query -a -d "Accessibility"

Evasion Considerations

  • Bypassing TCC: Attackers may attempt to spoof user consent (e.g., via UI automation) or exploit vulnerabilities in TCC's permission logic.
  • Persistence: Malware might persist by requesting access to domains like Accessibility or ScreenCapture, which are often granted without explicit user action.

Sandboxing: Restricting Application Behavior

Sandboxing isolates apps from critical system resources, limiting their ability to modify files, access network services, or interact with hardware. It is enforced by the App Sandboxing mechanism in macOS.

Key Constraints

  • File System: Sandboxed apps can only access files in their own sandboxed directory (e.g., ~/Library/Containers/) or user-owned paths (e.g., ~/Documents).
  • Network: Apps must explicitly declare allowed network hosts in their entitlements.
  • Process Isolation: Sandboxed apps cannot spawn arbitrary processes or access kernel-level APIs.

Example: Verifying Sandboxing

# Check if an app is sandboxed  
codesign -d --entitlements :- /path/to/your.app/Contents/Info.plist

Evasion Considerations

  • Bypassing Sandboxing: Attackers may exploit kernel vulnerabilities (e.g., CVE-2021-40444) or use privilege escalation to break sandbox constraints.
  • Privileged APIs: Some apps (e.g., system tools) have elevated entitlements, allowing access to restricted resources.

TCC and Sandboxing: Complementary Security Layers

While TCC focuses on user consent for specific resources, sandboxing enforces strict runtime restrictions. Together, they create a robust defense-in-depth strategy:
1. TCC ensures apps cannot access protected domains without user approval.
2. Sandboxing limits what apps can do even if they gain access to certain resources.

For example, a malicious app might request Accessibility access (via TCC) to control the screen, but sandboxing would prevent it from modifying system files or executing arbitrary code.

Defensive Implications for Red Teams

  • Target TCC Domains: Prioritize apps with access to high-privilege domains (e.g., ScreenCapture, Accessibility).
  • Exploit Sandboxing Gaps: Identify apps with elevated entitlements or kernel vulnerabilities that could bypass sandbox constraints.
  • Leverage User Consent: Use social engineering to gain access to domains like Accessibility or Microphone, which are often granted without scrutiny.

Key takeaways

  • TCC and sandboxing are foundational to macOS security, enforcing user consent and runtime restrictions.
  • TCC manages access to protected resources, while sandboxing limits app behavior.
  • Red teams should target TCC domains and sandboxing weaknesses to achieve persistence or privilege escalation.
  • Tools like tccutil and codesign are critical for analyzing and interacting with these security mechanisms.
  • Always operate within authorized testing boundaries to avoid violating security policies.