Skip to content

SYSTEM Cited by 1 source

Santa

Santa is an open-source macOS binary authorization tool originally developed at Google, now stewarded by North Pole Security. It controls which binaries (Mach-O executables) are allowed to execute on a Mac via a kernel/EndpointSecurity-framework client, a local rule cache, and a pull-based sync server that distributes rules from a central ruleset to every laptop in the fleet.

Operates in two modes:

  • Monitoring mode — passively records every binary execution. No blocking. Used to build a data-driven allowlist from observed fleet behaviour (patterns/data-driven-allowlist-monitoring-mode).
  • Lockdown mode — applies allow/block rules; any binary without a matching allow rule is blocked.

Rule types

From northpole.dev/features/binary-authorization:

  • Binary — exact SHA-256 of the binary on disk. Tampering invalidates the rule. The most precise rule type.
  • SigningID — matches a specific developer signing identity (e.g., EQHXZ8M8AV:com.google.Chrome). Precise within an app but labour-intensive when apps have many helper binaries with separate signing IDs.
  • TeamID — matches everything signed by an Apple Developer Team ID (e.g., EQHXZ8M8AV = Google). Low-maintenance but broad — admits every app the team ships.
  • Compiler / Transitive — auto-allow binaries produced by specified compilers; useful for development environments where locally-built binaries would otherwise be blocked.
  • PathRegex — allow/block by file path. Flagged as bypass-risky and advised to use sparingly.

Default resolution: explicit Binary rule > SigningID > TeamID > Compiler/Path > block-if-no-match (in lockdown mode). Deny always overrides allow.

File Access Authorization (FAA)

Beyond binary exec control, Santa also supports FAA: restrict which processes can read specific files. Canonical use case at Figma: lock browser-cookie files so only the browser binary itself can read them, defending against credential theft by scripts that could otherwise read Chrome cookies from disk. FAA has ~zero user workflow impact — often shippable independently before lockdown mode is attempted.

Static rules

Santa supports static rules in the local configuration that apply regardless of sync-server state. Essential hedge for a fleet whose rule-sync payload gets large: critical apps (MDM client, Chrome, Slack, Zoom) can be pinned in the static config so they function on a brand-new laptop whose first sync is still in progress. See patterns/static-allowlist-for-critical-rules.

Sync server

Santa clients pull rules from a sync server on a configurable interval (default 60 seconds). The protocol is open but the server is BYO. Canonical open-source implementation: Airbnb's systems/rudolph; Google's internal fleet uses a Firebase Cloud Messaging push variant not publicly available. Figma forked and customised Rudolph.

Known edge cases

  • go run race condition with Compiler rules (upstream issue) — go run compiles and executes in one step; Santa can't create the Binary rule for the compiled output before the OS invokes it, producing a block. go build then run works fine.
  • Ad-hoc codesign per-machine uniqueness — tools that invoke codesign --sign - (e.g., Anaconda's per-user Python build) produce distinct hashes per machine, defeating fleet-wide Binary rules; only very-permissive Compiler or PathRegex rules cover them, which pushes toward per-group rule scoping.

Seen in

  • sources/2026-04-21-figma-rolling-out-santa-without-freezing-productivity — Figma's fleet-wide rollout to 100% of company MacBooks over ~3 months. FAA shipped first (browser-cookie lock). Then monitoring mode across the full fleet → data-driven allowlist → staged lockdown rollout with a self-service Slack approval loop. Steady-state scale: ~150 global allowlist rules + ~80,000 auto-generated Package Rule binaries + ~50 blocklist entries + ~50 PathRegex rules + ~10 Compiler rules; P95 3–4 blocks per user per week, >90% resolved via self-service.
Last updated · 200 distilled / 1,178 read