Clearancekit

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. The ECDSA private key used to sign the on-disk policy database (`/Library/Application Support/clearancekit/store.db`) is stored in the macOS System Keychain. The key was created via the two-step pattern `SecKeyCreateRandomKey` (in-memory) followed by `SecItemAdd(kSecValueRef:, kSecAttrAccess:)` (persist). Prior to version 5.0.10, for `kSecClassKey` items in the legacy System Keychain, `kSecAttrAccess` passed to `SecItemAdd` is silently ignored — the persisted key inherits no ACL restriction. The same access builder applied to `kSecClassGenericPassword` items correctly binds the ACL, making this bug specific to the EC key. The result is that any process running as root can use the key to produce valid signatures over arbitrary policy content. Version 5.0.10 fixes the issue. No known workarounds are available. Disabling the system extension and manually removing the System Keychain item labelled `clearancekit policy signing key` would prevent the forged-signature path but also disables policy enforcement.

Published: 2026-07-20T21:17:22.539Z
Updated: 2026-07-21T14:56:09.708Z

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to version 5.0.10, each table in the on-disk SQLite policy store (`/Library/Application Support/clearancekit/store.db`) is verified using an ECDSA signature stored in the `data_signatures` table. The signed payload contains only the canonical row content, with no version counter or freshness binding. An attacker who can write `store.db` and the matching `data_signatures` row — feasible during the opfilter-update window when the Endpoint Security filter is offline, or via offline-boot / decrypted-backup scenarios — can substitute a previously-captured legitimately-signed snapshot. opfilter accepts the older snapshot as fully valid on next boot because the existing signatures still verify. Version 5.0.10 patches the issue.

Published: 2026-07-20T21:12:26.245Z
Updated: 2026-07-21T14:09:08.557Z

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to 5.0.6, the opfilter Endpoint Security system extension (bundle ID uk.craigbass.clearancekit.opfilter) can be suspended with SIGSTOP or kill -STOP, or killed with SIGKILL/SIGTERM, by any process running as root. While the extension is suspended, all AUTH Endpoint Security events time out and default to allow, silently disabling ClearanceKit's file-access policy enforcement for the duration of the suspension. This vulnerability is fixed in 5.0.6.

Published: 2026-04-21T17:41:53.580Z
Updated: 2026-04-21T20:36:53.181Z

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to 5.0.5, ClearanceKit incorrectly treats a process with an empty Team ID and a non-empty Signing ID as an Apple platform binary. This bug allows a malicious software to impersonate an apple process in the global allowlist, and access all protected files. This vulnerability is fixed in 5.0.5.

Published: 2026-04-21T17:37:05.064Z
Updated: 2026-04-21T18:35:04.258Z

ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to 5.0.4-beta-1f46165, ClearanceKit's Endpoint Security event handler only checked the source path of dual-path file operations against File Access Authorization (FAA) rules and App Jail policies. The destination path was ignored entirely. This allowed any local process to bypass file-access protection by using rename, link, copyfile, exchangedata, or clone operations to place or replace files inside protected directories. This vulnerability is fixed in 5.0.4-beta-1f46165.

Published: 2026-04-10T20:19:35.909Z
Updated: 2026-04-15T15:12:11.855Z