3 ms·

Applying SIP on the KEXT makes sense, since any KEXT that’s writable by the user is a huge security risk. The only thing that appears to be broken here is the B

by mikl 9y ago

Applying SIP on the KEXT makes sense, since any KEXT that’s writable by the user is a huge security risk. The only thing that appears to be broken here is the BlueStack uninstaller that is apparently not SIP-aware. There’s probably some way to do the SIP procedure you did to install the app in reverse.

0x0 9y ago
The point of the article is that there's no documented way to do the SIP procedure in reverse.
- Someone 9y ago
  https://developer.apple.com/library/content/technotes/tn2459/_index.html#//apple_ref/doc/uid/DTS40017658-CH1-TNTAG4 https://developer.apple.com/library/content/technotes/tn2459... gives some more info on the process for approving installation, but doesn’t mention extension unloading or removal. Neither does https://support.apple.com/en-us/HT208019 https://support.apple.com/en-us/HT208019, but I would guess/hope that, if you are managing Macs running High Sierra through MDM, you _can_ do that. Also, if you are using MDM, be prepared for a change (from that second document): “If your Mac is running macOS High Sierra and is enrolled in MDM, User Approved Kernel Extension Loading is currently disabled. All kernel extensions will load without requiring user consent. Use the Kernel Extension Policy payload to specify which kernel extensions should load without user consent, and to optionally prevent users from approving additional kernel extensions. In spring 2018, an update to macOS will cause User Approved Kernel Extension Loading to be enabled even on devices enrolled in MDM. You will still be able to use the Kernel Extension Policy to manage User Approved Kernel Extension Loading after this change.”
danieldk 9y ago
since any KEXT that’s writable by the user is a huge security risk Not I disagree, but this is somewhat mitigated because macOS only loads signed kexts by default. I think removal is the larger threat. E.g. if I installed Little Snitch, I don't want other software to be able to remove its kext (though I guess the remainder of Little Snitch is not protected by Little Snitch anyway).

by mikl 9y ago

0x0 9y ago

The point of the article is that there's no documented way to do the SIP procedure in reverse.

Someone 9y ago
https://developer.apple.com/library/content/technotes/tn2459/_index.html#//apple_ref/doc/uid/DTS40017658-CH1-TNTAG4 https://developer.apple.com/library/content/technotes/tn2459... gives some more info on the process for approving installation, but doesn’t mention extension unloading or removal. Neither does https://support.apple.com/en-us/HT208019 https://support.apple.com/en-us/HT208019, but I would guess/hope that, if you are managing Macs running High Sierra through MDM, you _can_ do that. Also, if you are using MDM, be prepared for a change (from that second document): “If your Mac is running macOS High Sierra and is enrolled in MDM, User Approved Kernel Extension Loading is currently disabled. All kernel extensions will load without requiring user consent. Use the Kernel Extension Policy payload to specify which kernel extensions should load without user consent, and to optionally prevent users from approving additional kernel extensions. In spring 2018, an update to macOS will cause User Approved Kernel Extension Loading to be enabled even on devices enrolled in MDM. You will still be able to use the Kernel Extension Policy to manage User Approved Kernel Extension Loading after this change.”

danieldk 9y ago

since any KEXT that’s writable by the user is a huge security risk Not I disagree, but this is somewhat mitigated because macOS only loads signed kexts by default. I think removal is the larger threat. E.g. if I installed Little Snitch, I don't want other software to be able to remove its kext (though I guess the remainder of Little Snitch is not protected by Little Snitch anyway).