phhusson / Superuser

Keeping koush's Superuser fresh
GNU General Public License v3.0
424 stars 50 forks source link

IDEA - SuperUser as permission #9

Open fonix232 opened 8 years ago

fonix232 commented 8 years ago

Seeing how CyanogenMod implemented SU as a permission into their own fork, would you not think that a better approach for SuperUser access in apps would be a system-wide controlled feature, via opt-in permissions?

Especially with the 6.0 permission system, I think it would be a lot more humane way of accessing superuser-reliant content (system providing access to files, filesystem, etc.) through system API calls (a la libsupersu), instead of starting own su processes. That way the system could still keep up granular access (allow-deny with remember option), while management would be in Settings-Applications-Permissions.

This would, of course, require a framework-level addition instead of a separate application, and my idea is more targeted towards the custom ROM sphere (and maybe even at manufacturers?).

lbdroid commented 8 years ago

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.

fonix232 commented 8 years ago

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 notifications@github.com 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 https://github.com/phhusson/Superuser/issues/9#issuecomment-151208023.

phhusson commented 8 years ago

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.

lbdroid commented 8 years ago

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).