4 ms·

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

pilif 4y ago
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
- therein 4y ago
  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.
  - dangrie158 4y ago
    Does not seem Privilege free as it seems to need sudo to run the client to connect to the service?
    - azinman2 4y ago
      My thoughts exactly. If you can sudo, isn’t it already game over?
      - eslaught 4y ago
        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?
      - j16sdiz 4y ago
        Think SELinux. sudo is bad, but it is not worse. Like SELinux, you are not supposed to be able to disable without reboot.
        fignews 4y ago
        Wouldn’t `setenforce 0` be essentially “disabling” SELinux without a reboot?
        OJFord 4y ago
        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).
  - pilif 4y ago
    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.

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

therein 4y ago
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.
- dangrie158 4y ago
  Does not seem Privilege free as it seems to need sudo to run the client to connect to the service?
  - azinman2 4y ago
    My thoughts exactly. If you can sudo, isn’t it already game over?
    - eslaught 4y ago
      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?
    - j16sdiz 4y ago
      Think SELinux. sudo is bad, but it is not worse. Like SELinux, you are not supposed to be able to disable without reboot.
      - fignews 4y ago
        Wouldn’t `setenforce 0` be essentially “disabling” SELinux without a reboot?
        OJFord 4y ago
        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).
- pilif 4y ago
  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.