Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ‘app’ you can’t trash: how SIP is broken in High Sierra

eclecticlight.co

Post reply on HN
Print view View original

61–70 of 100 posts

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#61

Post by microtonal »

mikl wrote: post #7

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.

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

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#62

Post by twir »

Add "System Integrity Protection" to the list of reasons why my next laptop won't be a Mac. Although based on a free operating system, Mac OS is gradually taking away users' control over their own devices. Either the user controls the software, or the software controls the user.

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#63

Post by OJFord »

Finnucane wrote: post #26
OJFord wrote: post #5

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

I think the difference is that those apps come preinstalled by Apple. Most users would think, if I install a bit of software, I can remove it later. That's normal behavior. If the KEXT installation process has a way of getting software into the special hidey-hole, it should provide a way of getting software out of it again if it is user-installed.

Wah, I misread then! I thought this was a new Apple-supplied program joining its others in being non-removable. I agree this is even worse then; I just also think I should be able to remove Safari, Chess, et al. too.

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#64

Post by ShabbosGoy »

otterley wrote: post #48
ShabbosGoy wrote: post #47

I'm glad I didn't upgrade. Why is it so hard for Apple to get System Integrity Protection right? Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc.

It took Linux/BSD years to get it right, too. It often takes a long time for the user-facing interface to catch up to the kernel functionality.

> It often takes a long time for the user-facing interface to catch up to the kernel functionality.

A long time to catch up for a company that revolutionized UX?

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#65

Post by acdha »

twir wrote: post #62

Add "System Integrity Protection" to the list of reasons why my next laptop won't be a Mac. Although based on a free operating system, Mac OS is gradually taking away users' control over their own devices. Either the user controls the software, or the software controls the user.

Just as with SELinux or AppArmor, you can ignore it if you think your normal practices keep you safe. That's probably mistaken but it's fully under your control:

https://developer.apple.com/library/content/documentation/Se...

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#66

Post by acdha »

ShabbosGoy wrote: post #47

I'm glad I didn't upgrade. Why is it so hard for Apple to get System Integrity Protection right? Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc.

> Why is it so hard for Apple to get System Integrity Protection right? Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc.

Same reason why you still so commonly find Linux and BSD systems where those are disabled: the improved security model breaks assumptions people have about what their code can do and it takes time to redesign code and retrain people.

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#67

Post by ShabbosGoy »

acdha wrote: post #66
ShabbosGoy wrote: post #47

I'm glad I didn't upgrade. Why is it so hard for Apple to get System Integrity Protection right? Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc.

> Why is it so hard for Apple to get System Integrity Protection right? Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc. Same reason why you still so commonly find Linux and BSD systems where those are disabled: the improved security model breaks assumptions people have about what their code can do and it takes time to redesign code and retrain people.

What does "improved security model" mean to you? One where the user cannot access ring0? My thoughts are: It's my fucking machine, I bought it with my hard earned money, so I should be allowed to do with it whatever I please.

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#68

Post by acdha »

ShabbosGoy wrote: post #67
acdha wrote: post #66

Earlier quoted context omitted.

> Why is it so hard for Apple to get System Integrity Protection right? Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc. Same reason why you still so commonly find Linux and BSD systems where those are disabled: the improved security model breaks assumptions people have about what their code can do and it takes time to redesign code and retrain people.

What does "improved security model" mean to you? One where the user cannot access ring0? My thoughts are: It's my fucking machine, I bought it with my hard earned money, so I should be allowed to do with it whatever I please.

Improved security model means not having it be incredibly brittle where the first time there's a zero day or the user gives the wrong response to a prompt they lose all of their data and need to completely wipe their system or buy a new one to recover (note that without full, bug-free firmware signing it's impossible to trust the system after a compromise).

Yes, you may think that you're going to make that call correctly 100% of the time day in and day out but even if that does happen to be true, it's not true for most people. Since Apple's the vendor and they consider trust/privacy a selling point, they're making decisions which are good for the other 99.999% of people using computers.

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#69

Post by sp00ls »

mintplant wrote: post #58
pilif wrote: post #20

Earlier quoted context omitted.

The dialog for kernel extension doesn't contain any of those labels though. Instead it offers you to open the "Security" preference pane where some additional UI will be displayed. If you blindly click buttons you will not accidentally enable a kernel extension.

I have barely any experience with macOS, but could an application perform those steps on a user's behalf if it were granted Accessibility access?

Every app I've installed that wants accessibility access follows the same steps from the comment you replied to. You must explicitly unlock that pane with your password after clicking the lock and then enable the app to have accessibility access.

Re: The ‘app’ you can’t trash: how SIP is broken in High Sierra

#70

Post by acdha »

AnIdiotOnTheNet wrote: post #36
acdha wrote: post #18

This post annoys me for describing a problem which other people might encounter with a good level of detail but uses “broken” to get clicks rather than the more accurate “I don’t understand or agreee with the security model”. As misnome and others have noted, if someone loads a malicious kext the only safe option is a complete wipe and reinstall – or depending on how much you trust Apple’s firmware signing, buying a…

On an organization's network, protecting resources from the user is a concept that makes sense. On personal devices, protecting anything from the user is a backwards and broken model that doesn't respect reality. It's the user's device, they should be able to use it any way they want. There is no need, or desire, to protect it from the user. What we really want to do, is protect the user's data from malicious actors,…

> It's the user's device, they should be able to use it any way they want.

Your mistake is conflating what the user authorizing with what the user wants. Nobody wants to install malware but millions of people manage every day. If blaming the user for mistakes was going to be a successful strategy we’d have evidence of that by now but since the opposite is true it’s no surprise that everyone is doing things which actually help people rather than doubling down on wishful thinking.

Post reply on HN