One question about AppOps and superuser permissions.
I have browsed the CyanogenMode Lollipop code and seen that the superuser permission is enforced through the AppOpsManager. (see system/extras/su/... )
This is very nice and integrates well with the other permissions management.
IMO, one thing is missing, i.e. the proper hiding the superuser executable from inspection from apps.
I noticed in the code that the permission to handle some special files is also handled through AppOpsManager.
It would be very useful if all requests to see if the superuser executable (/system/xbin/su or /system/bin/su) is present were filtered in the same way by asking the AppOpsManager if the SUPERUSER permission is allowed for the requesting app.
This (I think) would completely hide from non-allowed apps the presence of rooting.
Unfortunately I am not (yet) good enough with the system code to change it, thus it would be nice if some better developer could help doing this change.
Or perhaps this change is already available as a gerrit cherry-pick? Then it would be very nice if you could point it to me.
Related
Hi,
I have the app "superuser permissions" on my rooted Dell Streak.
Some apps request superuser permission and when they request, I can add them to the allowed apps list.
But some apps do not request permission.
How can I add superuser permission to those apps ?
For example, there is a web server named PAW. I want to run it on port 80 which requires root.
However, I can't add that to the list...
Also, some file managers do not request permission. How can I make them root ?
Hi mrmrmrmr
Well if an app doesn't request superuser permissions obviously it means it doesn't have that functionality in it so you can't just add it to it just by granting it permission it just doesn't work like that.
Again with File Managers they need to be written to need Root access and be granted permission you can't just grant them access as again thats just not how it works take Astro a great file manager but it doesn't have root access because it's not designed to do that. If you want a File manger with Root access that will on first use request superuser permission you need to look at Root Explorer that will do what you want as thats what it has been built to do.
But i would advise exercising extreme caution when doing anything with Root access as changing or deleting something without understanding exactly what you are doing can have seriously bad consequences. Seeing as you have asked these two questions i would really question if you should go messing around in Root unless you are really sure you know what you are doing or able or prepared to fix any mistakes you may make.
Marc
thank you for the clarifying post and the warnings.
well, actually being a user of Linux based OSs for more than 15 years, I know what "root" user is and what it can do.
I just didn't know how Android applications gain root access. (Thought they would all use it if somehow they were granted)
Now, for the filemanager , I'll install root explorer as you recommend.
But for the PAW webserver:
This application is listening on port 8080 by default.
For listeningon port 80 , it says it needs root access on the documentation.
But I couldn't find how to give root access.
Any idea ?
@mrmrmrmr
Well it sounds like you have a far better and greater knowledge and understanding then i do as prior to Android i have had no exposure to a Linux based OS. Although i believe Android is slightly different but sorry but i have no idea about the Web sever stuff as thats just not my thing at all and wouldn't know where to even start with it.
Marc
thank you Dogmann.
anyone else whou could give an idea ?
I tried the PAW webserver, and it didn't work for me either when i set it to port 80 - even though I have root access. I would suggest sending the developer an email, because that functionality is obviously broken.
An alternative would be to get iptables working (it's not installed on my device!) and run:
iptables -t nat -I PREROUTING --dport 8080 -m
state --state NEW -p tcp --sync -j DNAT --to
127.0.0.1:80
(got that from google: http://www.google.com/search?q=local+port+forwarding)
Dogmann said:
Hi mrmrmrmr
Well if an app doesn't request superuser permissions obviously it means it doesn't have that functionality in it so you can't just add it to it just by granting it permission it just doesn't work like that.
Again with File Managers they need to be written to need Root access and be granted permission you can't just grant them access as again thats just not how it works take Astro a great file manager but it doesn't have root access because it's not designed to do that. If you want a File manger with Root access that will on first use request superuser permission you need to look at Root Explorer that will do what you want as thats what it has been built to do.
But i would advise exercising extreme caution when doing anything with Root access as changing or deleting something without understanding exactly what you are doing can have seriously bad consequences. Seeing as you have asked these two questions i would really question if you should go messing around in Root unless you are really sure you know what you are doing or able or prepared to fix any mistakes you may make.
Marc
Click to expand...
Click to collapse
thank you thank you thank you and again tanks thanks thanks
what if you want to add ROM Manager or grant permission to it but ROM Manager won't ask for the permission?
ROM Manager doesn't currently work on the Streak. This might explain it not asking for permissions.
I have the same problem!
When I typed "updatebb" in emulator, it said "permisson denied". But the emulator didn't ask the permisson! So how can I give permission to it?
Mods, in case this is the wrong forum for this kind of discussion, feel free to move it. I'm a newbie here and the rules are always a bit ambiguous until you get a feel for how that particular community interprets them.
The problem I'm having is this: My phone is rooted and I've written a short application that moves the apk of another application to the SD, replacing it with a dummy file that in turn launches my application.
Moving the data to the SD isn't a problem and neither is moving it back, but informing the OS that it has been moved back is a different matter, as the particular broadcast message needed to inform other applications of the availability is protected by a UID check which will only allow root or system to proceed. While I can spawn a root shell, I haven't found a way to make this shell interact with the Android system, so the broadcast comes from my application which has a non-system UID and is therefoe denied.
I know I could sign my application with the system keys and add it to the shared system UID group, but let's be honest: that's more trouble than it's worth and would require me to re-sign all system applications on any device where I want my little app to run.
So I need a few API calls executed by an application that is already owned by a system user; a mediator which listens for requests from unprivileged applications and, after a user prompt, executes them in its own context.
I'm quite willing to write such a mediator service myself, but I don't want to duplicate work that's already being done... does anybody else know about
a) methods that would make such a mediator unnecessary
b) existing mediator services available on custom ROMs?
Update:
Right now I'm digging through the app_process source code, as it interfaces with the Android runtime from C++, which might allow for executing Android code under the UID of a Linux binary...
I'm creating a custom Android build (based on AOSP 4.0.1) and I need to be able to programatically enable and disable NFC from an app. After a little trial and error, I realized that the app would require the WRITE_SECURE_SETTINGS permissions, which is never given by Android to any non-system app. Installing the app as a system-app is not an option, since the android rom and the app will have to be distributed separately.
So my idea is (and considering that I'm creating a custom build) to find the file in the android source where it says that the NFC enable/disable setting requires the WRITE_SECURE_SETTINGS permission and then disable that. Can anyone point me to where this file would be located in the android source?
Noob question.
What is the actual password to su on various smartphone models, say Galaxy S5 or LG L3?
Is it a fixed character string or a formula based upon some hw specific like MAC ID?
Why don't vendors and network providers verify certain apps for su and give those sw vendors their devices' root password, or is it done that way now?
OK found the following on the web.
root in Linux (or any Unix-like system) is just the user with User ID 0. The su program (which actually stands for "Switch User", not "Super User") is just a program to start another program with a different user ID than the starting program (by default to uid 0, which is to user root). Android does not use the traditional /etc/passwd, however it still uses Linux User ID and Group ID for managing permissions.
If you want to intercept su requests so you can ask for password or enforce other rules, you will need to replace /sbin/su with your own version of su. Alternative approach is the one described here:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
though that will require applications to cooperate by firing an Intent when they want to switch user.
Android security framework is more or less like this: each installed application runs on its own User ID (selected at installation time), and application permissions is implemented as user groups.
Can i change the root password after rooting my android device by simply typing "passwd"?
Android does not use /etc/passwd so it also does not have*passwd*program.
how is the rooting process working ? i mean what is the "one click root" apps doing to my phone?
I'm not quire sure with the exact process myself, you probably want to ask to rooting developers. However, my guess is it just reverts the security check that originally prevent developer from setuid 0.
End of paste.
So the above is saying there are no passwords in Android. To give an app or file root privilege you must change the app's user id that runs it or users id of the user who created the file to 0 (zero).
Therefore giving root privilege to an app on Android is a su app that changes the user id to 0 of the app you want to give root privilege to.
So why don't hw vendors and network providers who provide the Android ROM include a special su app that checks (look up in a file) whether app is OK for root and then grants it ?
"It has been claimed that the Privacy Guard implementation of ‘su’ has security vulnerabilities even when disabled. In other words, the mere presence of the su binary is enough to compromise the device.
Unfortunately, the person who reported this vulnerabilty refuses to disclose its exact nature, nor could we make sure to properly fix this exact issue. The next best solution is to ensure that su is only accessible when enabled in the Settings app and keep su disabled when it’s not in use.
We’ve created a kernel patch that hides the existence of su from all processes except root and system when the su daemon is not running (root needs access so that init can start the su daemon, and system needs access in order to populate the root access settings appropriately).
This effectively makes it impossible for unprivileged processes to exploit su when it is disabled in settings. Indeed, it makes it impossible to even see that the su binary exists. It cannot be seen either directly (via stat /system/xbin/su) or indirectly (via ls /system/xbin). A side effect of this, is that Play Services can’t detect su binary when root is disabled either, allowing some (older) devices to pass SafetyNet when root is installed but disabled.
This fix cannot be applied globally but must be merged to each device’s kernel. If your device hasn’t been patched yet, or you’re maintaining a device, take the proper patch and apply it as soon as possible (kernel 3.18, 3.10 and 3.4).
This is a precautionary measure. We are not aware of any active exploits targeting this issue....."
Ref: https://www.lineageos.org/Changelog-9/
Any developers looking to resolve this vulnerability, I already had it merged in my kernel weeks ago
Here https://github.com/anupritaisno1/an...mmit/20796ec7f64678ef644cd8c1085bb01c9e951049