Over the years, Google has been shoring up security on Android in a bid to make the operating system more attractive to governments and businesses, and to reduce the threat of malware for regular users. Unfortunately, these changes often come at the expense of flexibility in our beloved platform. As we close in on the next major release of Android, due to be announced next month, SuperSU developer Chainfire has discovered a set of commits to the Android Open Source Project (AOSP) that may seriously impact some of the functionality currently enjoyed by many root users. In a post on Google+, he describes how a set of recent changes to the SELinux implementation will completely cut off write access to system to anything but recovery.

Chainfire previously posted about some changes root app developers would have to make to their apps to conform to other changes to SELinux, but nothing was identified that would directly affect end users. Once apps had been updated with the prescribed instructions, they would be able to go on functioning as intended.

In a commit appearing earlier today in AOSP, the SELinux implementation is set to remove a fairly important aspect for many root apps: the ability to write to the /system partition. The new policy strictly mounts /system as read-only in any context other than recovery, which is allowed write access for the purpose of applying OTA updates.


The implications of this policy are pretty straight-forward: any app with a need to modify the contents of the /system partition will have to do so by constructing a flashable zip file, instructing the phone to reboot into recovery to flash the zip, then rebooting back into the regular OS. This process will rely on a custom recovery like TWRP or ClockworkMod to flash unsigned zip files. Obviously, this process isn't as seamless and may ultimately interfere with the way some apps operate, especially if they make regular changes for any reason. Chainfire notes that there may be a way to restore write access via a simple mod flashed through recovery, but it's a loophole that that the Android team is already aware of, so it may be fixed fairly soon.

Quite a few root apps are based entirely around write access to /system while many don't need it at all, and there are plenty that fall in between. Backup utilities like Titanium Backup will go on largely unaffected since they primarily work with /data, and only touch /system if the user is restoring the apk of a system app. Modding tools like Xposed and Cydia Substrate already require a restart to install low-level components, but this will also impact many of the modules written for each framework. Unfortunately, File managers like Total Commander and Root Explorer, which are often used for making small adjustments to system configuration files, will require more involved updates and mandatory restarts to continue to fill that role. Don't worry, other apps like Greenify should be completely unaffected.

It's important to note that there is no change regarding the ability to read system files.

Nothing Is Official, Yet

These changes were only just posted to AOSP in the last couple of days, and the oldest of them was written barely over one week ago. Therefore, no device is officially running with these modifications yet. It has also been confirmed that the latest build of 4.4.3 for the Moto X is not affected, suggesting that these changes will not appear in other official releases, if 4.4.3 is even publicly distributed.

It's technically possible, albeit unlikely, that this implementation has been posted for testing purposes and may never make it into an officially shipping, consumer-oriented firmware. Of course, the mere fact it has been merged into the Master branch on AOSP suggests that we're looking at the future of Android. It's also worth pointing out that many of the recent SELinux patches come directly from Stephen Smalley, an employee of the NSA and one of the developers responsible for porting the SELinux project to Android.


Manufacturers will probably have the option to disable this policy, assuming they aren't partnered with Google and the policy doesn't become a part of CTS certification, but many will choose to include it simply for improved security. No doubt, there will be some custom ROMs built to re-enable write access for /system, but those will probably fade out over time.

Due to the timing of these modifications, this implementation could possibly go into effect with Android 4.5/5.0. Of course, we're getting pretty close to Google I/O, so it's entirely possible we won't see it until a maintenance release, or even the next major version.

In Closing

The sky isn't falling, at least, not yet. Sealing up write access to /system is a massive improvement to the security of our devices. In fact, this closes up one of the biggest remaining vulnerabilities in Android, and perhaps the single most important target for malware developers. Unfortunately, this will also add a bit of inconvenience to a few of the handy tools and hacks that many of us use. In the grand scheme of things, it's a worthwhile trade.

Many thanks to Chainfire for staying vigilant!


Notable Changesets: 95216, 96284, 96285

Source: Chainfire 1, 2, 3

Photo: Roots of big old tree by Paolo Neo