NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.
As promised, here are some more details about the current situation.
Why it breaks
Google has really put some effort into better securing Android, and we've seen a lot of SELinux related commits to the AOSP tree over the past months. There is some disconnect between the AOSP tree and actual L preview builds, some things from AOSP are not in the L preview build, and vice versa. Ultimately, it's a pretty good bet these things will mostly align, though.
On most devices and firmwares, SuperSU's daemon is started by the install-recovery.sh service script that runs at system boot time, as user root with the init context. This is what the daemon needs to function.
Recently, they've started requiring all started services to run in their own SELinux context, instead of init. Developers and security guys following AOSP have known this was coming; AOSP builds have been logging complaints about this specific service not having its own context for a while now.
Now this script runs as root, but as the install_recovery context, which breaks SuperSU's operation, as it is a very restrictive context.
In the last AOSP build I have tried (a few weeks old), there were a fair number of other holes that we could use to launch the daemon. At first glance(!), it seems those have all been closed. An impressive feat by the guys working on this, if it proves true.
How to fix it
To fix root, all that really had to be done was ensure the daemon's startup script is run at boot as the root user with the init context.
There are multiple ways to do this, but unfortunately for now it seems that it does require a modified kernel package (changing the ramdisk).
In the modified kernel packages I've posted for the Nexus 5 and Nexus 7, the daemon's startup is fixed by commenting out the line in init.rc that forces the install-recovery.sh script to run as the install_recovery context, so now it runs as init again, and all is well.
Repercussions
As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.
Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.
Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well.
Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.
It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now.
Apps need updates
Unsurprisingly, with a new major Android release, apps will need updates. None more so than apps that go beyond the Android API, as root apps do, but even some non-root apps will be affected by the security changes.
As one example, someone posted in the SuperSU thread of a kernel flashing app that didn't work. From the logcat you could see that it was looking for partitions in /dev/block from its normal non-root user and non-init context. That used to be possible, but now it is restricted: normal apps no longer have read access there.
The solution for that app is actually quite simple: list the /dev/block contents using root instead. But simple solution or not, the app will still need to be updated.
By far most root apps should be updateable for L without too much issue. There are indeed exceptions that will need some special care, but those are rare.
Permissive vs enforcing
The kernel packages I posted for the Nexus 5 and 7 LPX13D firmware keep SELinux mostly set to enforcing. I say mostly, because SuperSU actually switches a small part of the system to permissive, so apps calling su can do most things without much interference. The details on this are lengthy (yes, your apps will be able to modify policies as well if needed, which should be rare), and I will document these for other developers after L retail release, assuming it will all still work at that time.
Alternatively, you can set the whole system to permissive or otherwise disable SELinux. There are other kernel packages released that indeed do this. The advantage here is that it instantly fixes some apps' issues, as the SELinux based restrictions have all gone the way of the dodo. The disadvantage here is that you've just shut down a major part of the security system of the device.
Some would argue that a device with an unlocked bootloader, root, encrypted modem firmwares of which nobody really knows what they're doing, etc, is inherently insecure, and thus disabling SELinux doesn't make much difference.
I personally disagree with this. While I do agree that these things weaken security down from the ideal level, I would still not disable more security features than I absolutely need to. Just because you cannot eliminate all attack vectors, is no reason to just completely give up on defending against them.
It is of course your own choice if you want to run a permissive system or not. I will strive to keep everything working in enforcing mode though, and I hope other root app developers will do the same - as stated earlier in the post, I believe this is still possible.
(everything in this post is subject to change for retail L release, obviously)
I agree
Thanks for taking the time to explain things too.
thanks for your great work
Thanks for the explanation and for all of your hard work...
I'm always amazed how dedicated and indeed devoted you are to your work!
+1
Very user friendly argumentations: only those who know can teach. Respect!
Very good description!
Thank you chainfire
Glad to see Google enabling SELinux.
Great work
Thanks
I have used official Rom for 2 month and custom Rom for more than 3 years.
All hail the God of root!
So. If i understood, maybe Custom ROMS are an easier way to be with root privileges?. I apologize If i said something crazy
Thank you for the detailed and good explanation. Your great work is and always has been one of the Reasons why Android is the best System around!
Great,thank your job
On Google Play applications that require root permissions are lawful. Google earns from many years 30% on every sale even from these developers. The end-user as the owner of the phone, has the right to decide for her security. It's time that Google provides an official method and always valid to get root permissions as in other OS. In my opinion, this should be required by law, otherwise it means that the manufacturer of the device has more permission of the owner and this involves high insecurity for privacy and personal data. I am confident that if, in many, we start lawsuits, the root access also with a secure hardware button can be achieved because privacy is a universally recognized right. And a so beautiful app like SuperSu can help us to manage this root permissions.
Do not grant root permissions, it should also be at odds with a lot of anti-monopoly laws, it would be impossible without root uninstall many applications and services that we did not choose and that with force will be installed on our terminals.
But the Countries where they are ? Maybe they do not care that you are practicing this monopolistic system which is one of the greatest abuses of the history of computing.
This guy rock!
Thank you
Now what can you do if your phone did a system update while you were rooted but after the update it freezes on the boot
thank you.. no more flickering on boot startup on my nexus 7
+DroidMote Server / Client keep in mind that Google isn't restricting anything here. All of their own Nexus devices can be officially unlocked, and their firmware completely replaced by whatever you want. It is the OEMs, virtually always on order of the carriers, that lock devices. By far most high-end non-carrier devices are unlockable and thus rootable.
Consider that even if Google built in their own root facility for (retail!) firmwares, then the carriers would just have the OEMs take it out...
Business users also actually want the added security, there will never be a law anywhere that requires root access for these devices. Also because you have choice: you can buy an unlockable phone, switch carriers, etc. There is no locked device monopoly, unlocked devices are available in any country that I know of.
Now, if your favorite carrier offers the model that you want in the area that you want it for the price you find agreeable, that is a different question. Then again, the carrier has no obligation to give you what you want, and in a capitalist society, they shouldn't.
Thanks +Chainfire for explaining the situations. You are the man
You are a genius man, thanks for all of your efforts.
+Jorrit Jongma I know what you say, but an hardware button like in Chrome OS can help both users. Users that want full security, and users that think that having root permissions you are more secure. like me. I think differently from you, does not grant root permissions and create a large number of binary blobs on a open source OS, is a deliberate strategy to create a monopoly system.
Thanks for your very hard work.
No one has forgotten the history of internet explorer and a lot of money that Microsoft had to pay for having imposed its own software in a forced way.
It's time to change and all together we can.
Thank you for taking the time +Chainfire that was a good read.
Wow!! That's a very detailed explanation.. Thanks ☺
Thank you +Chainfire for explaining this so well....
What does this entail for Xposed if it ever manages to run on the ART runtime?
+Sayan Goswami, +Luqmaan Dien Mathee get a load of this ....
+amartya baidya checked it out man. This makes happy to see security being tightened in Android.
+Luqmaan Dien Mathee makes me a little worried that custom ROMs to maintain root over each build will permanently disable SE Linux and make the whole system permissive. ...I'm not sure that is the right way to go
I think Chainfire was the first word I heard after learning what root was 3 years ago on my first Droid.. Can't say thanks enough for all the dedication & hard work you've given over the years! ?
Thank you +Chainfire. You are a genius man!
+Chainfire=legend
Thanks Chainfire for all the hard work you put into the Android Community and for all the CF Autoroots, Super SU et al.
Thank you, +Chainfire, not just for this excellent post but also for the excellent information you also provide in your http://su.chainfire.eu/ page (particularly section 5)--invaluable stuff! :)
+amartya baidya: it isn't, and those advocating disabling SELinux or forcing it into permissive mode should stay the hell away from shipping system software to 3rd parties.
I'd like to see ROM makers and su devs agree on a standard set of SELinux contexts for root-enabled apps (and related manifest permissions), but the general consensus seems to lean on the usual unconfined su daemon (or worse, as you pointed out).
That would leave upstream and OEM firmware users (me included) out of the game, but things aren't looking good for them anyway with dm-verity still floating around.
+amartya baidya true that sucks. Well I've been permissive all this time? but I think in future I'll stay enforcing. Security will be something I look forward to.
Great work as always. Thanks for all that you do. ☺
Thank you for all the great information!
Thanx for the expalnation… keep up the good work you do.
I'm no expert for SELinux on Android, so please bear with me. Would it be possible to extend the policy with transition rules from install_recovery type to init (or what would be needed). If it is possible to change domains to permissive, it looks like modifying the policy is possible?
Thank you for in-depth exlanation. No cookie for me...
The whole reason why Android is better than iOS is because we can root aka jailbreak the device and gain complete control over it. And I suppose, if locking everything was a way to go then OEM's could give an option either in the boot loader or recovery to allow users to choose to gain root access or something. Normal users won't be able to get their and advanced users would also be happy. Everyone goes home happy!
Thank you +Chainfire for the detailed information,the quality and dedication of your work is be beyond compare.
Gracias por hacernos la vida más fácil.Gente como usted es la que hace avanzar al ser humano
+DroidMote Server / Client If you could turn off the security with a hardware button or from a bootloader that would negate the entire corporate data control idea. Either way, the corporations that control this apparently don't want it that way, so again, vote with your wallet.
+Klaus Lichtenwalder Chicken/egg problem. You can modify the policies to allow install_recovery to transition to init, but you need to be init before you can modify the policies. Unless you put the modified policy in the kernel ramdisk, which then still requires you to reflash the kernel.
+Jorrit Jongma I see... Of course, yes. But then Chainfire speaks about SuperSU setting some domains to permissive, or changing policy from apps. This would also not possible in install_recovery_t? Otherwise it would defy security? There is no modifying policy without flashing an updated kernel/initramfs?
Btw, any good pointers re implementation of SELinux on Android (policy, implementation, setup)? I couldn't find any
Thanks +Chainfire for the detailed reply, I was holding off on root after reading your earlier comments and awaiting this more detailed response. Glad to see enforcing route.
+Klaus Lichtenwalder again, to do any of these things, su has to run as init to start with. You cannot change the policies from install_recovery context. An app that calls a properly working su running as init, then can execute calls as init as well, so it can modify policies if it wants.
There are other facilities to load a modified policy, by putting these policies on the data partition. Those generally have to be signed by a trusted key that we don't have though, and the methods this works vary by OEM.
PS. I am Chainfire, this is my personal account.
Спасибо!
+Jorrit Jongma oh. sorry for not checking earlier... I see, so other apps can use su for changing the policy, but su obviously not ;) at least not for the purpose of getting the necessary permissions... Thanks for the explanation!
Sounds like of you want root, it's going to be Nexus or GTFO.
Which is fine. If root is a feature we want, we vote with our wallets to buy devices with unlocked bootloaders.
Chainfire it's BigG, thanks for hars work :)
that's why I can't flash your kernel and have root access...? I tried several times but then, when I check kernel info, it's always the google one and no root access...
Thanx for your fantastic work.
p Phzd
Duck selinux
Thanks!
Siete i N.1
I agree with your assessment.
The only reason I root my phone is so that I can run an ip-tables based firewall and an ad blocker that modifies the hosts file.
I'd prefer to have as much security as possible.
interesting read, thanks for the info and especially thanks for your work.
Will there be a fix for the nexus 4 here is the rom I'm using
http://forum.xda-developers.com/showpost.php?p=56145658&postcount=17973
It says its a preview bit I have to seen any problems
Has anyone been able to remove aosp browser, calendar, messaging, and music? I do have root and tried to delete these apps using root browser which usually does the trick but with no luck this time. Every time I go to the apps section in settings, it appears that these apps are no longer installed but the icons remain in the app drawer. Any ideas how to remove these apps completely?
I just disabled them in the settings
Uuuuuuuuu u
thx for all of your works man!
Dude, thanks now i can use my phone as its best :D
I half expected kit kat to do this to root. Thanks for a very informative post +Chainfire . hopefully something good will come from OEMs regarding this.
thanks for aour work and the infos
>>Since all mobile devices based on Android still have an 'Aeroplane mode' then it is the user that has the most permissions, you can always sever any network link.
Most devices (not only Android) do not switch off wireless connections in "airplane mode", they make them only inaccessible for apps. This behavior has been noticed even on Symbian 7 based devices. Some phones do not switch off the radio module even if users "switch off" them completely.
I love how so many people here are writing 'Thanks' and
a) have no idea what half of his post means
And/or
b) aren't even developers (of any sort)
In simple terms, what is chainfire saying?
Very interesting post, thanks
Locking down the os improves security. Locking out the owner but grant all access to manufactures decreases security. To me it looks like they are securing the ground I paid for. Google might follow another policy on their devices but they are part of the game (remember the changes on sd cards).
l'd hope that the Nexus line will keep their boot loader unlocked, if so, then bye bye Samsung hello (which ever manufacturer is building the nexus)
+Chainfire I hope you'll not give up though :) Thanks for all you've done so far!
The Mfg's will likely always be working with local govt to be sure that certain payloads can be pushed wirelessly via the cellular network. It would be best to understand that update interface since its likely not going away anytime soon. A personal IMSI catcher may be the next big thing to own? Also, the cell side of the device generally has a CPU that is independant of the OS and can therefor be put to use in subverting/sideloading the primary OS in its initial load/boot sequence. food for thought...
You're a brilliant man and I am glad you are still taking the time to not only discover how these releases change our access to the filesystems, but even take the time to explain to the community what we stand to face. We appreciate you and what you do here and may you forever be happy doing it.
Rooting and ROMs are what makes Android, I just rooted my Note 4 using your CF-auto on xda +Chainfire. I appreciate your work and hope you'll be able to continue it through the Lollipop updates.
....in other words.....nexus phones are going to sell like hot cakes
Thank you for your writing +Chainfire. I found xda and your tools when I tried to delete bloatware on my android phone. I hope in the future it will be
possible to get root in android, if not I don't know what to do, looking for an alternative (sailfish, ubuntu)?
You just made it on the XDA News page :)
On one hand i am happy to see this changes (I was root user, but since JB and KK i dont use it so much, so this is good news for user like me)
Thanks for your amazing work.
This happened for me in my Sony tablet S,
Unrootable. Its gonna be the undoing of Android. ?
This is going to be a huge problem for all of us that use or experiment with android phones. I hope manufacturers won't do the same as Google, or at least we'll have such great developers to help us get the most out of our devices.
Yes hoping this and in case it will not happen, hopefully there is another os for the phones (with root) at this time.
Am 22. Oktober 2014 20:21:56 MESZ, schrieb "Google+ (Dante Nemo)" <*@*>:
OK I do understand Google trying to lock the root access, cause if the root access is easy to be obtained, many users might get their services rooted without realizing what root really is. At this point some apps can cheat users saying something like "to better serve you I need the root access and I (don't) promise not to do bad things" and do evil things instead of serving you as described. Then people blame the system developer, which is definitely Google, for what they've lost.
So the hardship of getting the root access is somehow also kind of a filter of users. But anyway as long as rooting is still possible (which is theoretically possible forever), I'm going to get my device rooted.
Thank you +Chainfire, for the light of freedom on my device that you've brought.
I believe that android should have a root option, can be with disclaimer like : are you sure what are doing? We aren't responsible for consequences of root operations!
But I don't want a computer, which only let me be user not administrator and a phone is a computer. Without root I can't remove bloatware, administrate permissions, at least the phone isn't mine.
Am 23. Oktober 2014 02:28:59 MESZ, schrieb "Google+ (于笑晨)" <*@*>:
Beautiful explanation
+christian orjeda Yes I do agree the point that a phone is in fact a computer, and I would be happy to set MY phone having a root opinion so I can make my device much more powerful, but not everyone thinks in that way.
Basically up to now, only few people have root access on their phones and once all android devices have that option then EVERYONE has root access while they can give it to ANYTHING, and that causes severe problems. While there aren't many of the users have rooted devices, writing those cheating softwares don't get much profit, when the root opinion gives them a much more possibility to take control of ignorant users devices.One man's meat is another man's poison.
So maybe specialized ROMs for developers (and geeks like me) claiming what you've said might be a better solution, apps can't force you to flash another ROM while they might force users to click the root switch.
Having root as an option and with a warning would be OK. Like on a Linux system there you have to be root or su for doing more critical things. But not a system only giving you the rights of a very limited user, even not able deleting bloatware in many cases.
Am 23. Oktober 2014 07:58:00 MESZ, schrieb "Google+ (于笑晨)" <*@*>:
+christian orjeda But Linux itself doesn't have so many users but android does, so many users don't understand how powerful root access is. Just like those licenses, none of those guys read out care about the warning.
I don't want a system on a computer (phone) which don't give me the chance deleting things I don't want or motor having the possibility to quit some supercilious apps some permissions. If one put a clear warning before entering root mode one who is able to read should be also able to decide what he is doing. You can hide the rot access a little bit too, so one who want it will find and others not.
Am 23. Oktober 2014 12:47:46 MESZ, schrieb "Google+ (于笑晨)" <*@*>:
They should give you an option on 1st boot. Ie when you start it up for 1st time it asked if you want root or other extra access. It should require admin mode or sonething like that to allow root after 1st boot.
Does anyone know how lollipop handles sd cards
Thanks for the information Sir.
OK you have to choose Google slavery or little bit more freedom.
Am 23. Oktober 2014 19:26:27 MESZ, schrieb "Google+ (Emile Tenia)" <*@*>:
excellent info! i guess in the development world nothing is impossible, manufacturer world is totally different tho
Great description! Thanks!
+chainfire rules!(as usual)
Echt super
My question is still the same. Does this mean that its the end of Rooting and all the Custom Android development? It seems that Google is trying to increase their Nexus and Android One sales! Looks like we need to make a petition to Google to stop being evil and be developer friendly.
+Zahid Alaaudin Well, they havent restricted their bootloaders yet so
>> It seems that Google is trying to increase their Nexus and Android One sales!
After this change Android will quickly split into two (or more) different systems. One will be Android One and Nexus, the other(s) will be the OEM's version(s). And only first one will remain truly ANDROID.
Hola. Yo quiero saber como rootear mi note 3 soy nuevo en esto he estado leyendo terminologías pero bueno no es tan fácil. Y knox q pasa con el es bueno pero mmmmm no se por lo q he leído restringe más q proteger. Al fin y al cabo es nuestro terminal y podemos hacer lo que sea con el.
Quiero saber si ene la caso de rootear lo se podrá seguir ocupando la multiventana y más cos as q trae este fantástico equipo. Lo que deseo es quitar tanta cosa q trae pre instalada de telcel México sin el riesgo de que quede inservible. Invertí en el una hiena cantidad.
Gracias
+Andrei AndreaS Guitchev Not yet but OEM's(Maybe Samsung and some other non developer friendly companies) will see this as a golden opportunity to shut down root for good. I'm not really worried since I'm having a Bootloader Unlocked Moto G running CM11 and waiting for L.
Thanks Chainfire for the great article. How I wish I had a sliver of your knowledge.
This is why you should switch to a carrier who sells phones with an unlocked bootloader. T-Mobile
+SuperBROKEN81 But their plans are stupid. Plus pretty sure that they will lock the Bootloader if L has such protection coming
+Zahid Alaaudin t-mobile is known for unlocked bootloader. I doubt they would start locking them.
Then again when L hits I'll use mobile odin pro to flash and not upgrade the bootloader.
Of couse if they end up locking bootloaders future phones would be a problem.
Also t-mobile plans are good. Much better then Verizon. Cheaper, same service, with unlimited data.
Isn't it ironic how Google keeps android lollipop with massive SELinux features and at the same time they ask even what the names of your children are. Or I just don't know what security is.
+Chainfire You said "..it does require a modified kernel package (changing the ramdisk)" -> May this cause problems with file-observing on /system/priv-apps/? On my device (N7), changes to APKs inside that folder are no more detected until the device reboots. And I wonder if this might be related to the new root-method?
And what you say, means no root for the note 4, in the future..... I'm still in shock and not happy at all. I live for the root. Love root. Sucks bad, they are coming out with a developer version of the note 4 which will be rootable. Very yes. 700 bucks. To shell out even after we all bought the note 4 already. Sad times, why do they not want us to be able to root? I thought this was the awesome deal with Android. Jailbreaks with Apple, happen all the time. all the time. I still have faith because of that. Anyone?
Adios Root....Bye Root... Adeus Root....
Nice
Thanks Chain!
+An Orrible Monster I disagree a carrier app that is uninstallable that has permissions not even related to apk functionality that cannot be revoked without root accses is a definint personal data security breach
Help me..super su error
So very good and thanks for easy root in gadget... You must have predikat for your amazing briand
mass fino
Thanks mate.