mirror of
https://github.com/usnistgov/macos_security.git
synced 2026-02-03 05:53:24 +00:00
sysprefs_wifi_disable.yaml ignored for STIG compliance #263
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @grismemj on GitHub.
Summary
The sysprefs_wifi_disable.yaml file is ignored in the generated STIG compliance script. No wifi check is done, even though the yaml file is listed as a rule in the baseline.
Steps to reproduce
Operating System version
macOS 11.6.2
What is the current bug behavior?
As far as a can tell the wifi rule is completely ignored in the generated compliance script. There is no reference to it that I can find, and no wifi check is performed.
What is the expected correct behavior?
The wifi check is the last one that should be done, as it is the last check before the supplemental section (at least that is the order in the current STIG baseline). The user should see it as the last check done by the script.
Relevant logs and/or screenshots
Output of checks
Here is the end of a compliance check I just ran after verifying the wifi rule is in the baseline and generating the compliance script:
Thu Jan 20 21:41:25 UTC 2022 sysprefs_wallet_applepay_prefpane_disable passed (Result: 1, Expected: {integer: 1})
Thu Jan 20 21:41:25 UTC 2022 sysprefs_wallet_applepay_prefpane_hide passed (Result: 1, Expected: {integer: 1})
Results written to /Library/Preferences/org.AFRLRQ-STIG.audit.plist
The last rule checked is sysprefs_wallet_applepay_prefpane_hide, which is the rule right before sysprefs_wifi_disable.
Possible fixes
I thought perhaps there was an issue with the sysprefs_wifi_disable.yaml file, but I cannot find any issues. I also tried changing the order of the rules listed in the baseline so this wasn't the last one, but that made no difference.
@brodjieski commented on GitHub:
Yes, it will make it work... but if you are running the script remotely over Wi-Fi, you will get disconnected when it gets disabled. It's marked as manual as a precaution.
@brodjieski commented on GitHub:
The rule for sysprefs_wifi_disable is identified as a "manual" control (as listed in the tags: field). This means that there is no automated check or fix generated for the compliance script. Controls like this are typically difficult to automate and would need an administrator or auditor to check them while at the system.
In this case, as its written, it's checking for the name Wi-Fi in the network services. There is no guarantee that the wireless interface will be called Wi-Fi, and thus the check could result in an incorrect finding. Also, with this control, automated remediation could lead to an inadvertent disconnect from the network if no other connection is present.
Perhaps this control could be rewritten to better facilitate automation, but for now it is a manual control.
@brodjieski commented on GitHub:
I agree. The way the current check is written, it only accounts for the network interface named "Wi-Fi". If the name of the interface is anything else, it will produce incorrect results. One could even duplicate the Wi-Fi interface, call it "Wireless", disable the "Wi-Fi" and pass the check... even though a wireless interface is active and connected.
Unless there is a better way to ensure that wifi is disabled, we should keep it manual to not give admins a false sense of security with the control.
@erefneb commented on GitHub:
If I have a disable wifi rule on my baseline, I would expect it to disable wifi.
--
Eric Benfer
@.***
@erefneb commented on GitHub:
This is incorrectly marked as manual. The rule does in fact have a working fix.
Simply removing the manual tag from the rule will make this work.
--
Eric Benfer
@.***
@brodjieski commented on GitHub:
Documentation on the manual tag has been added to the wiki.
@grismemj commented on GitHub:
I would argue the point of being able to customize the rules for your environment is to allow these types of differences to be handled. So I think it is reasonable to expect the rule to be used, and it is my job to make sure it is effective in my environment. As it is it was just dumb luck that I noticed it was not being used.
My other comment is I could not find any mention of the manual tag setting in the wiki, so had no idea that was an option…
Thanks.
Matt Grismer, PhD
AFRL/RQVC
937-713-7059
From: Dan Brodjieski @.>
Date: Friday, January 21, 2022 at 12:51 PM
To: usnistgov/macos_security @.>
Cc: GRISMER, MATTHEW J CIV USAF AFMC AFRL/RQVC @.>, Author @.>
Subject: [URL Verdict: Neutral][Non-DoD Source] Re: [usnistgov/macos_security] sysprefs_wifi_disable.yaml ignored for STIG compliance (Issue #114)
I agree. The way the current check is written, it only accounts for the network interface named "Wi-Fi". If the name of the interface is anything else, it will produce incorrect results. One could even duplicate the Wi-Fi interface, call it "Wireless", disable the "Wi-Fi" and pass the check... even though a wireless interface is active and connected.
Unless there is a better way to ensure that wifi is disabled, we should keep it manual to not give admins a false sense of security with the control.
—
Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/macos_security/issues/114#issuecomment-1018731313, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AW6OSZOCVHPPVEGPSA6PJ43UXGMH5ANCNFSM5MN5UHIQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>