November 28, 2014

Superuser on Android 4.3 gets sketchy


According to a recent post by Koushik Dutta, aka – Koush, on Google+, there are some issues with the Superuser functionality in Android 4.3. According to Koush:

“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.”

What do you think of this change? Let us know in the comments.

  • Mickey

    What exactly does this mean? I am currently using SuperSU on my new Nexus 7 with stock 4.3 and it seems to be functioning fine. Is this an issue with only Koush’s Superuser?

    • Walkop

      It’s a security change with 4.3. Basically, it’s harder to attain proper root access at all; the way used now is just trying to circumvent the change, although it’s fairly hack-y in the process.

  • insink71

    Basically Android 4.3 institutes selinux. If you’re not familiar with selinux, its basically something the NSA released back to the linux community to improve security/close security holes. I agree with this OP’s title. Now programs [or apks if you prefer] are effectively sandboxed and dan’t talk to one another. So chainfire [and probably koush] have started a su daemon.. then allowed apks to request permission(s) via IPC routing. Problem is, this effectively breaks the sandbox [and leaves ppl’s devices as insecure as pre-4.3]. I’m not against a su daemon and IPC routing, but I’d love it if that su damon managed permissions and only assigned what was needed; I’d love it if the master [true su process] was password protected at the least or better yet security keyed with a TPM system. These things though are complicated, and as long as one [or many] choose convenience over security, there will most likely be a hackable scenario. Just as safe with better security, just rewrite the selinux security policy ;) it is open source; so, anyone can build a policy that gives them both some security and some convenience.