[Sprint Samsung Galaxy S 4 General] GiantJay:
Just curious who saw these posts on Google+ the other day. Lets discuss.

Steve Kondik - 22 hours ago

The Death of Root

Android 4.3 introduces some new and much needed security features which not only restrict setuid binaries on the system partition (su), but also limit the capabilities of processes. In the current architecture, even if you could get elevated privileges, you can't do anything out of the ordinary. Root in the shell via ADB is all I use, and it still works just fine.

This isn't a problem for me, since I use CM. When there is a situation that I'd need root, I just modify the system to accomodate what I'm trying to accomplish in a secure way. I can understand the desire to have full root on stock ROMs, since you're severely limited in what you can do and there is no provision for making any sort of real changes or improving the architecture.

+Koushik Dutta and +Chainfire are working hard to permit root in some way on 4.3, but I feel that anything done at this point might severely compromise the security of the system and we should start considering better options. Going forward, I'm interested in building framework extensions and APIs into CM to continue to abolish the root requirement.

A few good use cases for root are:

* Firewalls and network software, potentially requiring raw sockets.

* Managing the DNS resolver

* Tweaking various sysfs nodes to control the kernel

All of these can be done without exposing root, and they can be done in a very secure way.

If you're using CM or another custom ROM, what do you actually use root for?

Brought to you by Sprint and the letters GS and the number 4

Steve Kondik - 21 hours ago

An example to go with my previous post on root..

Let's say that I wanted to write an application that would let me block or rate limit network access for other applications. Seems easy, just run "iptables" as root and add some firewall rules. Calling "su iptables ...." and managing the list is easy. The harder, but much better way would be to extend the framework. This also has the side effect of opening this up for other developers to use.

To do this, you need two things:

1. A way to add the rules (which requires root)

2. An API to add the rules

3. Access control to this API

All Android systems run a daemon, "netd", which runs as root and manages various aspects of the network such as tethering and traffic shaping. The framework has a service, appropriately named "NetworkManagementService" which communicates with netd using a simple protocol over a socket. Applications with the right permissions can get a handle to this service using Binder, and control the network without actually needing root.

So to build a firewall API, it's really easy. You put the pieces that require elevated privileges into netd, then add a few methods to the NMS such as "addRule", "deleteRule", and "listRules". You can create and enforce a new permission, "android.permission.MODIFY_FIREWALL_STATE" that applications would require. You can even pop up a "scary" dialog similar to the newish VPNService when something needs it.

Then of course you upload your patches to the CM Gerrit, we iterate a bit, and ship it. If it turns out to be insanely useful, maybe it will go to Android proper.

Now you can write your app and a whole new class of applications that you couldn't do without using the root sledgehammer before. Yeah, it's harder, and you need to learn the system architecture a bit, but the result is much better and more importantly it's not a gaping security hole.

Of course it's possible to write malware that mirrors all of your packets to a remote site without your knowledge using this API, but Android's VPNService is actually more suited to this and it's already part of the framework :)

I might be exploiting this as an opportunity to sell the ideas behind CM, but I think it's a powerful concept. If your app needs to do something that normally can't be done, you can easily bend the system to your will and do it right.