system_settings_wake_network_access_disable resets on check #83

Closed
opened 2026-01-19 18:29:10 +00:00 by michael · 1 comment
Owner

Originally created by @exolab on GitHub.

I have generated a cis_lvl1_compliance.sh script.

When I run ./sudo cis_lvl1_compliance.sh --fix, the setting for system_settings_wake_network_access_disable is fixed, as shown by the subsequent check:

/usr/bin/pmset -g custom | /usr/bin/awk '/womp/ { sum+=$2 } END {print sum}'
0

If I then run a check, that check seems to manipulate the setting somehow:

> ./sudo cis_lvl1_compliance.sh --check
...
Fri Sep 13 13:26:30 UTC 2024 system_settings_wake_network_access_disable failed (Result: 2, Expected: "{'integer': 0}")
Fri Sep 13 13:26:31 UTC 2024 system_settings_wifi_menu_enable passed (Result: 18, Expected: "{'integer': 18}")
Results written to /Library/Preferences/org.cis_lvl1.audit.plist

>  /usr/bin/pmset -g custom | /usr/bin/awk '/womp/ { sum+=$2 } END {print sum}'  
2

I have waited for 20 minutes in between the two calls, verifying the value was still 0 right before running the check, in order to exclude the possibility of the setting being manipulated by some other process.

What am I missing?

Originally created by @exolab on GitHub. I have generated a `cis_lvl1_compliance.sh` script. When I run `./sudo cis_lvl1_compliance.sh --fix`, the setting for `system_settings_wake_network_access_disable` is fixed, as shown by the subsequent check: ``` /usr/bin/pmset -g custom | /usr/bin/awk '/womp/ { sum+=$2 } END {print sum}' 0 ``` If I then run a check, that check seems to manipulate the setting somehow: ``` > ./sudo cis_lvl1_compliance.sh --check ... Fri Sep 13 13:26:30 UTC 2024 system_settings_wake_network_access_disable failed (Result: 2, Expected: "{'integer': 0}") Fri Sep 13 13:26:31 UTC 2024 system_settings_wifi_menu_enable passed (Result: 18, Expected: "{'integer': 18}") Results written to /Library/Preferences/org.cis_lvl1.audit.plist > /usr/bin/pmset -g custom | /usr/bin/awk '/womp/ { sum+=$2 } END {print sum}' 2 ``` I have waited for 20 minutes in between the two calls, verifying the value was still 0 right before running the check, in order to exclude the possibility of the setting being manipulated by some other process. What am I missing?
Author
Owner

@exolab commented on GitHub:

Sort of answering my own question, at least in part.

/usr/bin/mcxrefresh -u $CURR_USER_UID is the culprit. Given the very short an informative man page of mcxrefresh, I will now try to find out what that means exactly.

@exolab commented on GitHub: Sort of answering my own question, at least in part. ```/usr/bin/mcxrefresh -u $CURR_USER_UID``` is the culprit. Given the very short an informative man page of mcxrefresh, I will now try to find out what that means exactly.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#83