Back in Android version 4.3, Jelly Bean, SELinux was introduced into Android, albeit in permissive mode which is basically turned off. This was switched to enforcing in KitKat, 4.4. SELinux policy is in effect and things that it doesn’t want to allow won’t be allowed. SELinux was ported to Android by a team who submitted a patch earlier this year that stated “/system is always mounted read-only, and no process should ever need to write there”.
This was a bit of a worry for those of us who prefer root access on their Android devices to be able to control how it behaves and how it looks. In the end it was explained by Chainfire that there was an easy way around this by just commenting it out or turning it off inside a custom kernel. Easy for those with an unlocked bootloader, not so for others. At the time Chainfire, the developer famous for SuperSU, commented that he had found other ways Google could make Android more secure which may make root access even harder but Google were yet to implement them. It seems that Google did in fact close up many of those holes that could launch the Superuser daemon.
A few days ago we published an article about the new rooting tools for the Nexus 5 and 7 for Lollipop. The standard root process now requires a custom kernel as well as flashing the usual SuperSU inside a custom recovery as suspected months ago. Certainly not a problem if you have a Nexus device and have unlocked the bootloader.
Chainfire has explained the new process in a Google+ post stating that to fix root permanently without making the system unstable a modified kernel with an altered ramdisk needs to be flashed. From the AOSP commit mentioned above 5.0 builds from AOSP have required all started services to run in their own SELinux context, instead of init thereby preventing root access. The modified kernel causes the daemon’s startup script to run at boot as the root user with the init context. The modified kernel has the line inside “init.rc that forces the install-recovery.sh script to run as the install_recovery context, so now it runs as init again” and thus SuperSU works as it should, bypassing the SELinux limitations in this area.
There are repercussions for users with the SELinux implementation. In the past root access was attainable with only modifications to the system partition. If the new inability to change system partition is combined with a locked bootloader (and possibly dm-verity: dm-verity is a verified boot that manufacturers can implement that prevents “persistent rootkits that can hold onto root privileges and compromise devices. This experimental feature helps Android users be sure when booting a device it is in the same state as when it was last used.” Unfortunately this also prevents custom kernels from being flashed) root access is virtually impossible. This is the result the security developers of Android are aiming for.
The end result is that all root apps will need updating and modification to change how they access root. Not difficult by any stretch of the imagination but definitely work that needs to be done.
There are two ways that the custom kernel could possibly work. First way is how Chainfire has done it for the Nexus 5 and 7 kernels, by setting only part of the SELinux to permissive while leaving the rest of the OS set to enforcing and security thus mostly kept in check. The second way involves setting the entire Android system to permissive but that opens up the entire OS and thus makes it more insecure. This is obviously not ideal and some app developers may attempt to do it this way although Chainfire plans to educate developers in how to access root without making the entire system permissive.
Where this lands in the final version of Android 5.0 is unclear but one thing for sure is that many Android root apps will need altering to work with the new method of obtain root access, a modified kernel. It’s nice to see Android heading down a secure path it does make it difficult for those users who are used to doing what they want with their own devices.
Reading between the lines one thing is now clear: if you want root access on Android version 5.0 without a heap of shortcuts and fun and game it is best to buy a device where the bootloader can be unlocked fully. With manufacturers still playing games with the Android development community the answer seems clear. If you want full root access it is not just a matter of buying a phone where the bootloader can be unlocked but a matter of buying a phone that can be unlocked fully without any repercussions (eg. warranty of software limitations), a Nexus device. Yet another reason a Nexus device appears to be a must purchase for root users.
