MacOs 26 - CIS_Benchmark - Policy Failures #48516

Fleet versions

• Discovered: 4.86.2
• Reproduced: 4.86.2

Web browser and operating system: macOS 26.5.1

💥 Actual behavior

Three CIS benchmark policies on macOS 26 fail or produce incorrect results:

5.1.3 — nvram_info always reports AMFI as enabled on macOS 26
nvram_info returns amfi_enabled = 1 even when AMFI is disabled via sudo nvram boot-args="amfi_get_out_of_my_way=0x1". The CIS 5.1.3 policy always passes regardless of actual AMFI state. Root cause: nvram_info.go:37 checks strings.Contains(res, "amfi_get_out_of_my_way=1") — macOS 26 preserves the hex prefix (0x1), so the substring match silently fails.

5.7 — Default macOS 26 screensaver rule use-login-window-ui causes false FAIL
On macOS 26, the default system.login.screensaver rule is ["use-login-window-ui"] — a new screensaver authorization mechanism. The CIS 5.7 policy treats this as a FAIL on all freshly enrolled, unconfigured macOS 26 hosts.

5.11 — sudo_info Fleetd extension stores boolean flags as null, breaking sudo logging policy
The sudo_info extension stores boolean sudo flags (e.g., Defaults log_allowed) as null in the JSON blob. This makes it impossible to distinguish "flag is enabled" from "flag is absent." The query workaround in PR #48282 (json_type IS NOT NULL) mitigates the symptom but the extension itself is incorrect.

🛠️ Expected behavior

• 5.1.3: When AMFI is disabled (amfi_get_out_of_my_way=0x1 in NVRAM), nvram_info should return amfi_enabled = 0 and the CIS 5.1.3 policy should FAIL. Fix: also check strings.Contains(res, "amfi_get_out_of_my_way=0x1") in orbit/pkg/table/nvram_info/nvram_info.go.
• 5.7: use-login-window-ui needs security team review to determine if it provides equivalent protection to authenticate-session-owner. If it does, the query should accept it as a passing state: OR rule LIKE '%use-login-window-ui%'.
• 5.11: When Defaults log_allowed is configured in sudoers, sudo_info should store the key as "true" so callers can distinguish enabled from absent. Fix in orbit/pkg/table/sudo_info/: detect lines with no = value and store as "true" instead of null.

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

5.1.3 — nvram_info hex prefix mismatch

1. Enroll a macOS 26 host in Fleet.
2. Boot into Recovery and run csrutil disable, then reboot.
3. Run sudo nvram boot-args="amfi_get_out_of_my_way=0x1" and reboot.
4. Run live query: SELECT * FROM nvram_info; — observe amfi_enabled = 1 (incorrect).
5. Confirm raw NVRAM: SELECT value FROM nvram WHERE name = 'boot-args'; — returns amfi_get_out_of_my_way=0x1.
6. Run CIS 5.1.3 policy — observe it passes (false positive).

5.7 — use-login-window-ui false FAIL

1. Enroll a freshly enrolled macOS 26 host with no custom screensaver authdb configuration.
2. Run live query: SELECT JSON_EXTRACT(json_result, '$.rule') FROM authdb WHERE right_name = 'system.login.screensaver'; — observe ["use-login-window-ui"].
3. Run the CIS 5.7 policy — observe it returns no rows (FAIL) on an unconfigured host.

5.11 — sudo_info null boolean flags

1. Enroll a macOS 26 host in Fleet.
2. Add Defaults log_allowed to /etc/sudoers.d/.
3. Confirm the setting is active: sudo sudo -V | grep -i "log when a command is allowed" — key appears.
4. Run live query: SELECT JSON_EXTRACT(json_result, '$.Log when a command is allowed by sudoers') FROM sudo_info; — observe null instead of "true".

🕯️ More info

For context on what we were doing refer to #35120