mobileconfig creation ignores exempt preferences settings #291

New Issue

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

michael commented

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

Originally created by @noambernstein on GitHub.

Originally assigned to: @golbiga on GitHub.

Summary

settings applied by mobileconfig ignore exempt preferences settings

Steps to reproduce

set the defaults plist in /Library/Preferences/org.PROFILE.plist exempt entry to true (and exempt_reason) for a rule that is enforced by mobileconfig, e.g. os_camera_disable. Then generate the mobileconfigs with scripts/generate_guidance.py -p build/baselines/stig_6390.yaml. The resulting mobileconfig will contain the entry that disables the camera, even though it should be exempt. Only the [source,bash] fixes take exempt into account, from what I can tell,

Operating System version

11.3.0

What is the current bug behavior?

things are disabled by the generated mobileconfig files even if they should not be.

What is the expected correct behavior?

rules that are exempt should not produce entries in the generated mobileconfig files.

Possible fixes

modify generate_guidance.py -y, I suppose, to read the preferences before deciding if a rule's mobileconfig entry should be created.

Originally created by @noambernstein on GitHub. Originally assigned to: @golbiga on GitHub. ### Summary settings applied by mobileconfig ignore exempt preferences settings ### Steps to reproduce set the defaults plist in /Library/Preferences/org.PROFILE.plist exempt entry to true (and exempt_reason) for a rule that is enforced by mobileconfig, e.g. os_camera_disable. Then generate the mobileconfigs with `scripts/generate_guidance.py -p build/baselines/stig_6390.yaml`. The resulting mobileconfig will contain the entry that disables the camera, even though it should be exempt. Only the [source,bash] fixes take exempt into account, from what I can tell, ### Operating System version 11.3.0 ### What is the current *bug* behavior? things are disabled by the generated mobileconfig files even if they should not be. ### What is the expected *correct* behavior? rules that are exempt should not produce entries in the generated mobileconfig files. ### Possible fixes modify `generate_guidance.py -y`, I suppose, to read the preferences before deciding if a rule's mobileconfig entry should be created.

michael closed this issue

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

michael commented

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

@golbiga commented on GitHub:

@noambernstein the exemptions are used when you configure something that is "out of compliance" but want to report it as such... it's not meant to configure a system out of compliance, only for reporting.

If you do not want os_camera_disable included in your guidance, you can create a stig baseline with generate_baseline.py -k stig remove the rule from baseline in build/baselines/stig.yaml, and run generate_guidance.py against it, then the profile will not be generated.

@golbiga commented on GitHub: @noambernstein the exemptions are used when you configure something that is "out of compliance" but want to report it as such... it's not meant to configure a system out of compliance, only for reporting. If you do not want os_camera_disable included in your guidance, you can create a stig baseline with `generate_baseline.py -k stig` remove the rule from baseline in `build/baselines/stig.yaml`, and run `generate_guidance.py` against it, then the profile will not be generated.

michael commented

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

@noambernstein commented on GitHub:

@noambernstein the exemptions are used when you configure something that is "out of compliance" but want to report it as such...

This is what I figured (although more documentation of this capability would be helpful). What I'd really like is for it to be tested, reported as passed or exempt (or maybe "failed but exempt"), but not remediated.

it's not meant to configure a system out of compliance, only for reporting.

In that case, why does the ..._compliance.sh script not apply the fix if exempt is set to true?

If you do not want os_camera_disable included in your guidance, you can create a stig baseline with generate_baseline.py -k stig remove the rule from baseline in build/baselines/stig.yaml, and run generate_guidance.py against it, then the profile will not be generated.

I assumed the workflow for remediation (whether or not some rules were set to exempt) was

run the remediation script
install the automatically generated mobileconfig files

However, in its current state it will behave inconsistently. The compliance script will not remediate exempt rules, but the generated mobileconfigs will enforce settings required by exempt rules.

Am I just misunderstanding the intended process for a system with exempt rules?

@noambernstein commented on GitHub: > @noambernstein the exemptions are used when you configure something that is "out of compliance" but want to report it as such... This is what I figured (although more documentation of this capability would be helpful). What I'd really like is for it to be tested, reported as passed or exempt (or maybe "failed but exempt"), but not remediated. > it's not meant to configure a system out of compliance, only for reporting. In that case, why does the `..._compliance.sh` script not apply the fix if exempt is set to true? > If you do not want os_camera_disable included in your guidance, you can create a stig baseline with `generate_baseline.py -k stig` remove the rule from baseline in `build/baselines/stig.yaml`, and run `generate_guidance.py` against it, then the profile will not be generated. I assumed the workflow for remediation (whether or not some rules were set to exempt) was 1. run the remediation script 2. install the automatically generated mobileconfig files However, in its current state it will behave inconsistently. The compliance script will _not_ remediate exempt rules, but the generated mobileconfigs _will_ enforce settings required by exempt rules. Am I just misunderstanding the intended process for a system with exempt rules?

michael commented

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

@noambernstein commented on GitHub:

Am I just misunderstanding the intended process for a system with exempt rules?

Is this in essence the problem? Are the exempt settings are meant to be set independently for each managed machine (by e.g. copying a modified version of the default ....audit.plist into the real location, namely /Library/Preferences/) , so it doesn't make sense to do anything with them when the mobile profiles are being generated?

If that's the intended workflow, perhaps this could be documented someplace (in general I didn't see any documentation for the exempt functionality), but if so I agree that no source code changes are needed. I could always write a script that removes mobileconfig payloads and modifies the default plist entries corresponding to things that need to be exempt.

@noambernstein commented on GitHub: > Am I just misunderstanding the intended process for a system with exempt rules? Is this in essence the problem? Are the exempt settings are meant to be set independently for each managed machine (by e.g. copying a modified version of the default `....audit.plist` into the real location, namely /Library/Preferences/) , so it doesn't make sense to do anything with them when the mobile profiles are being generated? If that's the intended workflow, perhaps this could be documented someplace (in general I didn't see any documentation for the exempt functionality), but if so I agree that no source code changes are needed. I could always write a script that removes mobileconfig payloads and modifies the default plist entries corresponding to things that need to be exempt.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: usnistgov/macos_security#291