usnistgov/macos_security
1
0
Fork 0
mirror of https://github.com/usnistgov/macos_security.git synced 2026-02-03 14:03:24 +00:00
Code Issues 21 Actions Packages Projects Releases Wiki Activity

system_settings_sleep_enforce rule has same detection limitations as os_sleep_and_display_sleep_apple_silicon_enable on Apple Silicon #19

New Issue
Closed
opened 2026-01-19 18:28:57 +00:00 by michael · 0 comments
michael commented 2026-01-19 18:28:57 +00:00
Owner
Copy Link

Originally created by @phaninder-scalefusion on GitHub.

Summary

The system_settings_sleep_enforce rule in macOS Sonoma has similar limitations as os_sleep_and_display_sleep_apple_silicon_enable (issue #576). It fails to correctly detect Apple Silicon MacBooks, lacks CPU architecture validation, and includes sleep/display logic that may conflict with remediation, causing false positives. Since os_sleep_and_display_sleep_apple_silicon_enable already checks and remediates the same settings, this rule appears redundant.

Steps to reproduce

  1. Run the system_settings_sleep_enforce check script on an Apple Silicon MacBook.
  2. Observe that Apple Silicon MacBooks may not be correctly identified due to missing CPU architecture checks.
  3. Observe potential false positives due to sleep vs displaysleep evaluation conflicts.
  4. Compare functionality with os_sleep_and_display_sleep_apple_silicon_enable which already covers the same remediation.

Operating System version

macOS Sonoma

Intel or Apple Silicon

Apple Silicon

What is the current bug behavior?

  1. The rule does not correctly detect Apple Silicon MacBooks, causing skipped or incorrect evaluations.
  2. CPU architecture detection is missing, so Intel and Apple Silicon Macs are not distinguished.
  3. The sleep vs displaysleep check may conflict with remediation values, producing false positives.
  4. Redundant functionality exists because os_sleep_and_display_sleep_apple_silicon_enable already checks and remediates the same settings.

What is the expected correct behavior?

  1. The rule should correctly identify Apple Silicon MacBooks and evaluate sleep settings as per CIS documentation.
  2. CPU architecture should be checked to differentiate Intel and Apple Silicon Macs.
  3. Sleep vs displaysleep logic should align with remediation to avoid false positives.
  4. Consider removing the rule or consolidating it with os_sleep_and_display_sleep_apple_silicon_enable to avoid redundancy.

Relevant logs and/or screenshots

# Similar checks as issue #576 would fail on Apple Silicon MacBooks:
$ /usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | grep -q "MacBook"
# Returns non-zero on Apple Silicon

$ /usr/bin/sudo /usr/sbin/system_profiler SPHardwareDataType | grep -e MacBook
# Correctly detects MacBook on Apple Silicon

$ /usr/bin/sudo /usr/sbin/sysctl -n machdep.cpu.brand_string
# Returns: "Apple M3 Pro" or similar

Output of checks

The rule may produce false positives, skip checks, or incorrectly report compliance due to detection and logic limitations.

Possible fixes

  1. Remove system_settings_sleep_enforce for Apple Silicon or consolidate it with os_sleep_and_display_sleep_apple_silicon_enable.
  2. Align detection logic with issue #576, including proper Apple Silicon detection, CPU architecture check, and sleep vs displaysleep logic.
Originally created by @phaninder-scalefusion on GitHub. ### Summary The system_settings_sleep_enforce rule in macOS Sonoma has similar limitations as os_sleep_and_display_sleep_apple_silicon_enable ([issue #576](https://github.com/usnistgov/macos_security/issues/576)). It fails to correctly detect Apple Silicon MacBooks, lacks CPU architecture validation, and includes sleep/display logic that may conflict with remediation, causing false positives. Since os_sleep_and_display_sleep_apple_silicon_enable already checks and remediates the same settings, this rule appears redundant. ### Steps to reproduce 1. Run the system_settings_sleep_enforce check script on an Apple Silicon MacBook. 2. Observe that Apple Silicon MacBooks may not be correctly identified due to missing CPU architecture checks. 3. Observe potential false positives due to sleep vs displaysleep evaluation conflicts. 4. Compare functionality with os_sleep_and_display_sleep_apple_silicon_enable which already covers the same remediation. ### Operating System version macOS Sonoma ### Intel or Apple Silicon Apple Silicon ### What is the current bug behavior? 1. The rule does not correctly detect Apple Silicon MacBooks, causing skipped or incorrect evaluations. 2. CPU architecture detection is missing, so Intel and Apple Silicon Macs are not distinguished. 3. The sleep vs displaysleep check may conflict with remediation values, producing false positives. 4. Redundant functionality exists because os_sleep_and_display_sleep_apple_silicon_enable already checks and remediates the same settings. ### What is the expected correct behavior? 1. The rule should correctly identify Apple Silicon MacBooks and evaluate sleep settings as per CIS documentation. 2. CPU architecture should be checked to differentiate Intel and Apple Silicon Macs. 3. Sleep vs displaysleep logic should align with remediation to avoid false positives. 4. Consider removing the rule or consolidating it with os_sleep_and_display_sleep_apple_silicon_enable to avoid redundancy. ### Relevant logs and/or screenshots ``` # Similar checks as issue #576 would fail on Apple Silicon MacBooks: $ /usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | grep -q "MacBook" # Returns non-zero on Apple Silicon $ /usr/bin/sudo /usr/sbin/system_profiler SPHardwareDataType | grep -e MacBook # Correctly detects MacBook on Apple Silicon $ /usr/bin/sudo /usr/sbin/sysctl -n machdep.cpu.brand_string # Returns: "Apple M3 Pro" or similar ``` ### Output of checks The rule may produce false positives, skip checks, or incorrectly report compliance due to detection and logic limitations. Possible fixes 1. Remove system_settings_sleep_enforce for Apple Silicon or consolidate it with os_sleep_and_display_sleep_apple_silicon_enable. 2. Align detection logic with [issue #576](https://github.com/usnistgov/macos_security/issues/576), including proper Apple Silicon detection, CPU architecture check, and sleep vs displaysleep logic.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#19
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?