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.

Source: Chainfire Google+.
    Inline Feedbacks
    View all comments

    What is everyone using titanium backup to restore? I don’t keep anything on my phone that can’t be wiped with short notice. (Confessions of a former crack flasher)


    Probably in app purchases without cloud storage. I know that my mother has spent about 120 bucks on IAP in a game, and I have informed her that if her device dies or is lost that she will have nothing and would have to start from scratch. She has feaked out on multiple occasions. I cannot believe there is still no built in method for at least a full encrypted backup of an Android device either to the cloud or at least a computer. This is the last and most important thing on the list of needs I have with… Read more ยป


    That’s what I thought, doesn’t “Google Play Games” have back up functionality built in? Albeit not often used by devs. I just checked my root permissions and they are all cosmetic and could mostly be fixed with app (Launcher) design or if I could bring myself to go back to Nova Launcher from Google Now Launcher.


    Yeah, that is the problem, it has to be coded for (and often is not). We need something that backs the entire android device up…even if only to restore to the same device. And it needs to be secure.


    A full apps and data backup from my, still currently used, LG Optimus One, which runs GB 2.3.3


    i keep a single backup of each app and it’s data. it does allow relatively quick and accurate restore of app post flashing a new rom etc. Google really need their own solution for this. An Aussie dev told me he was going to do something if google didnt in Android L… still waiting on that.. he is very busy, plus only 17yo…

    Joshua Hill

    Sony allows unlocking of bootloader. Are there other manufacturers?


    Sony allows that, while using that as grounds for their disabling the driving software that gives full and complete use of the hardware in your Sony Android device.

    Joshua Hill

    Sony have a right to protect their own developed software and algorithms. Unfortunately the way they go about that by effectively disabling all their proprietrary stuff when you unlock the bootloader is the wrong way to go about that.


    true . they do. silly thing is that there are ways around doing this but those ways can often lead to bricked phones, the thing they are trying to avoid by having an official bootloader unlock.


    HTC have a Bootloader Unlock facility

    Iain Simmons

    Thanks for the write-up Scott. Very informative.

    It will be interesting to see which phone manufacturers side with the developers and which choose to lock everything down.

    Your comment that Nexus devices are a must-purchase for root users is what concerns me the most, particularly with the cost of the latest Nexus devices!

    Here’s hoping Sony continues their streak of supporting devs (they added the Z1 and Z2 to the AOSP recently).


    Big reason I moved to android is having full control of my device. If this was taken, then I may will look at other ecosystems.


    Where would you go?

    Windows? Android?

    I don’t think this major statement of “someone took my cheese so I’m leaving!” is warranted at the moment. Are you going to flash straight to Android L upon release or wait until XDA build the workarounds?


    Ubuntu Touch or Tizen

    I would imagine those “distros” wouldnt have an issue with superuser access

    Joshua Hill

    Hence the op said they may look at other alternatives. Don’t be putting words in people’s mouths or misconstruing what they said.

    Darren Ferguson

    I could almost go without root if there was a way to back up my app’s data and the ability to restore it.


    A fair number of apps allow for cloud backup but there are a fair number that don’t and root is the only way to transfer.

    This could be a short term blow for android till as work around is found.


    This security measure puts a real impediment in any plans I had to upgrade my current devices.

    Without root, restoring from a TiBu backup can’t be done.

    Darren Ferguson

    Root is still obtainable. Just takes a few more steps.