tcc: fail-safe SIP detection for hosts in Custom Configuration - #1259
Open
rcurranmoz wants to merge 1 commit into
Open
rcurranmoz wants to merge 1 commit into
rcurranmoz wants to merge 1 commit into
Conversation
The SIP detection in tcc_perms.sh and add_tcc_perms.sh (added in #1152) matched output containing "disabled" to decide whether to write the legacy system-DB TCC entries. Hosts whose `csrutil status` returns `"unknown (Custom Configuration)"` (observed on r8-109 and r8-154 during PR #1152 validation) don't match that regex — they get treated as SIP-on, and the system-DB writes their configuration actually depends on get silently skipped. Existing entries persist as long as nothing clears TCC.db, so this hasn't broken anything today. But if a Custom-Configuration host ever gets its system TCC.db cleared (EACS, OS reinstall, manual reset), the next puppet run wouldn't re-apply the entries. Fix: invert the default. Treat the host as SIP-off unless csrutil clearly says "enabled" (matching the canonical `System Integrity Protection status: enabled.` line). Fail-safe to the legacy path — anything ambiguous preserves the write path the existing fleet has always relied on. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #1152. Inverts the default in the SIP detection block of
tcc_perms.shandadd_tcc_perms.shso anything other than a cleanSystem Integrity Protection status: enabled.is treated as SIP-off (legacy behavior).The current logic:
misses hosts whose
csrutil statusreturns"unknown (Custom Configuration)". Those hosts silently fall through to the SIP-on code path and the legacy system-DB writes they rely on get skipped.Where this was observed
During validation of #1152, two production staging r8 hosts (
macmini-r8-109,macmini-r8-154) reported this state:Neither is actively broken today — the entries from previous master-branch puppet runs persist. But if either loses its system TCC.db (EACS, OS reinstall, sqlite reset), the next puppet run wouldn't re-apply them.
The fix
Invert the default so ambiguity falls through to the legacy path:
Clean SIP-off (
disabled.) and clean SIP-on (enabled.) hosts behave the same as before. Only ambiguous / edge-case output changes behavior — and it changes to the safer (write the legacy entries) direction.Test plan
csrutil statusoutputs observed in the fleet:System Integrity Protection status: enabled.→ matches → SIP_DISABLED=false ✓System Integrity Protection status: disabled.→ doesn't match → SIP_DISABLED=true ✓System Integrity Protection status: unknown (Custom Configuration).→ doesn't match → SIP_DISABLED=true ✓ (fail-safe to legacy)macmini-r8-109ormacmini-r8-154(Custom Configuration) — expect the system-DB writes to happen this time.🤖 Generated with Claude Code