Can't you disable SIP as root? What can't you do as root? You could replace the kernel. I guess I am use to the Linux world where I build kernels and install as root.

You cannot do these with all security enabled, no. There are lots of other things that are prevented by SIP and/or Secure Boot. One of the principles is that being root should not mean that the kernel can be readily attacked without further bugs.

That also means no /dev/kmem etc., and on top of that POSIX file permissions are by far not the only thing that is protecting access to the file system.

If you want to go down the rabbit hole: https://help.apple.com/pdf/security/en_US/apple-platform-sec...

That is a deep hole. I see there is a chain of certificates of trust for fine grain control to all the system parts beginning with the boot sequence. A lot more complicated than Unix systems of yore.

Apple goes through a lot of effort to keep control of the system out of their customer's hands.

It's a delicate balance because Apple has to support a lot of people and at this point there are literally decades of experience showing that many people, including administrators and developers, will make mistakes or bad decisions due to social engineering or simply greed (how many people installed malware because they thought it was cheaper than paying $20 for a software license?).

SIP is a good compromise: it prevents malware from gaining completely control of the system but someone with physical access and administrator privileges can disable it for the few situations where that's desirable. That's not a high bar when you need it but it probably has a 100000:1 ratio of time preventing someone's day from getting worse to actually preventing legitimate work.

Linux and the BSDs really should have a more restricted default desktop capability model compared to macOS by now. It's a shame that Qubes is the main response we have, not because it's bad, but because it's necessary.

You shouldn’t run a web browser on any system with less security than this.

(It doesn’t have nearly enough security yet, but it’s much more advanced than Linux. And strangely also OpenBSD, who like defending against imaginary attackers doing imaginary attacks instead of their real weak points.)

SIP really helps protect people from themselves, and it’s easily disabled for those who need it (but it’s definitely a red flag).

A couple years ago many edit houses in LA suddenly had boot issues because a Chrome update was over writing system files when the updater was run with elevated privileges.

The issue was that these studios used Avid which required disabling sip at the time.

Other houses that didn’t disable sip were unaffected because it protects against exactly this kind of scenario.

I don't want to be protected from myself. As the admin I should have full access to the stuff I buy.

Disabling it is ok but the problem with that is that you lose all security. There should be a way to add our own signing keys to persist changes to the SSV (Signed System Volume) and SIP protected folders. It shouldn't be trust only Apple or nothing.

You do have full access to what you buy. While it would be nice to both have full access AND the security, that’s still not denying you full access.

This is not for you, rather for the kind of people that get Ask Jeeves installed when clicking on popups while browsing the Web.

They shouldn't have the same rights? Just because someone is less technologically aware today, you think it's OK to start stripping away their rights? That's like saying poor people shouldn't be allowed to own a house because they won't be able to afford the maintenance.

Many insurances don't cover house repairs if not done by companies specialised on the repair domain....

The more accurate version of your analogy is that they can choose to do their maintenance, they just won’t be covered by insurance (their own or that of a tradesman) if something goes wrong.

That is actually how it is in reality, and maps very well to as analogies go to GM the two levels of SIP.

The new cryptex mechanism could be used to allow persistent modifications to the SSV (that's how it's done on the iOS Security Research Devices), but no idea if Apple will actually implement that.

securelevel [1] is a similar feature from/for FreeBSD. As an example, it could be used to build e.g. a true append-only syslog server which even root would not be able to manipulate the data without a reboot or, in combination with other techniques like a capiscum-sandboxed tcpdump implementation, highly secure network appliance.. plenty of use-cases.

[1] https://www.freebsd.org/cgi/man.cgi?query=securelevel&apropo...

With SIP you can only reboot the machine into recovery mode, but the user would then have to go into the recovery mode terminal and run `csrutil disable` to disable SIP.

You can't disable SIP on a live system and you can't automate actions in recovery mode.

Then it's not root...

OK ... so w MacOS there is a user w more power than root? There has to be some entity that can ultimately install a new kernel and subsystem.

It’s more that there is far more protecting the system (and also e.g. data from different apps against each other, or things like access to your screen content), than the current user. Some of this is because we’re in a world where Macs and iPhones are far more likely to be single user machines than the UNIX machines of lore. See the PDF in my other answer.

There could be code in the system that directs IO and only allows write requests to parts of the OS if they include a signature from Apple.

I'm not sure if "a user with more power than root" would be the right way to describe that. The code would have a permission that "root" doesn't, but I wouldn't call the code "a user". It's a Unix idea that "a specific set of permissions" and "a user" are synonyms. Systems can exist where some permissions aren't represented as users.

No, there is no more powerful user, it’s just that the root user no longer has arbitrary control - it means that if an attacker compromises a root owned process the attacker can’t turn around and control the kernel.

The kernel has a number of things it can do: if you try to do a special thing it could force authentication itself - eg a “root”/admin user can still do the action, but a process with “root privileges” cannot, it can require the process attempting the action have correct entitlements, it can simply reject the operation entirely, etc. it can do all of the above: I recall there being some operations that can only be performed by specific apps, with specific entitlements, as special users, with immediate authentication (startup items and the like)

root is essentially a POSIX concept, and from a POSIX perspective this is still root, it’s just that the POSIX security model is by far not the only thing in play here.

When Apple introduced SIP, they marketed it as “Rootless”.

SIP is another system that exists besides POSIX and the root user. With SIP enabled, let me demonstrate:

    chris@chriscomp /usr/bin # sudo su root
    root@chriscomp /usr/bin # touch testo
    touch: testo: Operation not permitted