From Apple's own two-factor account support documentation:
"While [Apple Support] can answer your questions about the account recovery process, we can't verify your identity or expedite the process in any way."
Even if you manage to confuse a support agent, they cannot do anything to speed account recovery or be socially engineered into account compromise.
A friend of mine used to work in Apple's account security phone department, and can confirm that they really do mean CAN'T. Support techs can view a few bits of information that aren't displayed to the user, but cannot change anything.
Do I still need to remember any security questions?
No. With two-factor authentication, you don't need to choose or remember any security questions. Your identity is verified exclusively using your password and verification codes sent to your devices and trusted phone numbers. When you enroll in two-factor authentication, we will keep your old security questions on file for two weeks in case you need to return your account to its previous security settings. After that, they will be deleted.
> Some parts of the filesystem become off limits, even as root. But installers have access!
Point of clarification: only Apple-signed installers can modify system paths. (c.f. https://support.apple.com/en-us/HT204899) All other installers are subject to SIP restrictions.
And Apple only added a few simple steps for people eager to tinker: reboot and disable SIP. Or reboot into the installer for the other OS with which you prefer to tinker. Or create a VM with an experimental OS. Frankly, most of those steps existed before SIP.
Most users shouldn't care or notice, and will benefit from increased protection. People who want to tinker will (and can and should!) tinker.
> Apple can [sic] starts using the new Trusted Computing[4] features on new CPUs (such as SGX[5]), good luck regaining control.
It seems the apocalypse came to pass a while back, with the Secure Enclave in Apple's A7 processors.
> Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions.
Here's the funny thing: normal people benefit from those restrictions. Without them, their devices – the ones you insist they should own – would quickly become someone else's: the attacker's. It would be awesome if people started thinking about long-term consequences.
Honest question: do you hate root? Should all processes run with equal privileges? Does the kernel have an evil and undesired permissions level?
> Honest question: do you hate root? Should all processes run with equal privileges?
Of course not. Stop making up straw-man arguments.
> Without them, their devices – the ones you insist they should own – would quickly become someone else's: the attacker's
So users cannot run any program they download? Or are you claiming that programs that run as a user - with no intention of touching system files - cannot harm that same user? Many past exploits and trojans run entirely as the user.
SIP may protect the OS, but it will do very little to protect the user. Unfortunately, while this should be obvious, scaring people into giving up their freedom works, even when the "solution" doesn't actually do much (or anything) to prevent the supposed threat.
do you hate root? Should all processes run with equal privileges? Does the kernel have an evil and undesired permissions level?
The key difference here is that root is well known to be the all-powerful user, the one that really owns the system, while SIP is Apple's attempt at removing the power that root should have.
Given that Apple could have actually taken away root's power if they wanted to, it seems kind of inaccurate to call this an attempt to do so. They have given the user the option to have root on or off with a default of "off." They didn't attempt to disable root and fail.
I understand your concerns about taking away user power, but this doesn't seem to be that. The user still has the power to do the same things, they just have to decide that they want it. You could just as well say that not making the system files world-writable takes away the user's power, but in fact it's just locked behind a door that the user has the power to open.
I'm idly curious: what were your "symlink issues with /usr/bin/"? As with other unices, /usr is system-owned and anything not under the /usr/local hierarchy may be modified or destroyed during OS upgrades.
Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP.
Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.
One completely normal developer thing I need to do that involved turning off SIP is setting library and framework paths to debug an executable outside of Xcode.
We archive our daily builds so we can regress problems to a specific check-in. Now I could just roll back my source and build from that, but that takes significantly longer than just copying the regression build from the server. (Not to mention that if the revision is old enough, I need to install an older OS and Xcode just to build it.)
But our archives are straight out of an Xcode development build - they contain separate libraries and frameworks that we build and that aren't moved into the executable like during an install. So to run them from a disk image you need to set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to get the OS to know where to look for them. But this doesn't work with SIP. This is not some low-level kext-related issue. This is pretty basic development stuff with Xcode.
SIP shouldn't interfere with DYLD variables for normal (non-"restricted") executables. Unless you're using something like Java, which normally runs via a restricted launcher; but in that case you can bypass the launcher (see https://bugs.openjdk.java.net/browse/JDK-8139288).
Java troubles. A java application I needed required the latest java update but after running the Oracle updater, /usr/bin/java still pointed to the previous version. A simple solution is to point the symlink to the right place, but with SIP enabled that symlink can't be modified. Here's the stack overflow guide I was following: https://stackoverflow.com/questions/12757558/installed-java-...
Looking back, I think you are right, it would have been easier to just add a symlink under the /usr/local/bin folder. Though it didn't cross my mind at that point.
If you're looking to hide your activity from malware, you should be incredibly excited by SIP. With SIP enabled, you have more protection from malware introspecting other processes or monitoring activity on the system. Hell, if you're a researcher building tools to detect and analyze OS X malware, you'd likely benefit from SIP by opting-in your tools to SIP's restrictions. (Tangential example: Chrome is taking this step; Canary is currently SIP restricted.)
Malware can only introspect SIP-protected activity by employing kernel exploits. If malware can compromise the kernel, it's game over. You're not going to hide anything, ever.
If anything, it sounds like you want SIP's purview expanded to encompass more of OS X.
Improved privacy is one benefit https provides. There are two other benefits worth considering: authentication and integrity. Without https, there is no way trust a site's identity, and no guarantees the data you're receiving was not modified in transit.
Don't forget to weigh those other two factors when judging https adoption. Your goals are understandable and worthwhile. They're also still achievable with appropriate client management software.
Consider this: in a world without https, your children could visit a valid, approved domain and be served malicious or undesirable content because someone modified the content in flight or intercepted the connection. There is literally no way for you to have any guarantee what's served to your children.
In a world with https (and appropriate client management software), you can be confident they really are only receiving approved content because the connection is authenticated and traffic cannot be modified in flight. (And your children are less easily tracked by unknown 3rd parties, to boot.)
Authentication and integrity are often forgotten when discussing https, which is unfortunate because those are two incredibly important benefits that further motivate widespread https deployment.
OS 5 added a remote virtual interface (RVI) facility that lets
you use OS X packet trace programs to capture traces from an
iOS device. The basic strategy is:
1. Connect your iOS device to your Mac via USB.
2. Set up an RVI for that device. This creates a virtual
network interface on your Mac that represents the iOS device's
networking stack.
3. Run your OS X packet trace program, and point it at the RVI
created in the previous step.
If you don't pair the iOS device with the Mac, the technique won't work.
"While [Apple Support] can answer your questions about the account recovery process, we can't verify your identity or expedite the process in any way."
Even if you manage to confuse a support agent, they cannot do anything to speed account recovery or be socially engineered into account compromise.
https://support.apple.com/en-us/HT204921