sysprefs_screensaver_ask_for_password_delay_enforce not remediated

[marcindulak]

Summary

sysprefs_screensaver_ask_for_password_delay_enforce appears not remediated. I'm using the main branch https://github.com/usnistgov/macos_security/commit/06cc0d2614da5b6f478b6f1ff45b059bb7c6aa5a.

Steps to reproduce

On a fresh system, execute the compliance script generated from baseline (e.g. https://github.com/usnistgov/macos_security/blob/main/baselines/cis_lvl2.yaml) which includes this rule, and apply remediation with "3. Run Commands to remediate non-compliant settings". Then load the com.apple.screensaver.mobileconfig into "System Preferences -> Profiles", enroll the machine into an MDM. Run the "2. Run New Compliance Scan" again.

Operating System version

sw_vers
# Output:
# ProductName:      macOS
# ProductVersion:   12.5.1
# BuildVersion:     21G83

# Chip: Apple Silicon M1

What is the current bug behavior?

sysprefs_screensaver_ask_for_password_delay_enforce failed (Result: 300, Expected: {integer: 5})

/usr/bin/osascript -l JavaScript << EOS
$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\
.objectForKey('askForPasswordDelay').js
EOS
# Output:
# 300

It actually appears that the 300 seconds (5 minutes) is needed from the screen saver activation until the password lock is in effect, so the above cli appears correct and the below UI incorrect.

It seems like to mobileconfig is not effective, despite the Profiles menu showing the profile is added.

I'm not sure what is going one here, maybe there is another profile that overwrites the value and takes precedence? Or is this mobileconfig no longer effective? https://github.com/usnistgov/macos_security/blob/06cc0d2614da5b6f478b6f1ff45b059bb7c6aa5a/rules/sysprefs/sysprefs_screensaver_ask_for_password_delay_enforce.yaml#L51-L53

I still need to perform a manual check of the profiles to see if I find duplicates after I get hold of the machine again. If it turns out that a duplicate mobileconfig is the reason, maybe there is a way to add a rule that checks for duplicate settings as part of the compliance script? Choosing some other values than 300 and 5 may also help in understanding what is going on.

What is the expected correct behavior?

sysprefs_screensaver_ask_for_password_delay_enforce passed (Result: 5, Expected: {integer: 5})

Relevant logs and/or screenshots

Output of checks

sysprefs_screensaver_ask_for_password_delay_enforce failed (Result: 300, Expected: {integer: 5})

Possible fixes

Unknown

[robertgendler]

This is odd.

bob@PN111128 macos_security % /usr/bin/osascript -l JavaScript << EOS
$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\
.objectForKey('askForPasswordDelay').js
EOS
5
bob@PN111128 macos_security % 

So the only thing I can think of is a conflicting profile installed on your machine. Run sudo /usr/bin/profiles -P -o stdout and search to see if askForPasswordDelay is there multiple times.

[marcindulak]

I checked sudo /usr/bin/profiles -P -o stdout | grep askForPasswordDelay and there is only one hit askForPasswordDelay = 5;, but this setting is not enforced. The device is managed additionally by Microsoft Intune, and none of the Intune profiles, inspected visually on the device include any screensaver details. The "System Preferences -> Security & Privacy -> General" has a grayed-out "Require password 5 minutes after sleep or screen saver begins".

Even if I manually remove and add again the com.apple.screensaver.mobileconfig profile containing askForPasswordDelay of 5, it is not enforced, and askForPasswordDelay of 300 seconds continues to be used.

As soon as I "Remove" the device from Intune, the expected askForPasswordDelay of 5 is detected

/usr/bin/osascript -l JavaScript << EOS
$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\
.objectForKey('askForPasswordDelay').js
EOS
5

I "Enroll" the device again, and askForPasswordDelay of 300 comes back.

It's worrying that one could have conflicting settings without being warned about them. I'll close the issue unless there is a way to further debug it. Maybe conflicting profile settings get logged somewhere?

[robertgendler]

This reminds me of our finding with password policy in a sense.

Turns out they can be wrote to com.apple.screensaver and com.apple.mobiledevice.passwordpolicy based off of the screensaver profile has require password key. I wonder if some other profile you're not expecting is doing this. I'm not sure how you could test other than going 1 by 1 and seeing if the value is set to 300.