{"id":11646,"date":"2015-07-12T10:55:55","date_gmt":"2015-07-12T14:55:55","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=11646"},"modified":"2015-08-31T20:41:59","modified_gmt":"2015-09-01T00:41:59","slug":"system-integrity-protection-a-k-a-rootless","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2015\/07\/12\/system-integrity-protection-a-k-a-rootless\/","title":{"rendered":"System Integrity Protection (a.k.a. Rootless)"},"content":{"rendered":"

WWDC 2015 Session 706<\/a> (video<\/a>, PDF<\/a>, tweets<\/a>):<\/p>\n

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.<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

Which means that any piece of malware is actually one password, or one vulnerability away from taking full control of the device.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

This is what System Integrated Protection is.<\/p>\n

It is a new security policy that applies to every single process running on the system.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

For one, the task-for-pid and the processor-set-tasks SPI will now fail if they are called on a restricted process.<\/p>\n

And will set an 0 to EPERM.<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

[…]<\/p>\n

If you try to invoke lldb even as root and try to attach to the Finder, then this is going to fail.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p><\/blockquote>\n

Daniel Jalkut<\/a>:<\/p>\n

It’s awful restrictive. I ended up needing to disable it to even to attach to Dock with lldb.<\/p><\/blockquote>\n

Landon Fuller<\/a>:<\/p>\n

Add Dropbox – which used Finder code injection – to the list of things that’d be impossible to ship on today’s OS X.<\/p><\/blockquote>\n

Landon Fuller<\/a>:<\/p>\n

Mac OS’ original support for running multiple applications at once started life as a 3rd-party Finder extension.<\/p><\/blockquote>\n

Karsten Weiss<\/a>:<\/p>\n

However, one of DTrace’s selling points is\/was that you can use it anytime on a production system (without reboot).<\/p><\/blockquote>\n\n

Dave Nanian<\/a>:<\/p>\n

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.<\/p>

[…]<\/p>

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<\/strong> an “exact copy” of the source. Specifically, SuperDuper! must disable the system protection feature on the backup, and cannot<\/strong> recreate it when you restore.<\/p>

[…]<\/p>

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<\/em> 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.<\/p><\/blockquote>\n

Rootless also affects DropDMG<\/a>, since it installed its command-line tool<\/a> in a folder that is now off-limits. I’ve released a public beta<\/a> that adds compatibility with Mac OS X 10.11.<\/p>\n\n

Gwynne Raskind<\/a>:<\/p>\n

Getting compilers and associated tools to be independent of the traditional UNIX path structure is brutally hard.<\/p><\/blockquote>\n

Rosyna Keller<\/a>:<\/p>\n

rootless is likely going to cause issues with badly misbehaving Linux\/POSIX software.<\/p><\/blockquote>\n

Jonathan Wight<\/a>:<\/p>\n

also seen issues with some python modules (lxml) too. Ended up filing bugs all over the place and told “not our problem”<\/p><\/blockquote>\n\n

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.<\/p>\n\n

Update (2015-07-12): Gwynne<\/a> Raskind<\/a>:<\/p>\n

Also notice that the EA mentioned by Dave Nanian is, at least conceptually, just a reimplementation of chflags(SF_IMMUTABLE);<\/p><\/blockquote>\n

chflags() can only unset SF_* in single-user mode, whereas the EA appears to be gated by entitlements. The result is the same.<\/p><\/blockquote>\n

Landon Fuller<\/a>:<\/p>\n

Real difference is unrelated to security: EA is tied to Apple’s code signing approval rather than local admin control.<\/p><\/blockquote>\n

Gwynne Raskind<\/a>:<\/p>\n

That’s what inspired a new impl in the first place: Local admin control is assumed to be too stupid to be safe.<\/p><\/blockquote>\n

Gwynne Raskind<\/a>:<\/p>\n

I actually think it’d be much harder to social-engineer users into turning off SF_IMMUTABLE than into booting Recovery<\/p><\/blockquote>\n

Gwynne Raskind<\/a>:<\/p>\n

Use of the existing options for this kind of control would keep them from being able to bypass it for themselves.<\/p><\/blockquote>\n

Landon<\/a> Fuller<\/a>:<\/p>\n

Yes, and keeping it Apple-only makes it easy to flip a switch and make it mandatory, like iOS.<\/p><\/blockquote>\n

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<\/p><\/blockquote>\n\n

Update (2015-07-15): Dave Nanian<\/a>:<\/p>\n

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.<\/p>

This is all great news for users: basically, copying will work as it always has.<\/p><\/blockquote>\n

Landon Fuller<\/a>:<\/p>\n

The “security” of blocking code injection vs. the loss of productivity in only being able to use solutions Apple invents.<\/p><\/blockquote>\n

BinaryAge<\/a> (tweet<\/a>):<\/p>\n

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.<\/p>

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).<\/p>

So in a normally configured Mac, TotalFinder and TotalSpaces2 cannot run.<\/p><\/blockquote>\n\n

Frederic Jacobs<\/a>:<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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<\/em> 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?<\/p><\/blockquote>\n\n

Update (2015-07-16): Will Robertson<\/a>:<\/p>\n

The MacTeX people are already on top of the changes in El Capitan -- TeX Live will in the future be located inside \/Library<\/p><\/blockquote>\n\n

Update (2015-07-29): Craig Hockenberry<\/a>:<\/p>\n

The OS X “rootless” mode has benefits, but it’s going to make things very tough for the next generation of designers<\/a>.<\/p><\/blockquote>\n\n

Update (2015-08-13): See also Accidental Tech Podcast #128<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[2],"tags":[146,738,47,371,323,31,1137,317,30,32,1199,48,369,1235,1221],"class_list":["post-11646","post","type-post","status-publish","format-standard","hentry","category-technology","tag-backup","tag-conference","tag-dropbox","tag-dropdmg","tag-dtrace","tag-ios","tag-ios-9","tag-lldb","tag-mac","tag-macapp","tag-mac-os-x-10-11","tag-security","tag-superduper","tag-system-integrity-protection","tag-wwdc"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/11646","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=11646"}],"version-history":[{"count":10,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/11646\/revisions"}],"predecessor-version":[{"id":11924,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/11646\/revisions\/11924"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=11646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=11646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=11646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}