System Integrity Protection (a.k.a. Rootless)
WWDC 2015 Session 706 (video, PDF, tweets):
And for the same reason that you shouldn’t put all of your eggs in the same basket, you shouldn’t rely on a single layer of protection to defend the device, because no matter how bulletproof, or water resistant, or shock absorbent this layer is, when it starts failing you, then it’s complete game over.
Instead, you should rely on multiple layers of protection, ideally with different security properties that will delay the advance of an attacker and reduce your attack surface.
[…]
So the reality is that once you have code running on the Mac, it’s actually not that hard to become root, and once you are root, you have full control of the machine.
Which means that any piece of malware is actually one password, or one vulnerability away from taking full control of the device.
[…]
We need a layer that will eliminate the power of root on the machine and protect the system by default, as it was installed by Apple on the machine.
[…]
This is what System Integrated Protection is.
It is a new security policy that applies to every single process running on the system.
[…]
If you install anything in /bin, or /sbin, or anywhere under /usr like /usr/bin, /usr/lib, /usr/libexec, then you need to move this content into the appropriate subfolder of the /usr/local folder, because that’s the only location that is now available to third-parties.
[…]
For one, the task-for-pid and the processor-set-tasks SPI will now fail if they are called on a restricted process.
And will set an 0 to EPERM.
Which means that if part of your product relies on being able to attach to a system process at runtime, for instance, the Finder, and that you expect to be able to inject code into the Finder, that is not going to work anymore.
[…]
And finally, if you use dtrace, all dtrace probes that target a restricted process will not be matched anymore, which means you won’t be able to see an interaction between the process and the kernel.
[…]
If you try to invoke lldb even as root and try to attach to the Finder, then this is going to fail.
[…]
Now, because root can actually set a NVRAM setting and we can’t trust root to do the right thing here, it means we cannot have the configuration mechanism in the OS itself.
If you want to change the configuration, you need to reboot your machine in Recovery OS, and you can do so by holding the Command+R key on boot.
Then all you have to do is launch the Security Configuration application from the Utilities menu, and check the System Integrity Protection box, apply and reboot.
It’s awful restrictive. I ended up needing to disable it to even to attach to Dock with lldb.
Add Dropbox – which used Finder code injection – to the list of things that’d be impossible to ship on today’s OS X.
Mac OS’ original support for running multiple applications at once started life as a 3rd-party Finder extension.
However, one of DTrace’s selling points is/was that you can use it anytime on a production system (without reboot).
In our investigation, we’ve found that a new Extended Attribute -- com.apple.rootless -- is used to mark files and folders with this new protection. No process other than certain Apple-signed-and-authored ones can remove or write this attribute, and files and folders marked with this attribute cannot be changed.
[…]
Since we can’t write the com.apple.rootless EA, SuperDuper removes it during the copy. That means the backup -- while fully functional and bootable -- is not an “exact copy” of the source. Specifically, SuperDuper! must disable the system protection feature on the backup, and cannot recreate it when you restore.
[…]
It’s easy to regain full system protection features: you simply need to reinstall the OS from the App Store. You can do this at your leisure, but doing it as soon as possible means you’re less vulnerable (even though that vulnerability is quite small). It’s a painless process, and it writes the fresh OS under your existing applications and data. As an added benefit, it will speed up your boot process, since it’ll recreate certain caches that non-special-Apple-programs can no longer update.
Rootless also affects DropDMG, since it installed its command-line tool in a folder that is now off-limits. I’ve released a public beta that adds compatibility with Mac OS X 10.11.
Getting compilers and associated tools to be independent of the traditional UNIX path structure is brutally hard.
rootless is likely going to cause issues with badly misbehaving Linux/POSIX software.
also seen issues with some python modules (lxml) too. Ended up filing bugs all over the place and told “not our problem”
I’m worried about compatibility with LaTeX, as well as the long tail of Unix tools, which will probably not be adapted for a long time, if ever.
Update (2015-07-12): Gwynne Raskind:
Also notice that the EA mentioned by Dave Nanian is, at least conceptually, just a reimplementation of chflags(SF_IMMUTABLE);
chflags() can only unset SF_* in single-user mode, whereas the EA appears to be gated by entitlements. The result is the same.
Real difference is unrelated to security: EA is tied to Apple’s code signing approval rather than local admin control.
That’s what inspired a new impl in the first place: Local admin control is assumed to be too stupid to be safe.
I actually think it’d be much harder to social-engineer users into turning off SF_IMMUTABLE than into booting Recovery
Use of the existing options for this kind of control would keep them from being able to bypass it for themselves.
Yes, and keeping it Apple-only makes it easy to flip a switch and make it mandatory, like iOS.
I have to assume that’s the end-game. They’re whitelisting/grandfathering in user reqs that would cause blow-back while at the same time making it impossible for new entrants to introduce new requirements. Hard to see any other end-game
Update (2015-07-15): Dave Nanian:
Apple fixed the problem with copying the “com.apple.rootless” attribute in the Public Beta! So, with the release of our Beta 2 (download below), we’ve included the ability to copy with that EA preserved, and thus system protection is maintained on the copy as well. Plus, there’s no need to erase when restoring.
This is all great news for users: basically, copying will work as it always has.
The “security” of blocking code injection vs. the loss of productivity in only being able to use solutions Apple invents.
Both TotalFinder and TotalSpaces2 work by injecting code into processes that are part of OSX. They change the way those processes work, but they don’t change the underlying system - they just add features whilst they are running. If you quit TotalFinder or TotalSpaces2, those processes restart and system returns to its original state.
However, in El Capitan OSX 10.11, this kind of modification will be disallowed by a new feature called “System Integrity Protection”. It is also known as “Rootless”. The feature prevents both modifications to your system files, and to system processes whilst they are running (even if you enter your password for administrator access).
So in a normally configured Mac, TotalFinder and TotalSpaces2 cannot run.
What Apple is doing with this new OS X is the same thing they’ve been doing on iOS, protecting the boot chain by signing the whole boot process. This prevents (in theory) an attacker from hijacking the boot process to inject persistent malware. But unfortunately, this makes it really difficult to monitor your own machine against compromise. The only forensic analysis you can apply on such a system are black box analysis techniques since you can’t have any insights about what’s going on outside of user space. Malware becoming incredibly hard to track down if it used an exploit to enter kernel space. The hope is that it would not be able to find a persistence mechanism given that the boot chain is signed.
[…]
For now you can still disable most of these protections as a user/developer, but most of your users won’t (and it’s probably safer for them not to). As on iOS, the Mac’s distribution channels might be entirely controlled by Apple some day. It will be increasingly difficult to provide any feature that is not blessed by Apple. Something like randomizing your MAC address or verifying that your filesystem is encrypted like it should be might become impossible. How much of a “general-purpose computer” does it become if Apple acts as a gatekeeper to what operations can be ran on it?
Update (2015-07-16): Will Robertson:
The MacTeX people are already on top of the changes in El Capitan -- TeX Live will in the future be located inside /Library
Update (2015-07-29): Craig Hockenberry:
The OS X “rootless” mode has benefits, but it’s going to make things very tough for the next generation of designers.
Update (2015-08-13): See also Accidental Tech Podcast #128.
8 Comments RSS · Twitter
I'm starting to wonder whether ShareLatex (https://www.sharelatex.com) is going to be the only near-term solution for LaTeX. Offline editing is still possible via ShareLateX's Dropbox support, but the PDF generation happens on the remote host.
However, the TeXLive folks seem to be aware of all of this (http://article.gmane.org/gmane.comp.tex.macosx/47074) and working on remedies.
This is the end, beautiful friend. This is the end. My only friend, the end
Of our elaborate plans, the end. Of everything that stands, the end. No safety or surprise, the end. I'll never look into your eyes...again.
Lost in a Roman...wilderness of pain. And all the children are insane.
-----
I do share Landon Fuller's apocalyptic yet entirely clear-headed views. Back to the Mac!
RIP, general purpose Mac computers from Apple. RIP, Mac computers from Apple with user admin. 1984 - 2015. They will be missed.
Alternatively: And you'll see why 2015 will be like Nineteen Eighty-Four.
I don't think Apple has any choice. Just as it seems clear what this means as an "end game" for the Mac, it seems equally clear what the end game is for ALL computers given the current state of computer security.
How many people told their Mother, Aunt, some cousin to get an iPad as their general purpose computing device because it was safe and there was no way Mom wasn't getting to click those phishing links in email or that crazy uncle would download that "free kate upton sexvid" and compromise their system.
Exploit kits, ransomware, RATs, and a host of other terrible things are killing the computer industry for the average consumer. At this rate the computer industry was going to end up just being enterprise I fear.
Rootless brings Mac security closer to iOS and that's a Great Thing for the vast majority of people. Sure, the nerds will rage, but I don't see honestly see a middle path between the two extremes having any real hope.
"I don't think Apple has any choice ... I don't see honestly see a middle path between the two extremes having any real hope."
Well, that's the thing. From reading the relevant twitter feeds, and several articles on the topic, I think Apple most definitely did have a quite viable middle path available between making true root too easy for users and making it simply unrealistic for users.
"Exploit kits, ransomware, RATs, and a host of other terrible things are killing the computer industry for the average consumer. At this rate the computer industry was going to end up just being enterprise I fear."
No doubt. But this seems an unnecessarily Procrustean solution to that very real problem, and one that has as much to do with ulterior motives as the stated motive. (Plus, it's a solution which won't just eliminate the very real problem, unless we head much further down the game console model.) Because Steve-o's sensible explanation that everyone doesn't need trucks anymore is true doesn't mean that no one needs trucks...
[…] more complicated for non-basic uses. Meanwhile, the Mac has gained iCloud Drive, sandboxing, and rootless, which offer many of iOS’s simplicity and safety advantages without (in theory) compromising […]
[…] of LaTeX because the El Capitan installer had automatically moved the files for compliance with System Integrity Protection. I just had to update the path in my […]
