The first paragraph in the “Root Cause” section explains: that binary has access to a service that’s allowed to bypass SIP restrictions.

It’s required to have those capabilities because this is what’s used by Apple to install their OS updates

So it is privilege-free `sudo move` as a service. Nice.

Do all that entitlement dance all across the OS, sign the bootloader and ensure execution integrity up to the kernel and then do this.

That's the root of the issue. The service is meant to be used by a system component but didn't or couldn't check whether that was actually true and the failure to check properly was overlooked in the security review.

There's some history of similar problems where functionality offered by a privileged library was exposed to non-privileged users.

This isn't an apple-only issue though - before this system-level of authorization, there was suid binaries which could be abused because they didn't perform proper checking of user input.

Does not seem Privilege free as it seems to need sudo to run the client to connect to the service?

My thoughts exactly. If you can sudo, isn’t it already game over?

But that was the entire point of SIP, wasn't it? To mitigate the impact of a compromised root account. If it doesn't work, then what's the point of going to all this effort in the first place?

Think SELinux.

sudo is bad, but it is not worse.

Like SELinux, you are not supposed to be able to disable without reboot.

Wouldn’t `setenforce 0` be essentially “disabling” SELinux without a reboot?

Puts it in 'permissive' mode, i.e. 'audit but don't deny'. Disabling (i.e. no auditing either, no record) requires a reboot I believe (a change to kernel param).