System protection bypass does not work in MacOS 15.1

[shadowhand]

It seems that Apple no longer allows spctl --add ... at all; this is the documentation from man spctl in MacOS 15.1.0:

DEPRECATED OPTIONS
     As of MacOS 15.0, operations that modify the rule database or the global state of the assessment subsystem will no longer be supported.

     To add rules with configuration profiles, please see https://developer.apple.com/documentation/devicemanagement/systempolicyrule

     To modify the global state with configuration profiles, please see https://developer.apple.com/documentation/devicemanagement/systempolicycontrol

     --add    Add rule(s) to the system-wide assessment rule database.

And indeed, checking the assessment fails:

% spctl --assess /usr/local/bin/7777
/usr/local/bin/7777: rejected

This does not appear to impact users who already have SP bypassed for 7777, but it will likely impact new installations.

[shadowhand]

It seems the only way to allow 7777 to run is to allow applications from anywhere. This is a two step process:

1. In the command line, run spctl --global-disable, which will enable the hidden "Anywhere" option for allowed apps.
2. Open Settings.app > Privacy & Security > Security > Allow applications from: Anywhere.

Once this change is made spctl --assess /usr/local/bin/7777 exits cleanly.

[mnapoli]

Can you clarify what runs spctl?

I upgraded macOS too and things run fine:

[mnapoli]

@shadowhand I don't have that set to anywhere though 🤔

I'll try to upgrade to the latest version, just in case…

[mnapoli]

It is still working fine with the latest version:

[shadowhand]

@mnapoli I think if you have previously bypassed SP for 7777 then it remembers the setting. I suspect that new installations of MacOS and/or 7777 will run into this.

[mnapoli]

OK that could be it. Could you explain what the problem is exactly? I don't know what it means to run spctl --add and why one would run that command.

[shadowhand]

@mnapoli spctl used to allow specific unsigned apps to be executed. Now it seems that Apple has done away with that, only allowing Configuration Profiles to modify the SP database, so if users get an error saying that 7777 is unsigned and cannot be opened, they will need to allow applications from Anywhere, per my screenshots above. (See also this repo README. 😉 )

I have updated the title/description based on the exchange.

[shadowhand]

Ah-ha, while reading through some commentary from people smarter than me, I came across this comment:

Not unsigned apps, it flags “quarantined” apps that have been downloaded from arbitrary websites. Apps that don’t have the “mark of the web” quarantine flag will run just fine.

You can remove this flag from CLI too:

xattr -d com.apple.quarantine $FILE

As such, the recommended method of installing 7777 (via curl) should continue to work as expected for everyone. However, if someone tries to use download 7777 via a browser, it may not work.

[mnapoli]

See also this repo README. 😉

Doh! 🤦

Thanks for taking the time to add the details!

OK I'll clarify that explicitly in the README, thanks a lot. Between this app and the Bref Dashboard, I really hate distributing desktop or CLI apps 🥲 Working in the web is much more fun!

[victormacko]

I also had ths problem when trying to install 7777 via brew - the instructions on the README didn't work unfortunately;

% spctl --add /opt/homebrew/bin/7777
This operation is no longer supported. Please see the man page for more information.

I also tried the following, which also failed;
% run xattr -d com.apple.quarantine 7777
zsh: command not found: run

In the end I uninstalled via brew, and downloaded it via curl which didn't have any issues at all in terms of security/running.

That's on a new Macbook Pro, on the latest MacOS

[mnapoli]

% run xattr -d com.apple.quarantine 7777
zsh: command not found: run

The word "run" is not part of the command, i.e. this is what should be executed:

xattr -d com.apple.quarantine 7777

Good to know about homebrew vs curl though!

[victormacko]

Lol - good to know ... I probably needed more sleep at that point!
Thanks for the quick reply :)