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.