Disable SIP

What sucks is that you can't disable SIP without _also_ disabling disk encryption ("FileVault"), because Apple changed from full disk encryption to only encrypting user data, and relying on SIP and crypto hashes to protect the system partition. Therefore, you can't "safely" disable SIP, as you'd be able to boot into recovery mode and perform an evil maid attack.

This is really irritating, both that:

- I can't "accept the risk" and force disk encryption anyway. This may be technically possible if you bludgeon the OS enough, but it's definitely not something the built in CLI tooling supports.

- I can't use the old full disk encryption mode. Presumably, this code does or did still exist somewhere, but isn't supported because it's not used in any supported configuration.

So you're left with the option of having no disk encryption on your laptop, or having SIP.

EDIT: I'm thinking of SSV, not SIP per se. But when it comes to disabling the built-in launchd services like Spotlight, you have to disable SSV to do so, and that requires disabling FileVault.

I know the writing has been on the wall for a while but as a former fanboy, I just didn't see it. When SIP was released, it was my first "ah ha" wake-up call that Apple is no longer building software for me. Ten years later, it's still getting worse. This idea that the owner of the computer is not the ultimate authority over what is running on that computer is slowly seeping its way into macOS and with every release it seems to get worse. That and the ecosystem of apps that abandon you if you're running N minus 3 or earlier macOS.

I'm finally starting to de-Applify my home computing and slowly removing my and my family's dependence on the Apple ecosystem. Replacing an old Mac Mini here, replacing an old MacBook there. It's been a long time coming, but I'm out.

I'm not even mentioning Tahoe which is a disaster but doesn't bother me because I don't have a single machine that can run anything past Ventura anyway.

So on to Linux and RasberryPis?

You appear to be confusing System Integrity Protection with the Signed System Volume. FileVault works fine with SIP disabled. But you can't disable SSV without disabling FileVault.

Yes, this is true! I was thinking about "disabling SIP" in the sense of being able to modify the system to e.g. disable the Spotlight launchd service. My mistake.

But still -- you can't "unlock" the system (in this sense) without disabling SSV, which requires disabling FileVault.

(Unless I'm wrong about that too, and there is a way to disable Spotlight without disabling SSV)

You don't need to modify the system volume. Once SIP is disabled, you can then use standard launchctl commands to disable system launchd jobs.

As far as I know, recovery mode doesn't let you do anything without either successfully authenticating or wiping the entire disk. An evil maid could theoretically compromise recovery mode at the login screen (with a USB device or something) but if they were able to do that, they could probably disable SSV themselves even if you hadn't done so. Therefore, disabling SSV shouldn't create additional risk involving recovery mode.

If the evil maid could boot macOS from an external disk, on the other hand, that would definitely be a problem. I think you need to authenticate in order to boot from an external disk for the first time (cf. [1]) but I'm not sure how this works.

[1] https://eclecticlight.co/2023/03/15/ownership-of-apple-silic...

Edit: Actually I guess an attacker trying to disable SSV themselves (via exploit of recovery mode) wouldn’t have the machine owner key needed to sign the new LocalPolicy. But could they reset it and still keep the data somehow? I don’t know.

If that were possible, malware would shut down a mountain of services very quickly.

Right off the bat, XProtect, MRT, Gatekeeper, amfid, system updates, telemetry, MDM...

sudo or equivalent has been around for quite a long time now.

You think regular people can be trusted with sudo? (Absolutely not.)

Yes. It's their computer. We don't need to hand-hold grown adults, that's how we develop computer-illiteracy.

Nobody knows how to do anything because nobody lets them.

This is an interesting question. I started using computers in the late 90s when there were no guardrails and everything was permitted so I know what I am doing- or at the very least only blame myself if I fuck it up.

But your average 20 year old who only knows an iPhone would be out of his/her depth quickly.

Computers are no longer made for me.

To clarify, re-authentication prevents malware from doing what you said it would do. Regular people wouldn't need to use it.

Also all apple telemetry.

----

semi-unrelated tip - on ios, most telemetry options can be disabled under

Settings -> privacy & security -> Analytics & Improvements

However, there is a whole separate telemetry setting:

Settings -> search -> help apple improve search

note that this doesn't show up if you search for it in settings. (try searching for "help apple" or "improve")

and of course the whole "learn from this app" and other siri settings that are all individual settings.

You’re very entitled to your opinion, but it should be fairly obvious why this isn’t reasonable from their perspective. Put another way, let’s just say I think apple is glad you’re not making decisions about how their operating system should work. It’s an OS built for users, not those who wish to have iron control over everything. Allowing that would be disastrous for most users just to appease the very small percentage who’d want that.

You had full root for more than a decade on any macOS machine.

And then you didn't. What's the purpose of saying this?

All consumer-operating systems also used to be single user with administrative access by default. Shall we return to that, too?

The point of saying this is to let you realize that the last ten years weren't a disaster.

We also used to use wep encryption on wifi networks

How is allowing the user the power to disable software on the device they own "disastrous" for anyone

It opens the door to tech-illiterate users being tricked into disabling security features, doesn’t it? Not saying I agree with it but I imagine that’s the motivation.

That's like saying houses shouldn't have doors in case the unwary are tricked into letting thieves into their homes.

No, it’s not.

In general or in this case?

I'm also curious about this specific case.

In general: https://www.youtube.com/watch?v=o_XaJdDqQA0

Same reason we don’t let people set their banking password to “password”.

What is the attack chain enabled by letting me disable the com.apple.mediaanalysisd job?

Show me where I said there was one? You’re raising this in bad faith.

You're the one concern trolling over security.

Oh, so first you put words in my mouth, and now the moment you get called out on it you accuse _me_ of trolling? Get a grip son.

It's related to the entire security balance which is bad (imho). Until that separation, in the PowerPC/Intel supported days you had the option to remove one from the fat binary (Universal Binary 1).

This carried and I can still do that. But not on System apps. So now any system app is twice without ability to easily 'diet' it:

file /System/Applications/TextEdit.app/Contents/MacOS/TextEdit /System/Applications/TextEdit.app/Contents/MacOS/TextEdit: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e] /System/Applications/TextEdit.app/Contents/MacOS/TextEdit (for architecture x86_64): Mach-O 64-bit executable x86_64 /System/Applications/TextEdit.app/Contents/MacOS/TextEdit (for architecture arm64e): Mach-O 64-bit executable arm64e

It won't be marketing wonder when new macOS dropping Intel will be it's 25% smaller (I guess they'll take the extra size for on-device models are other feature you won't be able to remove :) )

I've always thought of iOS and iPadOS as appliance OSes, but macOS as the thing I retained control over. It's changes like this that are nudging me back to Linux as a daily driver for my desktop, not just for headless work.