Shared publicly  - 
Superuser on 4.3

I finally had a chance to dig into seeing why Superuser is broken on Android 4.3.

Basically /system is mounted as nosuid to any zygote spawned process (ie, all Android apps). Root will still continue to work via adb shell, etc.

This is a pretty nasty change. It seems that SuperSU works around this by replacing to run a su daemon that pipes subsequent through it. Pretty hacky, but understandable why it was done this way.

Will need to look into how to do this in a less invasive fashion, if that is even possible. Of course, if building from source, this change can simply be reverted.
Zygote: remount /system nosuid/nodev Android no longer has any setuid / setgid programs accessible to zygote. Make sure /system is remounted nosuid and nodev for zygote spawned processes. We use mount namespaces to make sure these changes are only visible to zygote spawned processes.
Jay G. (Yeti)'s profile photoYik Sheng Lee's profile photoKyle Weller's profile photoChad Guidry's profile photo
Wow interesting, wonder why they felt the need to change that.
4.3 or Superuser? What a pickle you've put me in +Koushik Dutta. I hope you find a non-hacky way around it soon.
Don't revert the change; that's crazy talk.

Implement it right.  Let the device admin (i.e. the user) grant su rights to apps that need it, exactly like a desktop unix admin grants su rights by uid.  Write some known-legit UI for administering su rights like this as part of Cyanogenmod or whatever, and off you go.
To clarify no su at all or just no persistent su.
+Tadej Rudec - This has zero effect on adb backup/restore and Helium.  None of the framework's backup/restore infrastructure ever runs as root.
"Non rooted phones don't need this, as apps couldn't get root anyway"

This is less true than you imagine.
+Christopher Tate Yeah, we'll be implementing "su" correctly of course. But ultimately we want to get rid of root altogether, by just exposing the necessary permissions in the framework to do whatever is needed.
So, essentially, what they did is made it 10x harder for a malicious app to root a device and screw with it.
Paul W.
This is the equivalent of killing an ant by dropping the sun on it. There are obviously people that want ROOT, but as per the Google PTB, they'll set the bar at the dumbest of users.

It wasn't unexpected however, at IO one of the panel did state they were working to remove some of the freedom and choices previously granted to users and apps. 
Actually I'm not in a position to be able to speak about specifics here.  Talk to one of the Android security guys if you want more background.
Does su have to exist in /system? What if the binary was on another partition that was mounted with suid?

BTW, your su app (as a whole) is awesome... loving it much more than any other su app.
What if you make one?... Can you make ram disks? If you can, make a tiny one, mount it and copy su over, run it and you have an uncle named Bob.
+Paul W This has basically nothing to do with your root and choices, and everything to do with a security model that's demonstrably effective (SELinux).  Their call was essentially to roll out as complete an implementation of SELinux as they could, or seriously compromise it by leaving a backdoor for both rooters and malicious developers to exploit.

You do realize that's how root exploits exist, right?  They're called that for a reason, because they take advantage of security flaws to run non-approved code.  Android + Google Apps is a consumer platform, and tbqh it should run like one.  As mentioned up top, if you run Android base, build it/flash it how you like, and add gapps later, then you're still fine.  

But for Google to ship a product with known and frankly inexcusable security flaw so you can root?  That's absurd.  And before this becomes a "Google is becoming Apple" flamefest, if that "shift" involves better implementations of a security model, so be it.  

That model can be compatible with an extensible framework.  Root as we know it really shouldn't have to be a part of using Android, because it's generally there to correct for a deficiency-- the lack of a user-controllable method of safely executing various commands and apps at the correct permission level.  It's a hack.
Conceptually, I like the idea of getting rid of the need for root and instead creating framework for root-level permissions.

In practice, though:
1). Won't work for stock devices at all, only source-based Roms
2). Doesn't really leave room for arbitrary execution. Typical root actions can be predicted, but some root apps run their own commands. Could be hard to actually affect change without losing basic functionality.
I can't believe that some people are actually complaining that Google fixed a major security leak. Or at least made it a little harder to exploit the system.
If you want root just buy a device with an open boot loader and maybe ultimately force the manufacturers to leave the boot loader unlocked by simply don't buying the ones with a looked boot loader. 
Preparing for the inevitable petition for Google to leave root alone
Well, if we want root we can still hack around this, either by building a ROM from source without these restrictions, or by hacking around them...

I think we are missing an opportunity here: since this is going to break a lot of root apps anyways, this is a great chance to change the root "API" which is kind of funky anyways.

The current root API is simply to run /system/xbin/su as a process, write commands to its stdin, and read results from stdout and stderr. Problem is flow control and IO separation suck, and also nosy apps can check if a device is rooted just by looking for a specific file.

Now that a daemon is necessary, why not get rid of the /system/xbin/su shim, and have root apps communicate directly with the daemon though another method. If the method is correctly chosen, an app should have no way to tell the difference between a non-rooted device, and one where root access was denied.
Paul W.
+Christopher Lee Well articulated but you're missing the point. Of course security holes should be patched. In reality we're talking about a tiny subset of users that utilise such a security hole for "good". The problem here isn't so much about patching security bugs, it's about losing the functionality that goes along with said bugs.

Smartphones aren't appliances, they're personal computer devices. What privileges I as the administrator of my device should want to grant to third party software should be up to me as the administrator. And in closing such security holes, knowing in exactly which way they're being leveraged if/when at all, there should be a professional responsibility to provide a saner more secure method.

When forums' software was being hacked on due to its open nature, developers saw fit to provide hooks and further foster the users and their desire to have their forums reflect their wills and individuality. There is a prime example of doing things the right way.

I recently saw an article whereby advertisers were attacking Mozilla because of their recent stance on third party cookies and that's because we the end user are the product, one of the pieces of functionality that's hindered by such a move on the part of Google is adblocking. Why shouldn't I be in charge of my privacy? To add to that, why shouldn't I be allowed to browse the root directory of my phone? Or run shell scripts to provide me simple functionality like reading a periodical synopsis of my calendar thanks to Tasker?

Plugging security holes is fine, but that should happen while providing the ability to legitimately control the device as the administrator requires. Not saying that 90% of our users don't need it and so screw the other 10%.
+Paul W Granted, but I don't think I'm the one missing the point here.  As I noted, I don't have a problem with users being allowed to execute commands as administrator.  However, any such method that is not supported natively by the operating system in question is a security flaw, full stop.  We both seem to be in agreement on that point.

If anything, I believe it is the "device administrators" tool that should be leveraged to this end.  On an iOS device, or program like Secure Settings for Android, a user can toggle specific behaviors they want to allow on a per-app basis.  A similar such option, but geared along the lines of today's "Developer options" panel could allow device administrators hooked to a pseudo-su account the ability to run limited actions as root (for example, allowing file operations such as cp, mv, rm, etc.), changing the lock screen, and so on.

But as far as the 90% and 10% split goes, it boils down to basic economics.  The marginal revenue Google gains to leaving in existing exploits for the sake of the 10% is not worth the loss of real and potential customers due to perceived insecurities in Android, and the damage control that's been necessary to fight that perception.

Bottom line: until and unless root becomes built into the system, any root method that does not involve an unlocked bootloader and a manual flash is represents a security flaw that must be patched if Android is going to be taken seriously in years forward as a consumer platform.  You're right, your smartphone isn't just a phone anymore-- and that means that any fallout from it being compromised is going to be taken a lot more seriously than it would have been in years past.
In a perfect world, the answer would be defining additional access levels within the system, so that you could have partial "root" access or full access if the app needs it. I suppose though, that this would fall under core functionality to ensure it's secure, which means it would have to be proposed to aosp... and something tells me that would be a very uphill battle.
+Christopher Lee Not really... I'll explain my take on this in simple words.. Security flaw or not, Root mode is more than just a way of computing for some of us, it's God mode, that we absolutely can not live without. 

to quote you: "Root as we know it really shouldn't have to be a part of using Android, because it's generally there to correct for a deficiency-- the lack of a user-controllable method of safely executing various commands and apps at the correct permission level. "

quite in contrast, root is indeed a part of using android, and that 10% of people are the actual android supporters/fighters/well wishers/promoters. It is because of this 10% that the other 90% ever came into the android world. Google can upset the 90%, who don't even really care unless they get basic functionality, but the 10% are the ones you really need to keep happy. We are, proudly, that 10%.

 And there will never be an official user-controllable method of granting root, that will void the concept of warranty.If a user has root access, then they can modify system files, and they can thus screw their own device, with no fault of Google or Samsung or lg. so the OEMs aren't responsible for it and wont give warranty support! 

Besides, we don't root to correct a deficiency, if that's what Google thinks, they are wrong. We root to get extra features, flashy fancy stuff, to do things simply cuz we can, and the things we do, we don't expect it to be standard in android. Some things in fact, we would hate to see in standard android. But we still wanna do it, cuz we are the power users, who like to have complete control over their devices. And these are nexus devices remember ? they are supposed to be developer friendly. ROOT IS the biggest developer driven sector, it enables even the normal user to understand how the phone works, that the whole spirit behind XDA. The whole HUGE XDA community is made on this basic principle, that root is good, it's great, and we love android for root, for the flexibility that no other OS in the world can have. 

As for security flaw, since Google has patched a way to get root, they should provide another sophisticated way. We need a way to have that same complete control, and there cant be an official way, cuz it'll void the concept of warranty, and anyone who cant read can grant root to an app to get a feature to his stock new shiny phone. THAT will raise security concerns. If there are people out there who willingly sacrifice warranty to get root, going through the pain of rooting, what's Google's problem ? Please, don't mess with root Google. We want root. We love android = We love root. 

P.S. sorry for the super long post, was in a frenzy, thanx for reading it fully if u did. :P I forgive you if u didn't. 
+Harsh Doshi No, I read it.  It wasn't particularly long.  And unfortunately, I don't think it's very convincing either.  Here's why.

Android is a consumer product.  So is the modern PC.  Once upon a time, the market was covered only by users with the time, money, and skill level to navigate what were then-primitive devices.  Deep level access was a must to make up for deficiencies and early technology.  Fast forward about a decade.  The market has exploded, and millions of consumers with almost no technical experience are buying more computers, all the time.

As for the original power users?  Or even the new ones?  The ones who can't live without full access?  They're still there.  They still buy computers.  _But they are no longer relevant to corporate strategy._  

The continuing belief that ROM developers are somehow key to Android's future success is grandstanding.  Look, I get it, you get it, they were early advocates for a new operating system.  But the market does not care.  Android has matured and it is now enough of a market force that people will buy Android because that's what their friend has, technical or not.

The 10% here are a vocal minority.  It happens all the time.  And you know what?  Companies don't really pay attention, because to the vast majority of the market, the company can keep doing whatever it wants and users will play along.

Until we get to security.  Full stop.  Security flaws scare people away.  It creates major problems for companies that need to advertise that their product won't get your ID stolen, rather than money that could go towards more hype.  And most importantly, security issues tend to get you into liability problems.

So no, Google really shouldn't be leaving "more sophisticated methods of getting root", because they still pose security flaws that are exploitable against design.  There may be changes to device administrative roles that let us get the kind of access we want, but the bottom line is with the exception of developer handsets, root is a security vulnerability that is becoming increasingly unacceptable as mobile malware begins to gain traction.

Many people who are rooted are likely people who had their device rooted by someone else to do a cool trick.  They don't know the risks, they don't even know how it works.  But that shiny new thing can bite you in the ass if it relies on something that isn't supposed to be there.

Bottom line.  XDA and other developer communities are huge.  The market is bigger, and has moved on.  More and more people are content to leave their handsets as is, and as the audience grows, security and stability, not extensibility, become prime motives.  Full stop.
+Christopher Lee You seem to be conflating two separate things. No one is arguing against the importance of patching vulnerabilities used to gain root access. These vulnerabilities may frequently be exploited by malicious applications in order to escalate privileges and perform unauthorized actions on user devices.

However, that doesn't mean that the mere presence of the ability to legitimately gain administrative privileges on an Android device is itself a vulnerability. It's just not. If you need further convincing, I suggest you request a CVE identifier for every major non-mobile consumer operating system in existence. Windows users can gain administrative privileges by overriding UAC. Linux users can use sudo or su, provided they have authorization. The key here is that there needs to be a mechanism in place to prevent unauthorized code from leveraging root access to perform malicious actions, which every sane implementation of su/Superuser on Android has always had: prompts are presented to the user whenever an application requests root privileges.

That's not to say that granting administrative-type privileges at a finer granularity via exposing them through the Android framework wouldn't be better, or that having a rooted device doesn't present additional attack surface, but calling the existence of legitimate root access a vulnerability is an exaggeration.

This new feature implemented in Android 4.3, which remounts the /system partition with the NOSUID flag inside a private mount namespace for each Zygote-spawned process, creates an easily circumvented annoyance for having a setup that allows you to grant root privileges to authorized applications, while doing absolutely nothing to prevent exploitable vulnerabilities that allow malicious applications to gain unauthorized root access on the average consumer's device.
+Dan Rosenberg Not at all.  If you look up top, I wrote that the presence of an exploit used to obtain root is in poor form.  I never wrote that obtaining root via a more condoned method (a.k.a. the standard bootloader unlock and recovery flash) is bad, because that's a user's prerogative. 

The problem lies mainly in how you go about obtaining said root.  Many people (for convenience) would rather use an exploit like motochopper or zergrush because you don't have to go through the system reset.  If you can "turn on" root so to speak without compromising the underlying system, then sure!  Superuser gateways, the best-practice use of sudo, UAC, and so on are all a good way of implementing this.

To finish addressing the first part of your post: I simply think you misread my posts if you believe that I am somehow against root.  I've pretty consistently maintained that if you're not using an exploit that you're in the clear, although a built-in alternative would be better.

To the second part: to my understanding, the current additions into Android 4.3 are somewhat incomplete, and I would be surprised if we didn't see it become a little more useful (if annoying) later on.  However, I'm willing to accept it as essentially transitional code for further interior changes (or perhaps just an increase in the level of SELinux enforcement from, well, audit).
+Christopher Lee Sounds like we're in agreement and I need to work on my reading comprehension. To be fair, holy walls of text.
Root access isn't needed to run other roms, or use some of the mods people want.

Root access is required to perform some of the tasks required to set up most of those things, and that's it.

And, root access is only needed because the files are otherwise locked, to prevent rogue apps or other processes from breaking them.

I think that some people have a big misconception of what root even is... and to be honest, Linux has a rather barbarian permissions system which is what gave rise to selinux and the use of acl's.
+Dan Rosenberg Not a problem, it's just been one of those threads.

+Eli Sand It's only crazy if you're choosing to use SELinux or a stict MAC scheme.  AppArmor is pretty good about not being in your face all the time.
+Christopher Lee I meant barbarian in the sense of useless and simplistic. You really can't do much with just rwx and ugo.
+Eli Sand I am clearly not the only one who can't read today.  I thought you said barbaric for some reason.
So if it's just related to how it mounts the partitions, I'm assuming people could make a kernel that removes the nosuid flag when mounting system and that sort of patches the issue? That could be the solution for stock devices.
+Mark Kennard I don't think that would work because, as far as I understand it, the change was made to the dalvik vm and not the kernel.  Any time the zygote is cloned it remounts the /system mount for that process with the flag set.  So you would need to swap out the dalvik vm to avoid this process.  I have never done or heard of anyone doing this, so I cannot say whether it can be done on a stock rom, but my guess is that it would not work well since we most likely don't have access to the original source.
Does it strike anyone else as odd that in the initZygote function that was modified for this change, it will bail out with a -1 and not do the remount if getMountsDevDir doesn’t return a path after reading the mounts?  The point that I find odd is that the function is intended to return a bool rather than an integer and I would suspect -1 to resolve to true.  This would ultimately allow the execution to continue in the calling function, as if the new code did not exist.

Though I find this odd I don’t see it as a viable exploit since one would have to gain access to the process’s “mounts” file and modify it in a way that would block the finding of the path, during the zygotes initialization flow.
They write about this change in the What's new Section of Android 4.3.
+Christopher Lee Alright, i thought you misunderstood me too. (reading ur other posts) I'm not saying that gaining root through exploits is right, i frankly was scared of exploits, imagine an app you install can gain temp root access and do all kinda nasty things to your system when u were actually on stock ROM and unrooted ! 

I misunderstood that you meant 'root' was bad and the main problem. Legitimate means of gaining root like unlocking bootloader, having been fairly warned beforehand, and then flashing a recover, etc. is the way to go, i think we both agree to that. But, yeah, root is necessary. 

And about how companies wouldn't care about that 10%, well, i must say, that wont be the case with google/android. Android itself solely exists on the basic principle of Open Source, and thus no mater what, those 10% should be the primary target, and they still are, and will always be, maybe they will increase the 10% to 20%. And they can always have a separate version of devices (like the nexus) or a separate operation model for the 10%. Like it is now ! Normally, on android, much like any other OS, you are locked down and restricted. No root access, no system access, you have to grant an app all the permissions it asks or none at all, and simply not install. (maybe App ops is changing that ?). HOWEVER, if you are a power user, and u need complete access, well, who's to stop you from doing what you want with your phone bought with your money ? By all means, go ahead, we'll just issue warning, and standard warnings that say that u loose warranty, you are solely responsible, yada yada yada...

But, there should only be one secure process and way to gain root, no other exploit should work, no malicious app should be able to gain low level access to anything. THATS how it should work, how it is even on the nexus devices. and after getting root, every time an app wants root, u must be asked for granting the permission, and they get root only if you allow them to, so it's all on you. A stupid person, by all means, should be warned. 
+Harsh Doshi We're back to economics again, where open source ideals unfortunately slam into a brick wall.  Look, it's not a case of "that won't be the case with google/android".  That ship has already sailed.  It sailed one or two years ago, really.

Here's the deal with open source software.  It's great stuff.  Anyone can change it.  No one can tell you what to do with it.  But there's a "problem" with this situation, in the sense that any one developer can essentially do whatever they want with that code, and there's no mechanism for anyone else to hold them back.  Nor should there be.  That's the nature of open source.

So what am I driving at?  It's pretty simple, really.  Android may be an open-source project, but it's the Google app platform that makes Android sell.  Google will still commit its changes back to AOSP from time to time, but its very-proprietary system is the rainmaker.

And here's the thing: they don't have to care what anyone else does with Android.  It's not like someone could say, "hey Google, listen to me, or I'll sabotage AOSP/stop committing."  Google picks and chooses what it wants and runs with it.

You're projecting your morals and ideals onto a company, big time.  Google, as a public corporation is going to pursue profit above all other things.  They'll make entreaties to developers when it suits them, but if you think that they'll be beholden to Android developers (as opposed to app developers), then you're head is in the clouds.

I'm not going to talk about what power users should be able to do, because we both seem to be in agreement as to how and why root access should be available, but also because it's not relevant.  The bottom line is, and always has been in this discussion that as a consumer product, Google Android will focus on what brings the best profit with the least liability.
ahh. i'm not gonna argue any further. I get your point, and arguing further may vreate more misunderstandings.. but we can always bank upon google to do the right thing.. im not saying SELinux is bad, or that this new implementation of root is flawed (it is actually, for now, just makes root harder but still possible). They should just fix the exploits, which every manufacturer have done in the past and will keep doing.. 
Add a comment...