New methods and security models have changed the way superuser permissions are handled in Android 4.3
You’ve probably heard some chatter about root and the latest version of Android, and maybe even heard things like “the death of root” being thrown around. Things have changed, and new security features in Android now limit what processes with superuser privileges can do on the system partition. I’ll try to explain some of this as best as I can without throwing around too many words nobody (well, almost nobody) will understand. Some of it’s unavoidable, though.
You might need to pour a stiff one for this.
All Android apps fork from a system process known as zygote. In Android 4.3, things were changed and now zygote has a new security policy. Even though we can fork a process with suid (superuser) privileges, the new restrictions limit what we can do with it. This is the entire point of SELinux, which is a good thing for user security. Our new process (think of it as the root app you’re trying to run) technically has root access, but it can’t actually do anything useful with it. This is a very good way to protect the system from rogue processes that you don’t want — as in potential ZOMGMALWARE — to have access to everything.
There are two ways being talked about to work around this new set of security policies. One is that root access through the shell — where you’ve connected your phone to a computer and use the command line to communicate — still works fine. You can elevate your user status, and do the same things you could always do through adb. And chances are pretty slim that’ll not happen without you knowing it.
The other way is with a su daemon.
A daemon is a background process that isn’t under direct control of the active user. It runs quietly, waiting for the time it’s needed to do something useful. When it’s called, it does what it was designed to do, then goes back into hiding. An su daemon needs to be invoked during the system initialization, which becomes a sticking point for hacking root access into “stock” ROMs.
The Android implementation shipping with [the] Nexus doesn’t look for additional policies in /data/system/sepolicy like the CyanogenMod and upstream indicate it should. It loads the /sepolicy file from ramdisk and calls it a day.
You need — at a minimum — a modified boot image to start a custom daemon on your Android device. That’s not a problem with something like CyanogenMod, but that means that you’re flashing something other than stock to make it happen. Flashing custom images, kernels and ROMs is something that a lot of people just don’t want to do.
So that’s where we are. The biggest names in the Android community are hard at work to get things all sorted, but there’s a very good chance that root, the way you know root today, will require you to flash custom firmware above and beyond the SU app and binary. It’s a good thing that Android is moving to a more secure security model, and you’ll just have to learn a little more about how your system works and how to modify it to get it in the condition you want — which in the end is another good thing.
Google knows users want things like superuser permissions. There’s a very good chance it will address these issues somehow, either by requiring root for less things or by building a solution into Android itself. If you run Linux or OSX on your computer, you know that having a home folder lets you do most things without elevating any permissions. Maybe Google will move towards this direction. Or maybe they will add superuser functions into Android in the developer options. In the meantime, they will continue to make completely unlockable Nexus phone for users who want or need to flash custom firmware — and folks like the developers at CyanogenMod (and elsewhere) will continue to build it.