mismatched test and remediate for Monterey os_blank_bluray_disable.yaml #254

New Issue

michael · 2026-01-19T18:29:49Z

michael commented

2026-01-19 18:29:49 +00:00

Originally created by @bernstei on GitHub.

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 1b03ed4b0d/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.

Originally created by @bernstei on GitHub. 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.

michael closed this issue

2026-01-19 18:29:49 +00:00

michael commented

2026-01-19 18:29:49 +00:00

@bernstei commented on GitHub:

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?

@bernstei commented on GitHub: 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?

michael commented

2026-01-19 18:29:49 +00:00

@robertgendler commented on GitHub:

Also to add, these are deprecated by Apple and REALLY do not work as functional controls. So people really SHOULD NOT be using them.

@robertgendler commented on GitHub: Also to add, these are deprecated by Apple and REALLY do not work as functional controls. So people really SHOULD NOT be using them.

michael commented

2026-01-19 18:29:49 +00:00

@robertgendler commented on GitHub:

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.

@robertgendler commented on GitHub: 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.

michael commented

2026-01-19 18:29:49 +00:00

@bernstei commented on GitHub:

Changing the mobileconfig alert to deny does fix the failed test.

@bernstei commented on GitHub: Changing the mobileconfig `alert` to `deny` does fix the failed test.

michael commented

2026-01-19 18:29:49 +00:00

@bernstei commented on GitHub:

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.

@bernstei commented on GitHub: 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.

michael commented

2026-01-19 18:29:50 +00:00

@bernstei commented on GitHub:

@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?

@bernstei commented on GitHub: @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?

michael commented

2026-01-19 18:29:50 +00:00

@bernstei commented on GitHub:

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.

@bernstei commented on GitHub: > 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.

michael commented

2026-01-19 18:29:50 +00:00

@robertgendler commented on GitHub:

dev_big_sur_rule_fixes and dev_monterey_rule_fixes will have them since it was basically both OSes

@robertgendler commented on GitHub: `dev_big_sur_rule_fixes` and `dev_monterey_rule_fixes` will have them since it was basically both OSes

michael commented

2026-01-19 18:29:50 +00:00

@robertgendler commented on GitHub:

Probably is

@robertgendler commented on GitHub: Probably is

michael commented

2026-01-19 18:29:50 +00:00

@bernstei commented on GitHub:

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

@bernstei commented on GitHub: 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 ```

michael commented

2026-01-19 18:29:50 +00:00

@bernstei commented on GitHub:

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?

@bernstei commented on GitHub: 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?

michael commented

2026-01-19 18:29:50 +00:00

@robertgendler commented on GitHub:

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.

@robertgendler commented on GitHub: 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.

michael commented

2026-01-19 18:29:50 +00:00

@robertgendler commented on GitHub:

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.

@robertgendler commented on GitHub: 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.

michael commented

2026-01-19 18:29:50 +00:00

@marcindulak commented on GitHub:

These checks are still failing with the latest main 06cc0d2614.
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

@marcindulak commented on GitHub: 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 ```

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: usnistgov/macos_security#254