I think the issue is that SIP is supposed to be like “beyond root”.

Because many installs (heck, going to a page with invalid cert in Safari!) ask for an admins password to install, which gives escalated privileges up to root.

So they added a level that requires higher than root access.

With this vulnerability, someone typing their password could allow beyond root privileges.

That is my simplified parsing of things.

Note - I didn’t read the article. I’m not in security. But I did live with Dan Kaminsky for close to 5 years. RIP :/

The problem with SIP though is that this higher than root access is not accessible to the user, only to Apple. You can turn it off completely but there is no way to make your own changes. It's trust Apple 100% or nothing.

In contrast, alternative OSes implementations of mandatory access control do have a role that can be accessed by the user.

Probably the dumbest thing I've said, but, just skim read as I'm no expert and these detailed reports go over my head.

Why is it such a bad vulnerability if it requires a sudo command?

On macOS, certain system components are intended to be protected even if you have administrator/root access to the machine. The intent is that a rogue daemon running as root shouldn't be able to e.g. delete OS files or inject itself into the permissions database ("give me ALL THE PERMISSIONS") without your consent. This protection system is called SIP, or "System Integrity Protection". The bug in the blog post bypasses this protection and demos it by overwriting one of these protected files that is not usually modifiable by root.

It’s similar to SYSTEM account access in Windows

> a rogue daemon running as root

Why would daemons be running as root in 2022? What does that anymore, especially on macOS?

If only we had something like that on Linux systems. I wonder how that work on the kernel side.

SELinux?

Can be disabled and the rules changed by root.

The entire value proposition of SIP is that it can supposedly protect you from certain attacks even if the attacker has root.

Can I use this to actually disable/delete Apple Music so it doesn't open automatically when I press a button on my headphones etc

You can boot with SIP disabled the 'legitimate' way and do that.

This is why I read HN. Thanks so much! That has been driving me crazy forever now.

You can easily disable SIP yourself, by rebooting into Recovery mode.

However, Apple Music may be part of the system. The system cannot be modified, it’s not permitted. You can download things that prevent this though by intercepting the key press.

What is this "shove" operation and how is it different than moving a file the normal way?

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).