macos_security
macos_security copied to clipboard
mismatched test and remediate for Monterey os_blank_bluray_disable.yaml
I've applied the os_blank_bluray_disable generated mobileconfig (checked out monterey_rev2 tag), and it sets the following xml dict
<key>blankbd</key>
<array>
<string>alert</string>
<string>eject</string>
</array>
However, the test is apparently looking for blankbd
value of deny,reject
https://github.com/usnistgov/macos_security/blob/1b03ed4b0d0760e7e1e66893df293859d54fa23f/rules/os/os_blank_bluray_disable.yaml
, and when I the test command I get just deny
.
Can someone confirm whether or not this is expected? I'm surprised by "deny", which matches neither the "alert" or "eject" in the xml dict, and the fact that only one value is printed, rather than the expected two.
This document (I have no idea if it's the latest) https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf mentioned deny
and eject
(p. 55), but not alert
.
The same is true for other mount-controls rules, I think.
Changing the mobileconfig alert
to deny
does fix the failed test.
Are you on 12.3 or prior? I wonder if this was something that worked on 12.2 and under properly. All the tests similar to that come back as deny not deny, eject. There would have been some reason we put "deny, eject". Hard to say at the moment without setting up a system on the previous update.
Also to add, these are deprecated by Apple and REALLY do not work as functional controls. So people really SHOULD NOT be using them.
I'm on 12.3.1. If I replace "alert" with "deny" in the mobileconfig I get the expected "deny,eject" in the test command. I think it's just that "alert" is not a supported value.
The latest I can find in the STIG (from 2022 01 19) V-252537 APPL-12-005051 says "deny", not "alert". Any chance that "alert" in the mobileconfig is just a mistake?
Probably is
Also to add, these are deprecated by Apple and REALLY do not work as functional controls. So people really SHOULD NOT be using them.
That needs to be taken up with the people who wrote the STIG and defined the lack of these settings as a finding.
Same issue applies to
rules/os/os_blank_bluray_disable.yaml
rules/os/os_blank_cd_disable.yaml
rules/os/os_blank_dvd_disable.yaml
rules/os/os_dvdram_disable.yaml
rules/os/os_removable_media_disable.yaml
@robertgendler Thanks for taking care of this (and the others I submitted around the same time). Is there a particular corresponding branch they're doing into that I should be testing?
dev_big_sur_rule_fixes
and dev_monterey_rule_fixes
will have them since it was basically both OSes
Thanks. Is there a best practices for keeping up with the patches? Or is it just stay on the main branch and merge specific dev branches if they seem needed?
We usually test out fixes and changes in the dev_* branch. Then we move those into the OS branch, then after some more testing of the OS branches to make sure things didn't go awry with the merging, we then merge into main and do a release.
Think of the dev as sort of nightly, os more like stable branch, and main as long term release. If you're able to use the dev branches, that's the best place to catch issues and bugs.
These checks are still failing with the latest main https://github.com/usnistgov/macos_security/commit/06cc0d2614da5b6f478b6f1ff45b059bb7c6aa5a. When will the fixes be merged?
sw_vers
# Output:
# ProductName: macOS
# ProductVersion: 12.5.1
# BuildVersion: 21G83
For example
# os_blank_bluray_disable failed (Result: deny, Expected: {string: deny,eject})
/usr/bin/osascript -l JavaScript << EOS
ObjC.unwrap($.NSUserDefaults.alloc.initWithSuiteName('com.apple.systemuiserver')\
.objectForKey('mount-controls'))["blankbd"]
EOS
# Output:
# deny
These are on the OS branches, if you do a pull from there that and many other things are fixed and updated. Our next release and merge into main will be when Ventura is released.