IDEA - SuperUser as permission about superuser HOT 4 OPEN

I think you are actually mixing two ideas together;

First being assigning root access as a permission, which was tried and failed, since nobody ever actually bothered to build that permission request into their applications in order to use. It will never work since none of the groups building root control software are able to get along with each other. I will admit that it was a noble idea though.

The second, which is what CM has done, is to just integrate the root authentication application into the permissions UI. It isn't actually handled as a system wide permission, they are just hijacking the the interface to make it look like it is.

Regardless, this really isn't a high priority, since (a) it doesn't provide any additional security, (b) it can only be implemented as part of a full system build, which isn't our first priority. Our first priority is "light" modifications, that can actually involve an system image that is fully factory.

If you feel like contributing, feel free to write up a patch against the AOSP permissions UI that adds this feature independently of the application. The "meat" of this project is still in the su program itself, and not in the authentication UI.

from superuser.

Of course. My idea was not about the core of the app (except for the
"accessing via native Java calls instead of calling into the su binary and
initiating a separate root user shell process"), but about implementing
access to the end user.

And I agree, developers won't implement it. They are lazy (including
myself). If something works, why change it, even if there's a better
solution. Unless they are forced to do so, they will NOT implement a new
way to access root (however safe it would be), and they will not work with
the root control builders.

But if say, CM was to adapt a "root" permission, where the user is
arbitrarily asked for allowing the app root access (with proper warnings,
etc.), then I can see it working. Most of the custom ROM installs is still
CM, mostly for their large device support base, short adaptation timeframe,
and they are the de facto standard for ROM building (meaning if you have a
device tree that works with CM, you're pretty much 90% done for all custom
ROMs, except a few little patches here and there). If they were to adopt
such a patch (mainly because it would work nicely together with 6.0), most
of the devs would be forced to adapt to it at least partially.

And it would actually be safer. We could get around the nasty hacks e.g.
SuperSU employs to achieve root with strict SEAndroid policies in place. A
permission, user-controlled at that, could circumvent this, and allow only
one root shell, with access only to apps that have requested successfully
that permission (and permission must be requested from active UI thread, so
no hidden background requests, window should contain app name, not activity
label, and so on).

On 26 October 2015 at 17:56, lbdroid [email protected] wrote:

I think you are actually mixing two ideas together;

First being assigning root access as a permission, which was tried and
failed, since nobody ever actually bothered to build that permission
request into their applications in order to use. It will never work since
none of the groups building root control software are able to get along
with each other. I will admit that it was a noble idea though.

The second, which is what CM has done, is to just integrate the root
authentication application into the permissions UI. It isn't actually
handled as a system wide permission, they are just hijacking the the
interface to make it look like it is.

Regardless, this really isn't a high priority, since (a) it doesn't
provide any additional security, (b) it can only be implemented as part of
a full system build, which isn't our first priority. Our first priority is
"light" modifications, that can actually involve an system image that is
fully factory.

If you feel like contributing, feel free to write up a patch against the
AOSP permissions UI that adds this feature independently of the
application. The "meat" of this project is still in the su program itself,
and not in the authentication UI.

—
Reply to this email directly or view it on GitHub
#9 (comment).

from superuser.

I let lbdroid answer on the permission question (I don't know enough the rom community to answer), though having a system permission won't change stuff much about SELinux (@lbdroid we could use permission this to disable NO_NEW_PRIVS for apps asking for root, but I don't like the idea).

As for java calls, the aim is to be compatible with ChainFire's libsupersu, which is a nice, open-source library to handle those problems.

from superuser.

fonix232:

Custom "rom" installs are a tiny fraction of "root", which is a tiny fraction of all Android users. Not a big enough target to worry about.

But besides that, I'm not really sure what you are asking. We already implement a permission mechanism. Its just not explicitly requested in the manifest, but rather on-demand as it is actually used. Remind you of anything, like maybe the android 6 permissions model?

Further, we have already moved well beyond the supersu hacks. Our sepolicy IS locked down, enforcing across the board (theirs puts lots of domains into permissive, and you at the mercy of whatever software you have installed), and even blocks any and all policy reloading and disabling of selinux (which theirs allows, which makes it possible for ANY root application to disable selinux altogether).

On top of that, the request authorization window DOES include the application name (though it should also include the full package name, like it is in the logs). Notifications and toasts that appear for "remembered" authorizations do as well. Every request, whether it is allowed or denied, is logged. One thing that would be nice to add to the logging, is a complete transcript of the root session. Or at least the sending channel.

NOTHING gets root access unless the user has specifically authorized it.

In addition, I would like to eventually break authorizations down on a command-by-command basis, and block the ability to remember authorizations for conventional su, since it is just crazy to grant ANYTHING that kind of permission.

phhusson: I don't think an Android permission would be much use for that, since the permission is meaningless until after Android is already running -- too late to implement it. It would also require modifications internal to zygote/app_process. The permission model he is referring to is actually for controlling data requests between Android applications. I.e., application A is a provider for data of type X, defines in its manifest a permission for accessing data type X. If application B wants to obtain data type X from application A, it has to declare in its manifest the intention to use that data type, by requesting the permission. It really doesn't apply to us at all, since we are working at the linux terminal level. So even if we wanted to use a permission model for turning off NO_NEW_PRIVS, we would have to implement it at a lower level than Android permissions.

Even when you take the permission model down another step into what "was" implemented in supersu/etc., when application B asks for root, it obviously still must be via the 'su' command. When Supersu received the request, it would just check the manifest of B to see if it was requesting the su permission, and automatically deny it no matter what if it wasn't. So all it could do was try to guess if it was appropriate to automatically deny. If an application requested the permission, it still wouldn't be appropriate to automatically approve, which means that you haven't actually gained anything except to avoid the annoyance of being asked (with the side-effect of likely breakage and no indication of why).

from superuser.