os_anti_virus_installed errors: Tahoe #11

Open
opened 2026-01-19 18:28:55 +00:00 by michael · 4 comments
Owner

Originally created by @nameitsa on GitHub.

Summary

XProtect launch scans: disabled after running remediation steps,
checked https://github.com/usnistgov/macos_security/issues/294 and ran the steps again after stopping xprotect via bootout and kill -9 pid of xprotect.

Steps to reproduce

Initial check showed:
XProtect launch scans: disabled
XProtect background scans: enabled

ran following commands
/bin/launchctl bootout system/com.apple.XprotectFramework.PluginService
/bin/launchctl bootout system/com.apple.XProtect.daemon.scan.startup
/bin/launchctl bootout system/com.apple.XProtect.daemon.scan

Then ran the remediation code:
/bin/launchctl load -w /Library/Apple/System/Library/LaunchDaemons/com.apple.XProtect.daemon.scan.plist
/bin/launchctl load -w /Library/Apple/System/Library/LaunchDaemons/com.apple.XProtectFramework.PluginService.plist

Final check before and after reboot showed:
XProtect launch scans: disabled
XProtect background scans: enabled

Also repeated above steps including:
/bin/launchctl load -w /Library/Apple/System/Library/LaunchDaemons/com.apple.XProtect.daemon.scan.startup.plist

Operating System version

Tahoe 26.1

Intel or Apple Silicon

Apple Silicon M5

What is the current bug behavior?

XProtect launch scans: disabled
XProtect background scans: enabled

What is the expected correct behavior?

XProtect launch scans: enabled
XProtect background scans: enabled

Relevant logs and/or screenshots

No Errors shown in terminal

Output of checks

XProtect launch scans: disabled
XProtect background scans: enabled

Originally created by @nameitsa on GitHub. <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label and verify the issue you're about to submit isn't a duplicate. ---> ### Summary XProtect launch scans: disabled after running remediation steps, checked https://github.com/usnistgov/macos_security/issues/294 and ran the steps again after stopping xprotect via bootout and kill -9 pid of xprotect. ### Steps to reproduce Initial check showed: XProtect launch scans: disabled XProtect background scans: enabled ran following commands /bin/launchctl bootout system/com.apple.XprotectFramework.PluginService /bin/launchctl bootout system/com.apple.XProtect.daemon.scan.startup /bin/launchctl bootout system/com.apple.XProtect.daemon.scan Then ran the remediation code: /bin/launchctl load -w /Library/Apple/System/Library/LaunchDaemons/com.apple.XProtect.daemon.scan.plist /bin/launchctl load -w /Library/Apple/System/Library/LaunchDaemons/com.apple.XProtectFramework.PluginService.plist Final check before and after reboot showed: XProtect launch scans: disabled XProtect background scans: enabled Also repeated above steps including: /bin/launchctl load -w /Library/Apple/System/Library/LaunchDaemons/com.apple.XProtect.daemon.scan.startup.plist ### Operating System version Tahoe 26.1 ### Intel or Apple Silicon Apple Silicon M5 ### What is the current *bug* behavior? XProtect launch scans: disabled XProtect background scans: enabled ### What is the expected *correct* behavior? XProtect launch scans: enabled XProtect background scans: enabled ### Relevant logs and/or screenshots No Errors shown in terminal ### Output of checks XProtect launch scans: disabled XProtect background scans: enabled
Author
Owner

@robertgendler commented on GitHub:

Did you disable SIP in order to be able to disable XProtect?

I have a root shell and am not able to do a bootout or a kill on the XProtect service.

/bin/launchctl bootout system/com.apple.XprotectFramework.PluginService
Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged
/bin/launchctl bootout system/com.apple.XProtect.daemon.scan.startup
Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged
/bin/launchctl bootout system/com.apple.XProtect.daemon.scan
Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged


ps aux | grep -i xprotect
rmg2              2161   0.0  0.0 435355968   9184   ??  S     3:50PM   0:04.99 /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/XPCServices/XProtectPluginService.xpc/Contents/MacOS/XProtectPluginService

kill -9 2161
kill: 2161: Operation not permitted
@robertgendler commented on GitHub: Did you disable SIP in order to be able to disable XProtect? I have a root shell and am not able to do a bootout or a kill on the XProtect service. ``` /bin/launchctl bootout system/com.apple.XprotectFramework.PluginService Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged /bin/launchctl bootout system/com.apple.XProtect.daemon.scan.startup Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged /bin/launchctl bootout system/com.apple.XProtect.daemon.scan Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged ps aux | grep -i xprotect rmg2 2161 0.0 0.0 435355968 9184 ?? S 3:50PM 0:04.99 /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/XPCServices/XProtectPluginService.xpc/Contents/MacOS/XProtectPluginService kill -9 2161 kill: 2161: Operation not permitted ```
Author
Owner

@brodjieski commented on GitHub:

This rule is derived from the CIS benchmarks and uses the methodology as outlined by CIS. It appears that the commands do not work while SIP is disabled. We will have to engage with CIS to identify the correct course of action. If you are able, please open a ticket with them to add visibility to the issue.

Until then, I recommended not disabling SIP on your systems. Enabling SIP will restore the correct behavior and should report as compliant with the rule.

@brodjieski commented on GitHub: This rule is derived from the CIS benchmarks and uses the methodology as outlined by CIS. It appears that the commands do not work while SIP is disabled. We will have to engage with CIS to identify the correct course of action. If you are able, please open a ticket with them to add visibility to the issue. Until then, I recommended not disabling SIP on your systems. Enabling SIP will restore the correct behavior and should report as compliant with the rule.
Author
Owner

@nameitsa commented on GitHub:

Hi @robertgendler, Yes I did disable SIP before doing the commands, the odd thing is on my 2019 intel macbook pro, this is showing up as enabled.

@nameitsa commented on GitHub: Hi @robertgendler, Yes I did disable SIP before doing the commands, the odd thing is on my 2019 intel macbook pro, this is showing up as enabled.
Author
Owner

@nameitsa commented on GitHub:

I tested to see if there were any changes with a reboot after sip was enabled before making this post, should have clarified that, though I will try to create a ticket with CIS.

@nameitsa commented on GitHub: I tested to see if there were any changes with a reboot after sip was enabled before making this post, should have clarified that, though I will try to create a ticket with CIS.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#11