Can you disable Gatekeeper and XProtect?

Can you disable Gatekeeper and XProtect? – The Eclectic Light Company

Whenever you try to run an app, Gatekeeper checks whether that app complies with system security policy, and that may involve its contents being scanned by XProtect against a set of rules. Checks made depend on the source of the app and its signing and notarisation, whether it has been run before, whether it is quarantined, and which version of macOS is running.

Significant changes were made in both macOS Sequoia and Tahoe, including controls the user has over both Gatekeeper and XProtect. This article explains how those controls have changed, in particular what you can now do to disable Gatekeeper and XProtect checks.

For an app, plug-in or an installer package downloaded from outside the App Store and opened on a Mac, Gatekeeper may verify the software:

is from an identified developer, in signature checks;

is notarised by Apple to be free of known malicious content, in notarisation ticket checks;

hasn’t been altered, in CDHash verification;

doesn’t contain known malicious content the first time it’s opened, regardless of how it arrived on the Mac, in a first run XProtect scan.

In Tahoe, on-demand XProtect check against its detection rules may be omitted if the first three of those verify correctly.

There are also two other flavours of XProtect: periodic scans by XProtect Remediator to detect and mitigate any malware, and a behavioural XProtect that gathers security intelligence for Apple.

Controls

The only control exposed in the GUI is the popup menu towards the foot of Privacy & Security settings, to allow applications from the App Store alone, or App Store & Known Developers.

Prior to Sequoia, the command

sudo spctl --master-disable

effectively disabled Gatekeeper checks including on-demand XProtect checks, although in practice those were still performed, but their results weren’t used to determine whether the app should be launched.

In Sequoia and later, man spctl states that "operations that modify the rule database or the global state of the assessment subsystem will no longer be supported". However, if you use the same master-disable option, that can widen the scope of apps permitted to be run to include any signed app, in Privacy & Security settings.

There is also the option to install a profile detailed by Apple, in which EnableAssessment is set to false, which "disables Gatekeeper". In practice, this sets the scope of permitted apps to Anywhere , the same as using the master-disable option and changing that menu manually.

Effects

Prior to Sequoia, the command

spctl --status

returns a statement of whether the Gatekeeper "assessment subsystem" is enabled or disabled, and this remains available in both Sequoia and Tahoe.

Sequoia adds a new command xprotect to manage XProtect, with the command

xprotect status

to return individual XProtect status for both on-demand app checks and XProtect Remediator scans, for example

XProtect launch scans: enabled

XProtect background scans: enabled

Effects observed in a Tahoe 26.6 virtual machine running on a 26.6 host are:

Following spctl --master-disable and allowing any signed app, resulted in spctl reporting that assessments were disabled , but xprotect reported that both flavours of XProtect were enabled .

Following installation of a profile setting EnableAssessment to false, the effects were identical.

Those results are not consistent with the man page descriptions given.

Conclusions

In Tahoe 26.6, the command spctl --master-disable followed by allowing apps from Anywhere in Privacy & Security settings doesn’t disable Gatekeeper or on-demand XProtect, but merely enables you to run signed apps that haven’t been notarised. Installing a profile that sets EnableAssessment to false appears to have identical effects, but doesn’t require the user to change that menu in Privacy & Security settings.

There doesn’t appear to be any direct way of disabling Gatekeeper or on-demand XProtect, nor does there appear to any way of disabling XProtect Remediator scans. It thus appears the xprotect status command is superfluous.

SilentKnight

Both current versions of SilentKnight, 2.14 and 3.02, rely on spctl --status to determine whether Gatekeeper and XProtect are enabled. From these results, that appears to be more sensitive and relevant than relying on xprotect status. In the absence of any information to the contrary, I propose to continue that.

Can you disable Gatekeeper and XProtect?

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

NHS apologises and admits Palantir have access to identifiable patient data

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills