back
3 comments
On Apple Silicon, you may lose access to e.g. Touch ID login to websites and Apple Wallet, as Apple’s Touch ID protocol allows^ websites to require a secured+unmodified system partition and Wallet may require the same for anti-fraud purposes. I expect Steam VAC and Xbox cross-platform multiplayer will take note of this someday, too.

This relates closely to the likelihood of future PCs with Microsoft Pluton^ firmware as well. I assume that Microsoft saw the writing on the wall about secure OSes and remote education and online testing and is repurposing their Xbox anti-tampering system for Windows before they get locked out of that market by Apple Silicon.

It’s not about disallowing you from tampering, or about blocking third-party operating systems — it’s about attesting whether or not you are able to tamper, in scenarios where a remote third-party has no physical access to your system. The Linux secureboot shims probably will not be sufficient to earn ‘tamperproof’ as they boot arbitrary unsigned code with tamper-capable privileges via /sbin/init or whatever.

^ via crypto-signed attestations by the Apple firmware+OS, working in tandem to attest that the stack is not and cannot be tampered with as currently booted.

^ https://news.ycombinator.com/item?id=25123990

EDIT: Apologies, the missing paragraph connecting to the parent comment is —

IT departments will begin updating SSO/MFA systems to require, when deployed hardware permits it, the tamperproof attestations. This will protect them from the liability risk of employees turning off key security protections such as SIP, and may result in Apple Silicon being widely adopted by sensitive industries such as banking and IT once they realize they can reduce their risk and liability insurance costs by doing so.

This is already here, Apple[0] can report to a MDM whether or not SIP is enabled, and then Microsoft's Intune[1] can use this to allow or deny access to corporate resources (similar to some stuff that Google had in the BeyondCorp paper).

0: https://developer.apple.com/documentation/devicemanagement/s...

1: https://docs.microsoft.com/en-us/mem/intune/protect/complian...

So SIP isn't about keeping me secure. It's about keeping my computer secure from me.
Keeping you secure requires keeping the computer secure from attackers. You can't be distinguished from an attacker, from the computer's perspective. Having the computer be able to attest that it's unmodified means that it doesn't have to mistrust you so aggressively, relative to today.

Requiring a reboot to rescue mode to disable SIP is sufficient to block most social engineering attacks that would otherwise have you click through dialogs to bypass it. A dedicated attacker can still overcome this, and once they do, they can impersonate you readily.

If the computer can attest that it's unmodified, then it's possible to throw up alarms for non-expert users when their computer is in that state. I don't think most websites will bother, but those that care sure would love to be able to do so. None of this is specifically for the benefit of users who want to hack the software internals of their computers, though — but those are not the target market for security practices today in any case, since they can overcome literally any barrier prior to this that says "please secure your device before entering".

Still, from an IT standpoint, it sure would be nice to find out how many expert technical users are lying about keeping their system in secure mode when they have privileged access, because they don't think it's necessary and they don't see any harm in lying about it. I'm guessing it's something like 10-20% of all IT admins using unmanaged devices. We'll find out soon enough!

> You can't be distinguished from an attacker, from the computer's perspective.

Then what's the point of things like passwords and fingerprint scanners?

> Having the computer be able to attest that it's unmodified means that it doesn't have to mistrust you so aggressively, relative to today.

How so?

> Requiring a reboot to rescue mode to disable SIP is sufficient to block most social engineering attacks that would otherwise have you click through dialogs to bypass it. A dedicated attacker can still overcome this, and once they do, they can impersonate you readily.

We need to lock people out of their own computers to protect them from social engineering?

> I don't think most websites will bother, but those that care sure would love to be able to do so.

In practice, this will end up just like the abomination that is SafetyNet on Android, where if you take control of your own device, you can't use Netflix, Snapchat, Pokemon Go, Super Mario Run, Android Pay, etc.

> keeping their system in secure mode

Really? "secure mode"? What kind of attacks specifically would this prevent that an IT department would care about, as opposed to Hollywood/RIAA/etc. caring about?

You’re already familiar with the difference between passwords and secure computing platforms, as evidenced by the citation of SafetyNet and Pokémon Go, and your use of the phrase “abomination” leaves no opportunity for further discussion, so I will stop now to avoid wasting any more of your time. Apologies and be well.
It simply affords you the same level of security enjoyed on macOS up to and including 10.10 (Yosemite) -- which was state of the art until July 9, 2018.
Are Windows and Linux insecure? They don't have anything like SIP. Also, the whole idea of SIP has a strong https://xkcd.com/1200/ vibe.
It's worth noting that macOS without SIP is a bit more permissive than Windows—it allows you to load unsigned kernel extensions, for instance, whereas 64bit Windows will not load unsigned drivers†.

But I generally agree—power users should feel fine disabling SIP.

Windows has Windows Resource Protection (previously known as Windows File Protection) with same goals as SIP.

SELinux for Linux can achieve similar levels of protection.

Windows Resource Protection doesn't prevent code injection, and can be disabled from within the OS. I don't consider them equivalent.
Disabling allows you to run dtrace...