The Fight for Root

Apple’s iOS is often criticized for having sandboxed apps only and the lack of customization that it involves. Since the original release, Apple has been increasingly opening up APIs to third-party developers and last year, they announced their biggest attempt at making the operating system more integrated across all the sandboxes with Extensions.

Extensions are an elegant solution to solve a problem: how do you make a flexible, consistent and secure user experience on a system where all the processes all apps live in separate silos?

Extensions do solve some of that, but only at the pace that Apple allows. Opening up an operating system to customizations that way undeniably takes time. But there is also another reason why this process takes time. Apple doesn’t want to give freedoms to developers that they would be later be taking away from them. Apple has been really reluctant to open up some APIs. One of them is the NetworkExtensions framework. It’s been around for some time now, they gave private access to OpenVPN to develop their own app. With iOS 9, they announced it publicly and are now inviting developers to apply to get access to the NetworksExtensions framework.

Depending on Apple’s roadmap and will, you won’t be able to build the app of your dreams (not even speaking about distribution here).


On the Mac, things have always been really different. Inheriting from the UNIX/BSD legacy, the Mac had a quite permissive extension model. People have been customizing their Macs since the early days. Using dependency extension or patching binaries, the operating system was extended to serve the user’s needs and desires.

But over the last few years, Apple has been preparing to change all of that.

GateKeeper introduced new code execution settings that could restrict code execution to only Mac App Store apps, or MAS apps and code-signed ones or everything (don’t require code signing).

Apple had also mapped out a roadmap to provide system extensions crucial for desktop users. Virtualization is something that OS X users have significantly using. Up to recently, that kind of software required kernel extensions to get access to laptop ressources. But since Yosemite, Apple has now baked a hypervisor to run virtual machines directly into the operating system without requiring .kext (kernel extensions).

Hypervisor (Hypervisor.framework). The Hypervisor framework allows virtualization vendors to build virtualization solutions on top of OS X without needing to deploy third-party kernel extensions (KEXTs). Included is a lightweight hypervisor that enables virtualization of the host CPUs. Source

This all lays out the way to a completely sandboxed environment on the desktop. At WWDC, Apple presented System Integrity Protection. As it’s name suggests, System Integrity Protection is meant to protect the integrity of the system.

System Integrity Protection

I will quickly go over some of the implications of System Integrity Protection (referred as SIP from now on). SIP is an entire layer that lives between userspace and kernel space. It prevents applications to attach to system processes and protects against code injections. On a previous version of OS X, your system was only one (often weak!) password away from being fully compromised since OS X users are running as administrators and can get root by entering their passwords.

Of course, sandboxed applications are not affected by this. But any application that is customizing your system (a lot of developer tools!) are affected.

Note: SIP can be disabled by rebooting into the recovery partition to set a NVRAM register.

Don’t get me wrong. SIP is a great defensive measure in most cases. It can address some of the issues mentioned by Patrick Wardle in his excellent talk about persistence of malware on the Mac.

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.

Trading liberty for security?

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?

If you’re interested to discuss new ways of preventing persistent malware without locking up the boot chain and protecting the kernel, join the discussion on Hacker News. More information about System Intergrity Protection can be found in the “Security and your Apps” session from WWDC.

For more updates, you can follow me on Twitter too.