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.
First things first
If you're a root app dev, I have updated the How-To SU guide with information regarding SELinux/SEAndoid, including some more details about this issue. libsuperuser example code has also been slightly updated. Link in the box below.
4.5 ?
Take that with a grain of salt. It may well end up being 4.4.3 or 5.0 or whatever. I just mean the next version of Android, and only if the current changes are not reverted (again!) before it's released.
The issue
A recent commit to the AOSP master tree prevents the unconfined domain (everything you run through su by default) from executing files located on the /data partition.
A lot of root apps (though by no means all of them) include binaries or scripts that they extract to their app-specific files or lib directory (located on the /data partition) and execute from there as root. This will no longer work out-of-the-box, and generate an access denied error.
Though there are certainly several ways around the issue for the affected apps, there doesn't seem to be a single generic solution that would work for all cases and can be implemented in the su command itself (though of course if you can come up with one, I'm all ears).
For now it appears that a fair share of root apps will need to be updated to work with Android '4.5'. As it has not actually been released, nothing is for sure yet, but work to bypass this issue in your favorite root app could start today. It may be prudent to inform your favorite root app authors of this potential problem.
Potential work-arounds (depending on what your app does) include extracting and running from memory or rootfs (mount namespace separation for the win), piping commands directly to su instead of writing to a .sh first (which was a bad practise anyway), forcing a context switch to a non-unconfined domain by way of su parameter or runcon, etc.
Testing
As the commits are readily available in AOSP master ( https://android-review.googlesource.com/#/c/74082/ and https://android-review.googlesource.com/#/c/78801/ ), if you have a recent Nexus device you can just compile AOSP, flash it to your device, and start playing with it. If SuperSU is your Superuser solution of choice, I would recommend updating it to v1.91 on the test device.
(Thanks to Justin Case and pulser for pointing out the commits to me)
Thank you for the heads up, and keep up the great work!
are beginning to make it more difficult?
Our luck is your knowledge, dedication and hard work.
Sharing with members of SGNB.
Thanks for the explanation +Chainfire
Waiting 1.91 in PlayStore ^^
Yes, and thank you +Chainfire for the great utilities.
Presumably this commit could be reverted in third-party ROMs.
+James Karaganis Sure, but keep in mind there's a metric fuckton more users running stock+root than custom ROMs ...
+Chainfire can apps that run in /system avoid this issue? Should devs start moving their apps to /system/app? Or could SU do it on install and on reflash system?
Chainfire thank you once again and I will notify the developer who created the SD Maid, [@Darken] which is a very useful application.
+Ronald Ammann it depends on what you are executing... if you use that su command inside the script to execute other files from /data, no, that will not work.
And how do you know these Info's ?? :P
Ioannis Tzon Tsolakidis because its public information
And before anyone freaks out, this is a GOOD thing. This increases the security of your phone, making it less likely malware or malicious people could take advantage of flaws.
+Chainfire do you consider this change a "bad" thing Google did? or rather encouraging developers to implement things better, or better security.
+Ran Sagy no one with any security sense is going to see this as bad. It is more about preventing something from gaining root, than messing with root applications. If someone already has root, they should be able to disable or work around this feature trivially.
This seems like a good change for the general population and +1 for CyanogenMod for the rest of us :)
+Ran Sagy ill put money on Cyanogenmod implementing this change as well
Yeah, for the sake of security, at the rate things are going, you will not be able to execute anything.
Even if not the case, It really looks like it a group of people at Google really really hate root, making it harder from version to version...
I imagine secret contests between developers: "what can we do in the next Android version to make the life of rooted developers harder?"
I can't wait for security to be so secure that rooting is not practical anymore and Chainfire give up out of desesperation...
+Michael Pujos everything in your comment, is just so wrong.
Have you ever written a root app and having to modify it to work with each Android update ?
My post was a bit sarcastic but even if Google doesn't renderer root harder on purpose, it is in Google interest that the less people possible root their device. Think how they must like how some root apps undo or modify what they thought on how you must use your system.
+Michael Pujos quite a few actually, including many root exploits. I am more than qualified to comment on this. I am also the one Chainfire points out in his last sentence.
Indeed, I had not seen that.
I'm in the case of having a root app executing stuff from /data..., so just a bit annoyed, that's all. Maybe that will be the occasion to put that app to rest.
+Michael Pujos This should be trivial to work around in most cases, if you already have root. This should only impact people writing exploits, and devs unwilling to evolve for the sake of user security.
+Michael Pujos link me to your app so i can see what it is actually doing, i think working around this will be trivial.
+Chainfire are you referring to this? http://source.android.com/devices/tech/security/dm-verity.html
https://play.google.com/store/apps/details?id=com.bubblesoft.android.gmusicfs
look a the shell script in res/raw
A clarifing question (I don't know much about selinux policy). Does this disable executing any binary on /data/ or "only" binaries which runs as root?
Losing this would make me rethink my love for android. To be honest security in its truest form is a myth. If someone wants to break it they will.
+Justin Case Gotcha, Thanks.
+Michael Pujos without looking yet (working atm), would it be possible to duplicate by just execute the commands directly?
Among other things the shell script triggers execution of an app provided binary. I suppose that copying the script + that binary somewhere on /system where they can be run could work.
Just an average user here so prepare yourselves for probably a stupid Question. A listener application that sits in the system partition and execute given commands wouldn't bypass those restrictions?
Why is Google locking Android more and more? Dont they get that the reason why it spread in the first place was freedom, unlike in ios? First airplane mode, then 2g/3g toggle, then battery stats, then... Sigh
Wait... The update took away root??? +Chainfire?
Hopefully these changes will only affect the "ASOP" version of Knox.
+Michael Pujos You could change the selinux policy itself, or pack your script/binary in an ext4 file system and possibly mount that somewhere else, like somewhere in the root FS?
+Roberto Fabrizi umm securing an OS is a good thing... it is kinda what is expected...
+Gerhard Schranz Knox is not in AOSP in any way shape or form, Knox is proprietary to Samsung
Huh... I fixed permissions in rom manager (CWM) and it came back...
+Justin Case you really belive that they removed the access to battery stats for security converns, rather than trying to hide the ridiculous wakelocks in the stock kernel and google services apps? Come on
+Justin Case app ops is freedom, freedom to use an app like facebook without having to accept its TOTAL access to every single permission of my phone. Greenify takes care of badly coded apps (like facebook itself) and prolongs my battery life. Wakelock Terminator does the same by stopping play services to spam me with NlpWakeLocks all day long. Xposed + GravityBox give me customization features without having to run a cooker rom. If anything, they should open these useful and definitely not risky features to the average user, rather than try to hide them even more to the superusers like us chatting here and following chainfire on g+
+Roberto Fabrizi are you drinking? Where did I ever mention battery stats? I am pretty sure I never spoke of battery stats, to anyone, ever, let alone here.
Apps Ops is a broken implementation that was never supposed to be be in any end user device. It can cause massive issues for developers, as well as users. It has the potential to break so much stuff, and causes many many false bug reports and crashes.
Xposed, while reaally neat, is also a broken implementation and a nightmare for security. Really don't know what I should point out about it, I mean it is just a major risk (but really neat concept).
You really just showed what lack of understanding you have here. App Ops and xposed are both "risky features", how can you suggest they are not? Please back your statement.
+Chainfire most people don't get the real Android experience with stock Rom, and I was one of them until I flashed CM
So any malware can still mount system and put binary there. Yet they just cripple regular root apps. Anyone else feel that root users/modders were useful while they helped to popularize Android but now they become a burden for Google?..
+GoodMoodDroid please explain how any malware can mount system
+Justin Case I know but it looks like that Google is planning to add such a feature to AOSP.
+Gerhard Schranz im not seeing evidence of that, can you link me to it?
+Justin Case Sorry I don't have any proof or something like that, it's an idea. SELinux is just an extension of the normal kernel and a feature like Knox (chained and more secure environment) would be nice AOSP :) crossing fingers
+Justin Case maybe you have been drinking, I definitely havent.
I said that they removed: programmatically turning on airplane mode (useful for night profiles etc applications, harmless), then 2g/3g toggle (same as before, tasker maybe? all non root apps, harmless), then battery stats (same as before, harmless, used by non root apps, actually an incredibly valuable debugging tool to find misbehaving apps).
You dragged into this all the bullshit about security and making the os more secure, which is the same laughable official excuse from google for having hidden battery stats, a security concern. Come on, noone can be so stupid to belive that. And even if it was true, why keep what the issue actually is a secred behind a private ticket?
About xposed... Personally I dont risk anything with it, I simply dont run with it code which hasnt been open sourced. I understand that not everyone is a developed, but Im a "my device, my choise" supporter, and companies know that freedom of choise sells, so they start with it, but have no remorse taking it away, see sony's joke with otherOS on ps3.
But the whole point was that if they want to secure android, they should make available what you can get only with root / xposed nowadays, not hide it even more. Hell my mom can barely surf the net with my tablet, and even she finds the quicktoggles stock implementation retarded and wishes she could change it.
+Gerhard Schranz SELinux isn't really like knox, vastly different.
+Roberto Fabrizi you are utterly unqualified to comment on any of this, based on your comments. My daughter makes a better argument on how she shouldn't have to take baths. With that, I will leave you in your misunderstandings.
+Justin Case That's right but you need SELinux and the policy for a Knox-like experience / features.
+Gerhard Schranz Knox encompasses so much, but when I hear Knox I think pseduo separate OS in a container. They certainly are using SELinux to make it more secure
+Justin Case Me too :) And that is hopefully the reason why AOSP got SELinux support. Just as super "revolutionary" business security container.
+Gerhard Schranz I think it got SELinux support to help spread it's usage in government and the business sectors (being the short short short reason why). I don't think we will see a container based system on aosp.
Most of these arguments against this (in the grand scheme of things) end up looking like kindergartner's arguing over who gets to sit next to the hot teacher in school. All trying to look important - but they fail miserably and just look like the kids they are.
Oh and I envision +Justin Case - http://goo.gl/ijbyO6
So it looks like simply copying and then executing a binary from /system/whatever would work around this...
Is this the best/"proper" way to do it though (in the context of sticking to the security principles that Google are trying to enforce with this change)?
Than i will stay on 4.4
+Justin Case I don't mean that malware without root can do it. I'm just saying that if you have root then this new change only hurts regular apps.
Cool info
I love watching people think they know more about this stuff than +Justin Case Amusing stuff here. I guess some of u haven't been on xda and have seen everything he has done for the root community.
:(
+GoodMoodDroid this should not be a problem for apps with root, unless a developer is being lazy.
One thing I'm finding it exceedingly difficult to find is, is SELinux policy loaded into the kernel as a single load (all or nothing), or can it be loaded incrementally (from several files/several system calls)? It would seem pretty easy if the latter, just load in additional policy making exceptions for some subset/subtree of /data, such as /data/supersubin .
The vast majority of the Web pages out there deal with writing the policy source files, and how to compile them and set up your system to use those modified files, nothing (that I've seen yet; I'm sure it's out there) about for example how the policy loading tools were written.
(light bulb just went on...use the source, Luke)
+Joe Philipps it looks like it can be loaded incrementally, and looks like new policies can be pushed via standalone OTA
I don't think this is a bad thing.
I really wish there was a more granular way to elevate privileges to apps...only allow them to do specifically prescribed actions, maybe even a limited number of times, instead of the blanket "hear ya go, do as you will" system we have right now. (Not a criticism of Chainfire or SuperSU, etc...its already hard to do what they do.) Not that such a system would be foolproof, but it certainly would be better.
What's the point with this move? Aren't nexus device supposed to be a Google way to collectively improve their OS? Why the hell they should lock root access to /data partition?
I just wanna hope that this is a secure method to denie access to people who aren't running a rooted OS or something easily avoidable.
+Klaas Madison The point of the move is to make the OS more secure.
This will not be an issue for people running open devices, or devices who have been rooted unless they want to make it an issue. It is possible to disable, or bypass once already rooted. This really is just an issue for those who want to write exploits, and barely an issue at that.
Time to move on to Ubuntu Touch
+Sinan Çetinkaya and when ubuntu touch matures on and becomes safer, more secure, where will you go next?
+Justin Case Canonical is not Google
+Sinan Çetinkaya ah so you mean Canonical is not going to mature their OS? Leave it buggy and insecure? Probably correct, one of the reasons I moved from their desktop implementations.
+Sinan Çetinkaya seriously? Ubuntu Touch is a pipe dream until they actually deliver something instead of constantly being in "reference" mode. Canonical has a history of over-promising and under-delivering.
The only areas where I see this fix and SE being any issue whatsoever, is with coding the initial exploits anyone may have to use (read: non-Nexus devices) to initially gain root. After you have root and the bootloader unlocked etc, it'll be a non issue.
+Matt Eskes BINGO ! You hit it on the head.
+Justin Case Are you working for Google? Half of the posts here are from you. You keep attacking people who don't like Google's move. I totally agree with +Roberto Fabrizi. I don't like the boundaries that Google bringing more and more with every Android update...
Overall, this code inclusion is smart, and I completely agree with it, from a security point of view. This update does more good than harm, and everyone here who's bickering and saying this is a bad move just doesn’t understand that once you have root, the above mentioned fix is moot.
+Sinan Çetinkaya I wish I worked for Google, but I don't. I do however know what the hell I'm talking about. I think most people shouldn't comment on technical things if they have no clue, or are not trying to learn but hey that is just me.
Personally, I welcome the addition. Considering Java is the insecure beast that it is, we need need all the help we can get locking it down.
Never quite understood the term 'secure OS" .Sounds.like an oxymoron
+Harrison Maina I don't see how you figure. Apparently you've never seen things like AIX or HP-UX. System's Security is a fine art between locking things down and keeping things unlocked just enough to where your end users aren't going to complain.
In all my Apps, I extract necessary binaries, scripts and assets to a Hidden folder in SD Card.. Will I have to change the way I'm doing it too?
+Chainfire thanks man
+Roberto Fabrizi you bring up batterystats.bin... You do know that that file gets deleted every time you plug your device in, right? An end user deleting that does absolutely nothing, and is absolutely unnecessary. There is not one reason why you should be even touching that file in the first place. Any "gain" you think you get from that is pure placebo.
+GoodMoodDroid you have absolutely no idea what you're talking about.
+Justin Case Btw, love your commercials. ;-)
+Matt Eskes, regarding "Personally, I welcome the addition. Considering Java is the insecure beast that it is, we need need all the help we can get locking it down. " I'm confused by this comment regarding Java security. I don't believe Java's security issues are particularly relevant to Android. Android is not using a JVM. Android doesn't use a Java security manager. Android VMs don't interpret Java bytecode.
I don't yet know enough to be for or against this update. If it does wind up breaking a ton of root-oriented apps, I'm against it. And on the flipside, if we're able to trivially work around it, then I'd like to know how it benefits security? If it simply means adding more hoops to jump through, then that would be a "increase in complexity of the security model without benefit." In my opinion, the more complex it is, the less secure it is.
In any case, this issue again points out that Google/AOSP developers need to recognize that there is a large community of users (tens of millions) who have root access. Their lack of interest in even so much as recognizing that is disturbing.
Point 1) You're right. Tell me again why Oracle sued Google over Android, if it's not Java? (It's based on Harmony)
Point 2) You're right, it doesn't run a Java VM, it runs Dalvik, soon to be ART.
Point 3) It doesn't run a Security Manager, but does that mean security should be a second thought?
Point 4) As has been repeatedly stated, these commits are not making the platform any more complex. It's not necessarily going to break root, per se. What it's doing, is extending SELinux support to a part of the filesystem it should be anyway, and disallowing any UID0 actions on /data, and if some current root apps break, oh well. We'll just have to deal with it.
Again, as has been stated in this thread, the only areas where this is going to make anything whatsoever more difficult, are the initial root exploits that we currently use to gain UID0. Once you have UID0, the point is moot.
While that may hamper what we want to do with them, explain to me how that is exactly a bad thing. It's not. These sorts of things are actually what Google should be concentrating on.
Again, while Android is most certainly open source, why shouldn't they be looking into ways and methods to secure the platform. I don't anyone here using their Distro of choice, (which are usually free) if it were holier than the Vatican.
The thing I don't like about Android is not the attempts to make it more secure, robust.
The thing I don't like is Google's stripping down the features we like such as airplane mode access, 2g/3g toggle(+Roberto Fabrizi already mentioned).
Everyday, Google is integrating more of its crap into Android.
You may keep Android and Google Apps apart but we users don't.
No matter which options I disable, the Google Play Services is still causing Location Access wakelocks(ended up with disabling its location access permissions using an xposed module).
Hangouts is a joke. Just showing online contacts took so long to be fixed, actually it's still sort of broken.
Although I disable wifi, Google enables it to find out my location, seriously wtf? I have to disable it too.
I do like the way of CyanogenMod, OmniRom. I'd use them if they were fully compatible with my Note2 (exynos crap).
i am getting a feeling that blocking root, as android matures is inevitable!
Considering that root was never really an intended feature, but more of a really nice side effect.. The point really is once we have root, everything is moot. Mundane details can be coded around.
Really, this is a non-issue and it's being blown waaaay out of purportion.
Funny, how we're having this discussion, with there being some on this thread opposed to Google's attempts at securing the platform.
May I submit this article for the neighsayers:
http://thedroidguy.com/2014/01/cisco-security-report-shows-android-targeted-99-malware-attacks-2013/
+Arne Schwabe Only binaries trying to execute UID0
+Matt Eskes im going to call bullshit on the article, but yeah its ridiculous that people are seriously upset. This is a GOOD thing, and is a non issue. Developers should have no problem working around it within minutes. My in house testing apps have already been modified, and should be ready to go.
+Matt Eskes Cisco's report on how "Android has the most web malware attacks" is merely a function of a tremendous number of sites trying to get you to download and install malicious APKs. That's not something I lose a lot of sleep worrying about. The only solution to that problem is locking down the device like an iPhone, where there's a single path to installation. To prevent this, you have to save stupid users from their own stupidity.
Most of that malware is just using non-root Android permissions that the user agreed to. A small percentage of it does use root exploits that are found on phones which are no longer supported by their manufacturers (that is...if only the users had a convenient and safe way of installing community-updated firmware, they'd be immune).
+Tod Liebeck I agree with that assessment. It's still a security risk, no matter how ignorant of the permissions the end user may be, but you're spot on.
For once it would be fun if an informational thread didn't turn into a bitch-fight between the overreacting underinformed and the underreacting overinformed ;)
+Matt Eskes Thanks for clarifying that for me. Now I can await 4.4+1 without fearing that it will break my app
+Chainfire you knew damn well this post would be bait for both the underinformed and the over opinionated, but correct, beautiful, sexy, smart developer.. So you don't get to complain.
And then lead to something as asinine as this - https://plus.google.com/+AdamOutler/posts/UC2w5veRcRG
+Chainfire you're a jackass, you know that? ;-)
No, +Matt Eskes - +Chainfire is a ROYAL jackass. Get it right. =)
Hah!
+Matt Eskes I had indeed been previously informed of this ...
Do you know how to edit imei on s4 gt i9505 without service box I didn't pay my phone bill now it's blacklisted :(
+Ioannis Tzon Tsolakidis i was wondering the same thing jaja
+Clinton Bowden this really isn't a discussion on how to spoof your imei. Guess you should have paid that bill...
+Matt Eskes well I was just wondering seems all of you seem to have tech knowledge I'm rooted all ready and have about 15 different programes from hex editor to efs pro but have no clue how to use them or even know if they can be used with standard usb cable or do I need uart cable what ever it's called lol . I have someone with x box but he charges 50 pound to do it so thought I would give it a whirl myself first :D
Honestly, I don't have a clue. I've never had to go low-level. I'm mainly a Linux kernel and security guy... That's beyond my pay grade. Sorry.
How about rooting haier w718 on Android 4.2.2 ?
I think downgrading firmware causes security problems and also modem problems like generic imei numbers as it messes with the security of the efs folder that the imei is located :(
What keeps rom devs from just reverting these changes is things like Cyanogenmod They did seem to do that when Google restricted system wide mounts (but only in 4.2).
Does cm want to stick to Google's code?
+Alex Ballmer Nothing. That's kind of the point of the whole discussion.
Oh, one more thing. Would setenforce 0 do anything for this problem, or is the restriction hardcoded?
Google should force Samsung and everybody else to pay more money on securing their products and releasing updates that fix exploits, so that they get released faster
and there should be something like su integrated into android by default but is deactivated normally and can only be deactivated through the bootloader/something which is normally write-protected and can only be changed if the device is connected to a pc
(or can these exploits bypass supersu, too?)
Just thinking...
Non-Root: Having a room in your own house, you can't leave. Just painting the walls and maybe some new interior. You suggest it is secure, but you know: There will ever be some people, having the skills to break in. Maybe less possible, but the risk isn't obsolete.
Root: Having your house in your hands. You can build rooms, paint walls, extend it to every side and secure it by yourself. You know, that securing every room isn't really possible - but with the systems you installed in the main hall, you can lock, watch & clean them if someone broke in.
So yes: No root means, that you're restricted in every case. I know, buying your apps @Chainfire never can be enough to thank you. But at least, it is a small thing you know, you're appreciated.
Thx
thank you!
Will this changes make impossible to gain root acces without unlock bootloader? I think eg about Sony devices - you can use exploit without unlock bootloader (some devices have locked by carrier fastboot so it's only way to gain root)
+patryk rajba This change should prevent the usage of exploits (for gain in security as malicious apps could do the same) and an unlocked bootloader alone won't bring you any root access
you will need a custom Rom which didn't apply this patch
It won't prevent them. It'll just make things a little more difficult to do for a little while...
О чем вы бля)))
+Chainfire Thank you. This was the first successful root of a droid Razr maxx hd with 9.30.1 that I've come across! Thanks
+Chainfire pls add support for note 3 n900 in all ur dvlpmnt so dt all indians cn enjoy ur softwares...v r getting n900 version only.....
How do I get kit kat 4.4 for my my m919 t-mobile and also m919n metropcs
Pls help me I can't see icon for supersu I think I go to the system and I chenge the icon pls I want to unroot my glaxy s4 but I need to open the lancher pls help my
+Adam Lamb 애미없는년 븅신
Updated to 1.91 from .90 and now can't run. Says no binary and cannot install it apparently. On Droid 4. What to do. The .90 runs ok and updates ok but then get the error message when I try to run 1.91.
+Krisztian Kovacs yes, they do. The current stock update enabled it. If you didn't take the update (read: if you were smart) there's nothing to worry about... If you did happen to take it; have with touchwiz. Don't try to downgrade, you'll brick your phone.
+Michael Pujos Wow, how'd I miss someone asking JCASE if he had ever worked on root apps? lol...
+Chainfire is NOT a Jackass! Well, most of the time he isn't anyway. ;-D
Thank you!! Knowledge is power. Keep up the good work!
hi do you know Arvin Raj Singh Gill... he owes me money and he is nw not replying to me. Tell him to give my money back ! he is a liar n cheater
+Beni Mahboob ?????
FOLLOW UP HERE - https://plus.google.com/+Chainfire/posts/ZtXAhw164QD