September 20th, 2024

Can't change security policy or disable SIP with macOS 15 Sequoia

A user is unable to change the startup security policy or disable System Integrity Protection on their M1 Mac mini after upgrading to macOS 15 Sequoia, encountering errors previously unexperienced.

Read original articleLink Icon
Can't change security policy or disable SIP with macOS 15 Sequoia

A user has reported issues with changing the startup security policy and disabling System Integrity Protection (SIP) on their M1 Mac mini after upgrading to macOS 15 Sequoia. The user has multiple APFS boot volumes for different macOS versions, and while they were able to modify security settings in previous versions, they encountered errors when attempting to do so in Sequoia, Ventura, and Monterey. Specifically, when trying to change the security policy from Full Security to Reduced Security, an error (SDErrorDomain error 104) occurs. Additionally, attempts to disable SIP using the Terminal command "csrutil disable" also fail, indicating a problem with updating the security configuration. The user is unsure why these issues have arisen and is seeking solutions, noting that they have not encountered similar problems with earlier macOS versions.

- User cannot change security policy or disable SIP on macOS 15 Sequoia.

- Errors occur when attempting to modify security settings on multiple macOS versions.

- The user has previously been able to change these settings without issue.

- The problem may be related to Apple silicon hardware lockdown.

- The user is looking for solutions to resolve these errors.

Link Icon 11 comments
By @burke - 5 months
As someone working in developer tools for a company with thousands of people developing software on MacBooks, MAN do I resent SIP. I've recently started calling it "Systems Implementation Prevention".

It's incredible that it's 2024 and I can't cobble together anything vaguely container-like on macOS because:

* bind mounts don't exist (?!)

* clonefile() could maaaybe do the job but doesn't work cross-volume and a lot of the stuff outside of /Users is a different volume

* there's no filesystem namespace.

* chroot doesn't work either because /usr/lib/libsystem.B.dylib is required, but also pretend.

* And it sounds like chroot runs afoul of some SIP rule nowadays even if you can get past the above.

* A lot of this could be worked around with FUSE, but in order to turn that on, we'd have to turn off a lot of SIP.

The closest we can get without virtualization is sandbox-exec, which just allows allowing/denying file reads by path, with no path translation. And also is deprecated.

Nevermind that dtrace exists but you're not allowed to use it either.

Truly, the worst UNIX.

By @DidYaWipe - 5 months
After upgrading, I was prompted to allow the AltTab utility to control something "for one month," or to open Settings. So I opened Settings and everything was already enabled.

The question is who is clamoring for all this BS? The cynic would say that Apple is prepping us all for the eventual iOSification of Macs, where you can't do squat. Which will leave only Linux as a viable (AKA tolerable) computing platform.

By @mbirth - 5 months
I've got the same on a stock M1 MBP. At some point in the past I've disabled SIP - probably when I was playing around with FUSE.

Did all the Betas - never had any problem. However, after installing the RC/final version of Sequoia, I suddenly had a popup after bootup about an updated extension from "Apple Inc." and to please allow the updated version.

In Settings --> Privacy I was able to "Allow" the extension, however, this also requires a reboot. And after the reboot, the same popup appeared again.

I've put in a ticket - FB15087179.

Apple replied and said to first, toggle Activation Lock/Find My and wait 5+ minutes in-between. (Either off - wait 5mins - on, or on - wait 5mins - off.) Then boot into the bootloader and turn SIP on, then back off again.

However, when trying to turn SIP on, I get the same error as OP:

SDErrorDomain error 104.

I've found another user on Twitter with the same issue: https://x.com/davidhsherman13/status/1833264669793923151

After reporting my findings in the Apple Feedback thing, I've yet to get further instructions to try.

By @nativeit - 5 months
For everyone who reads the title and instantly assumes this is something Apple has done—this is a tech support request for an error this person has encountered.
By @eksu - 5 months
I did a .ipsw restore of my M1 Mac mini to 15 Sequoia RC last week and have since gone in and lowered the Security Policy to install ZFS kexts. I wonder if your issue is a bug relating to your multi MacOS boot setup? Have you posted this on MacRumors or elsewhere?
By @unsnap_biceps - 5 months
Seems like this has happened occasionally for years.

https://apple.stackexchange.com/questions/408016/local-polic...

There's an answer there on how they recovered. Worth a try.

By @habitue - 5 months
The ideal state for Apple and their target audience is to make your computer an appliance. They really don't want a wide set of configuration options, that makes it harder to service and harder to test.

People are kind of anchored to how Mac is / used to be etc, thinking of it as basically another unix. That's a historical blip in retrospect. Long term, their market really isn't developers & technical users, there are not enough of those to make concessions to.

In order to really help Aunt Sally keep her computer running and functional, they need to make sure that her nephew Billy can't make any complicated or potentially dangerous changes to the lower levels of the OS based on some internet forum post. If you need that kind of configurability, you really want a different OS. (Alternately, consider whether you really do need that configurability. Maybe you just think you do, and you'd much rather have a stable operating system that just works)

By @altairprime - 5 months
> How do I fix it?

Image the partitions to a backup location. Zero the entire drive. Clear nvram. Reinstall macOS 15. See if it’s resolved.