Skip to content

CONCEPT Cited by 1 source

Binary authorization

Binary authorization is the security control that restricts a device or host to running only pre-approved executable binaries. Everything else is blocked at exec-syscall time. The allowlist is authoritative — default deny, opt-in allow.

The point is attack-surface reduction: malware delivered via email, a browser download, an unapproved USB, or a supply-chain-compromised installer never runs because its hash / signer isn't on the list. Security teams no longer have to vet, harden, and monitor every binary that might run on the fleet — only the bounded set in the allowlist.

What it does and doesn't cover

  • Covers: native executables (Mach-O on macOS, ELF on Linux, PE on Windows) that the kernel invokes via exec() / CreateProcess / equivalent.
  • Doesn't cover: scripts interpreted by an already-allowed binary (Python scripts run by an allowed python3 binary, JavaScript run by an allowed browser, shell commands run by an allowed shell), browser extensions, IDE plugins, or anything that executes as data inside an already-running process.
  • Therefore one part of a layered security posture, not a complete exploit barrier.

Typical rule-type hierarchy

From most-precise to most-permissive:

  1. Binary hash (SHA-256) — pins one exact binary. Breaks on upgrade because new version has a new hash.
  2. Code signature — signing identity — pins a specific developer signing identity (one app, all versions signed the same way).
  3. Code signature — team/publisher identity — allows every app from a developer's entire signing certificate (all their apps, all versions).
  4. Compiler / transitive rule — allow whatever a specified compiler produces on this machine (covers locally-built binaries without enumerating them).
  5. Path-based rule — allow binaries under specific filesystem paths. Flagged as bypass-risky (anything the attacker can write to the path gets allowed).

Choosing between these is a precision / maintenance trade-off: narrower = more labour, broader = larger attack surface.

Rollout methodology

Binary authorization is disruptive to turn on because every binary the fleet runs needs a rule. The canonical low-disruption rollout is the two-mode pattern Santa embodies:

  1. Deploy the tool in monitoring mode, logging every binary execution without blocking anything.
  2. Mine the monitoring data to build the allowlist (patterns/data-driven-allowlist-monitoring-mode).
  3. Progressively switch cohorts to lockdown mode, adding rules for the remaining unknowns as they surface (patterns/cohort-percentage-rollout).
  4. Pair lockdown with a self-service approval flow (patterns/self-service-block-approval) so users can unblock safe-but-uncommon binaries in seconds.
  5. Give users a revert-to-monitoring escape hatch (patterns/rollout-escape-hatch) during rollout; retire it at 100% cohort.
  • File access authorization (FAA) — restricts which processes can read/write specific files. Same tool family (Santa supports both) but orthogonal — binary authz = "what can run", FAA = "which process can touch this file". FAA often ships earlier because it has no user workflow impact.
  • concepts/device-trust — complementary: device trust attests the device is corporate-managed, binary authz controls what runs on that trusted device. Both are end-of-user-workstation controls in a zero-trust posture.
  • Code signing — binary authorization depends on it. Without developer code signatures you're stuck with raw hashes, which don't survive upgrades.

Seen in

  • sources/2026-04-21-figma-rolling-out-santa-without-freezing-productivity — Figma rolled out Santa fleet-wide. Monitoring → SigningID + TeamID-dominated allowlist covering most executions → lockdown in cohorts, handling three residual categories: Apple-signed without rule yet (proactive review into allow / block / personal rule), unsigned locally-built (Compiler rules), unsigned from package managers (Package Rule auto-generation). Steady state: ~150 allowlist + ~50 blocklist + ~80,000 auto-generated Binary rules from ~200 Package rules; P95 3–4 blocks per user per week,

    90% self-resolved.

Last updated · 200 distilled / 1,178 read