ClearanceKit

// clearancekit

┌───────────────────────────────────────┐
│  CLEARANCEKIT                         │
│  process → kernel → file_system       │
└───────────────────────────────────────┘

Kernel-level file access control for macOS, bound to code-signing identity.

docs source

// download

version: latest · download: latest.dmg · source: github.com/craigjbass/clearancekit · license: MIT

// how it works

┌──────────┐    AUTH_OPEN     ┌─────────┐
│  process │ ───────────────▶ │ opfilter│
└──────────┘                  └────┬────┘
                                   │ check signature
                                   ▼
                              ┌─────────┐
                              │  policy │ → ALLOW / DENY
                              └─────────┘

A process attempts open(), rename(), unlink(), or another file-system syscall.
The kernel forwards the request to opfilter as an Endpoint Security AUTH event.
opfilter looks up the calling process's signing identity and matches it against policies.
opfilter responds ALLOW or DENY.

// features

code-signature policies Rules match the Team ID and Signing ID embedded in the calling binary, not its path or hash. Survive software updates without maintenance.
jail rules Confine specific processes to an explicit set of allowed path prefixes. Inherited by child processes.
process ancestry Rules can require the access is happening on behalf of a trusted parent process, not just the immediate caller.
native SwiftUI interface Review denied events, build policy as you work, see a live throughput graph. No config files required.
MDM fleet management Policy, allowlist, and jail rules deliver via standard Apple Configuration Profile payloads. No external server.
zero network calls, zero third-party dependencies Built entirely on Apple's own frameworks. No telemetry. No auto-update. Nothing to audit beyond Apple's own toolchain.

// what an unconstrained process can reach

A single postinstall script in a compromised package runs with full user-level access. Without per-process policy, it can read:

~/.ssh/id_*: SSH private keys, usable for lateral movement to servers and cloud environments.
~/.aws/credentials, ~/.config/gcloud/, ~/.azure/: Plaintext cloud credentials and tokens.
~/.git-credentials, ~/.netrc: Silent access to every private repository your account can reach.
~/.gnupg/private-keys-v1.d/: GPG private keys, copyable for offline passphrase cracking.
~/Library/Cookies/Cookies.binarycookies: Safari session cookies.
~/Library/Messages/: iMessage history and attachments.
~/Library/Group Containers/group.com.apple.notes/: Unlocked Apple Notes (CoreData SQLite, readable on disk).
~/Library/Application Support/Signal/attachments.noindex/: Signal Desktop attachments.

// why code signing, not paths or hashes

path / hash MAC

Trusts whatever binary sits at the expected path.
A trojanised binary at that path inherits the policy.
A vulnerability in an allowed process inherits the policy.
Every software update invalidates the hash.
Active development machines need constant policy maintenance.

Trusts the kernel-verified signing identity of the binary.
A trojanised binary carries a different signature and is denied.
A dylib injection changes the loaded code's signature mix and fails the check.
Policies stay valid across all future updates from the same signer.
Policy revisions happen only when you change which software you trust.

// install

Open the .dmg, drag clearancekit to Applications, launch it. Grant Full Disk Access when prompted, then activate the system extension.

No auto-update. Check the releases page for new versions.

// license: MIT · source: github.com/craigjbass/clearancekit · version: latest