The ‘app’ you can’t trash: how SIP is broken in High Sierra
eclecticlight.co
The ‘app’ you can’t trash: how SIP is broken in High Sierra
1–10 of 100 posts
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#2Possibly inadvisable, but you can disable SIP in High Sierra by using `csrutil` from the recovery OS (kind of moot, admittedly, as you'll need to be in recovery to trash the files that the author has mentioned, but you can at least make this setting permanent if you're willing to live with SIP disabled).
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#3> when some malware does manage to slip an evil kernel extension past a user and is rewarded with the protection of SIP, neither the user nor any anti-malware tool will be able to remove that extension, unless the user restarts from a different boot volume, or KernelExtensionManagement allows it.
But isn't that scenario "Game Over" anyway? At least installing kernel extensions is a process that is explicit and - importantly - not just another 'trained to ignore' permissions dialog. The alternative would be to prevent the user from ever installing kernel extensions unless they turn off security, and then you are back to square one. At least this way, authorised kernel extensions are taken under protection and not just left lying around for potential modification?
My main frustruation with SIP has been with environment variables starting with LD and DYLD being silently swallowed e.g. `DYLD_SOMETHING_SOMETHING=a env | grep DYLD` gives no output. So if you want to use these variables, or have existing scripts that do, you have to know what the command you are launching is - if it's an executable bash script, then the variables will never make it in.
SIP isn't perfect, and can be frustrating, but it certainly raises the bar for compromising a whole system.
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#4I guess the KEXT gets SIPed so it cant be hijacked by malware...
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#5The article doesn't mention that this is not new; nor is it 'the' app you can't trash: it joins Safari, Finder, and most other 'Apple apps'.
I find it quite surprising. Even when Windows defaulted to IE without choice, it could always be removed with 'Add or Remove Windows Features', as I recall.
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#6The article doesn't mention that this is not new; nor is it 'the' app you can't trash: it joins Safari, Finder, and most other 'Apple apps'. I find it quite surprising. Even when Windows defaulted to IE without choice, it could always be removed with 'Add or Remove Windows Features', as I recall.
Apple, protecting the user from himself?
As for removing IE. My understanding is that this would perhaps remove the UI and certain other assets, but the engine and various other bits would remain as the rest of the Windows UI relies on it.
Or at least that seemed to be the technical side of the claim that IE could not be removed during the antitrust trial.
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#7Applying 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.
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#8The article doesn't mention that this is not new; nor is it 'the' app you can't trash: it joins Safari, Finder, and most other 'Apple apps'. I find it quite surprising. Even when Windows defaulted to IE without choice, it could always be removed with 'Add or Remove Windows Features', as I recall.
Apple, protecting the user from himself? As for removing IE. My understanding is that this would perhaps remove the UI and certain other assets, but the engine and various other bits would remain as the rest of the Windows UI relies on it. Or at least that seemed to be the technical side of the claim that IE could not be removed during the antitrust trial.
Yeah, IE has at least two parts: "mshtml.dll" which is the rendering engine, and "iexplore.exe" which is the UI frame around it. On my system mshtml is 23MB and iexplore is 800kB, so I think we can infer where most of the logic is.
Microsoft made the integrated help, "active desktop", and I think a few parts of Explorer depend on mshtml.dll.
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#9Earlier quoted context omitted.
Apple, protecting the user from himself? As for removing IE. My understanding is that this would perhaps remove the UI and certain other assets, but the engine and various other bits would remain as the rest of the Windows UI relies on it. Or at least that seemed to be the technical side of the claim that IE could not be removed during the antitrust trial.
Yeah, IE has at least two parts: "mshtml.dll" which is the rendering engine, and "iexplore.exe" which is the UI frame around it. On my system mshtml is 23MB and iexplore is 800kB, so I think we can infer where most of the logic is. Microsoft made the integrated help, "active desktop", and I think a few parts of Explorer depend on mshtml.dll.
As well as, what was the first wave of "Electron" apps, thankfully largely ignored.
Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra
#10The article doesn't mention that this is not new; nor is it 'the' app you can't trash: it joins Safari, Finder, and most other 'Apple apps'. I find it quite surprising. Even when Windows defaulted to IE without choice, it could always be removed with 'Add or Remove Windows Features', as I recall.
One can't remove 'Apple apps' because Apple follows the BSD logic: https://www.over-yonder.net/~fullermd/rants/bsd4linux/01