What are the potential consequences of partially-disabling SIP for yabai

Solution 1:

On a traditional UNIX system—including many major platforms still in use today, such as Debian—any user or process with "root" privileges is considered to have absolute control over a machine. There is basically nothing the OS will not allow a root user to do, whether it's rewriting system files, adding code to other processes, adding code to the kernel, you name it. If you've ever been told not to run programs as root unless absolutely necessary, this is why.

macOS, being itself a UNIX operating system, also behaved this way for many years. As recently as OS X 10.10 Yosemite, once you gave an app your root/administrator password, it was free to do anything it wanted, and macOS would not stand in its way.

All of this changed with the release of macOS El Capitan in 2015. For the first time on the Mac, Apple decided to define a set of actions which they believed no user or program—even one with root privileges—should ever be able to perform! Among these restrictions included installing kernel extensions from unidentified developers (the "kext" protection), injecting code into projected processes, such as apps made by Apple (the "debug" protection), and writing to certain protected system directories (the "fs" protection).

Apple called this new set of restrictions "System Integrity Protection", or SIP for short, and they also made it possible for advanced users to disable, by running a Terminal command from within recovery mode. Disabling SIP reverts your computer to the traditional UNIX behavior of letting root do whatever the heck it wants. Apple also made it possible to individually disable certain restrictions—for instance, running csrutil disable && csrutil enable --without debug will allow injecting code into protected processes, but still leave SIP's other protections in tact.

Suffice to say, disabling SIP grants you a great deal of power over the way your Mac operates. I've recently been learning how to swizzle methods in Objective C; when SIP is off, you can use this to replace code in existing apps, which is really quite fun. When an app does something I don't like—whether it's Zoom making all its windows rudely float on top, or the Dictionary app not respecting my Mac's proxy settings—I can go ahead and change it.

The danger, however, is that if I can inject my own code into any other app, other software potentially could too! You don't need to be particularly creative to imagine the mischief an evil app could cause if it could modify every other app on your machine. For example, an app could inject its own advertisements into Safari, or tell Microsoft Word to send all of its documents to a server in North Korea.

On the other hand, evil apps with root permissions can wreck plenty of havoc without disabling SIP! They won't have any trouble installing bitcoin miners, reading all of your browsing history, and holding for ransom a great many (although not all!) of the files on your hard drive. In fact, a lot of these attacks don't even require root to work. Installing apps is just inherently somewhat dangerous—not unlike inviting someone into your house—unless they come from the Mac App Store, where they're guaranteed to be sandboxed.

I'm only aware of one real-world issue caused by disabling SIP, although it was pretty bad! A couple of years ago, there was a bug in Google Chrome's updater (which sometimes requests root permissions... ugh...) which caused it to overwrite a number of core system files, rendering Macs unbootable. On Macs with SIP enabled, Chrome was prevented from deleting these files, and Chrome carried on its merry way. Presumably, Google never tested Chrome on a Mac without SIP, and so did not discover the problem prior to release. In Google's defense, they did fix the issue quickly, and I'd imagine Chrome now gets tested on Macs without SIP. (But suffice to say, uh, this is why I don't like Google Chrome.)

You should also be aware that on Apple Silicon Macs, Apple does not allow iOS apps to run while SIP is turned off, presumably because developers expect iOS software to only be usable in a locked-down environment. (Those developers are also wrong, because Jailbreaks exist.)

Given all of the above, my general recommendation is as follows:

• If you don't have a reason to turn off SIP, leave it on. It won't do any harm.

• If you have a reason to turn off SIP, go ahead, and don't let it keep you up at night. You need to be a bit more careful about which apps you run as root. You need to do that anyway.

Other people can and will fall elsewhere on that spectrum. Hopefully you now have enough information to make your own decision!

^{Okay, so, "anything you want" is perhaps an oversimplification. For starters, modern versions of macOS have a number of other protection systems in addition to SIP, such as TCC and AMFI. The thing is, once SIP is off, there is in theory nothing to stop a process from disabling those as well—who is going to stand in the way, when you can literally rewrite kernel memory? I suppose there are probably protected CPU registers and such.}