Well, I was going to hold off until all of the vendors had new releases posted, but now that the cat is out of the bag and the evildoers have sufficient information to figure out what got fixed:
[size=+1]Current Superuser/SuperSU releases have security holes that allow any application to execute commands as root without the user's permission (even apps with no permissions). Please upgrade immediately to SuperSU >= v1.69 or another patched release.[/size]
This is expected to impact the vast majority of rooted devices and custom ROMs.
Details follow:
[size=+2]Superuser unsanitized environment vulnerability on Android <= 4.2.x[/size]
Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner:
ChainsDD Superuser (current releases, including v3.1.3)
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of third-party ROMs include one of these packages.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000):
/system/bin/log, to record activity to logcat
/system/bin/am, to send intents to the Superuser Java app
/system/bin/sh, to execute the /system/bin/am wrapper script
/system/bin/app_process, the Dalvik VM
The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent:
- On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > app_process ; chmod 755 app_process
PATH=`pwd`:$PATH su -c 'true'
The PATH vulnerability is being tracked under CVE-2013-6768.
- Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker.
The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774.
[size=+2]Android Superuser shell character escape vulnerability[/size]
Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request:
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line.
On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface.
If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell:
Code:
snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d",
VERSION_CODE,
ctx->from.name, ctx->to.name,
ctx->from.uid, ctx->to.uid, get_command(&ctx->to),
policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id);
get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root:
Code:
su -c "'&touch /data/abc;'"
Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769.
SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect:
Code:
su -c '`touch /data/abc`'
su -c '$(touch /data/abc)'
The SuperSU variant of this problem is being tracked under CVE-2013-6775.
ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line.
[size=+2]Superuser "su --daemon" vulnerability on Android >= 4.3[/size]
Current releases of the CyanogenMod/ClockWorkMod/Koush Superuser package may allow restricted local users to execute arbitrary commands as root in certain, non-default device configurations.
Android 4.3 introduced the concept of "restricted profiles," created through the Settings -> Users menu. A restricted profile can be configured to allow access to only a minimal set of applications, and has extremely limited abilities to change settings on the device. This is often used to enforce parental controls, or to protect shared devices set up in public places. The OS requires an unlock code to be entered in order to access the owner's profile to administer the system.
/system/xbin/su is a setuid root executable, and any user may invoke it in client mode ("su -c 'foo'" or just "su"), or in daemon mode ("su --daemon"). In either mode of operation, the user who invokes this program has the ability to manipulate its environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items. By adding new entries at the front of the PATH for commonly-executed root commands, then re-invoking "su --daemon", an attacker may be able to hijack legitimate root sessions subsequently started by other applications on the device.
"su --daemon" is normally started up very early in the boot process, as root, from /init.superuser.rc (CM) or from /system/etc/install-recovery.sh (other ROMs). The fact that unprivileged users are allowed to restart the daemon later, under EUID 0, appears to be an oversight.
Successful exploitation requires a number of conditions to be met:
- The attacker must have ADB shell access, e.g. over USB. This is disabled by default, and normally restricted to trusted ADB clients whose RSA key fingerprints have been accepted by the device administrator. Root access via ADB (i.e. Settings -> Developer Options -> Root access -> Apps and ADB) is not required. Note that ADB shell access is typically considered a security risk, even in the absence of this problem.
- The attacker must have a way to assume a non-shell (non-2000), suid-capable Linux UID in order to prevent /system/xbin/su from creating infinitely recursive connections to itself through the daemon client UID check in main(). One way to do this would involve uploading an app with the "debuggable" flag and using /system/bin/run-as to assume this UID. "adb install" can probably used for this purpose. However, due to a bug in Android 4.3's "run-as" implementation[1], this does not currently work. This bug was fixed in Android 4.4, so CM11 will probably be able to satisfy this requirement.
- The device owner must have granted root permissions to one or more applications via Superuser. The restricted profile does not need to be able to run this app from the launcher.
Sample exploit:
The restricted local user can reboot the tablet, run "adb shell" when the boot animation shows up, then invoke the following commands:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > /data/local/tmp/trojan
chmod 755 /data/local/tmp/trojan
for x in id ls cp cat touch chmod chown iptables dmesg; do ln -s trojan /data/local/tmp/$x ; done
PATH=/data/local/tmp:$PATH setsid run-as.422 my.debuggable.package /system/xbin/su --daemon &
(Note the use of "run-as.422" as a proxy for a working Android 4.3 run-as binary, and the installation of "my.debuggable.package" with the debuggable flag set.)
At this point the USB cable may be disconnected.
The next time a root application successfully passes the Superuser check and invokes one of the trojaned shell commands, /data/local/tmp/trojan will be executed under UID 0.
An ideal candidate for exploitation is a package which runs privileged commands on boot, e.g. AdBlock Plus or AFWall+, as this allows for instant access. Another possibility is to hijack an app which the device's operator runs frequently, such as Titanium Backup.
Note that this can NOT be exploited by malicious applications, as zygote-spawned processes (apps) always access /system in nosuid mode[2] on Android 4.3+. The ADB shell was used as the attack vector as it is not subject to this restriction.
ChainsDD Superuser v3.1.3 does not have an Android 4.3+ client/server mode at all, and SuperSU aborts if an existing "daemonsu" instance is already bound to the abstract @"eu.chainfire.supersu" socket.
Proposed resolution: on Android 4.3 and higher, install all Superuser-related binaries with mode 0755 (setuid bit unset).
This problem is being tracked under CVE-2013-6770.
[1] https://code.google.com/p/android/issues/detail?id=58373
[2] http://source.android.com/devices/tech/security/enhancements43.html
Did you report that to @Chainfire?
SecUpwN said:
Did you report that to @Chainfire?
Click to expand...
Click to collapse
Yes, he's been very responsive.
I contacted all three developers last Saturday, and posted the advisory after there was enough public information available to deduce what the problems were.
In case you're curious, there's been some additional discussion about exploiting ChainsDD Superuser on BUGTRAQ.
Is there a way we can patch this maybe using xposed framework
milojoseph said:
Is there a way we can patch this
Click to expand...
Click to collapse
There are new releases of SuperSU and CWM Superuser posted:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu&hl=en
http://forum.xda-developers.com/showthread.php?t=1538053
https://play.google.com/store/apps/details?id=com.koushikdutta.superuser&hl=en
I haven't seen any updates to ChainsDD Superuser, and AFAICT the project is no longer maintained.
maybe using xposed framework
Click to expand...
Click to collapse
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
cernekee said:
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
Click to expand...
Click to collapse
There's always Substrate, that can be used even for patching native code, but still in this case not applicable I guess.
Where you able to find any patch to fix them?
thank you for sharing ...
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
diabolicalprophecy said:
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
Click to expand...
Click to collapse
Did you get an answer for this? I have the same issue on 4.4.4
Vankog said:
Did you get an answer for this? I have the same issue on 4.4.4
Click to expand...
Click to collapse
No I didn't, I reflashed the rom and it solved the problem.
Related
The common method of enabling root by creating a suid root shell named 'su' opens the device to malicious programs; it is trivial to 'echo rm -rf|/system/bin/su'. Changing the name of 'su' only makes the exploit slightly more complicated at best. A standard /etc/shadow auth will not work, as this would require a shell program to set the password, and anything a user can do in Term.apk can be automated by a malicious program.
This method uses Dalvik's own security system, in which a GUI app cannot read the database of another app. 'SU Passwd' is a simple program to set a password value in it's database. 'su' is a modified version of the su from GNU Coreutils 5. When it's suid root, it can read the database, prompt for a password, and spawn a root shell if the typed password matches. By default it will reject if there's no database or no password entry, however it will not prompt for a password if the user sets it to 'NONE'.
* TO INSTALL:
put dist.newsu/su into /system/bin/su
chmod 4755 /system/bin/su
Install SUPasswd.apk
* SPECS:
The database structure is an approximation of /etc/passwd:
username|cleartextpass|homedir|shell
The GUI app currently doesn't support changing the home directory or the shell, however this can be done (as root) with:
sqlite /data/data/org.fnord.android.passwd/databases/passwd.db "update passwd set shell='/data/opt/bin/ash' where user='root'"
or:
sqlite /data/data/org.fnord.android.passwd/databases/passwd.db "update passwd set home='/data/opt/home' where user='root'"
* LICENSE:
'su' is covered under the terms of the license of GNU Coreutils-5.0
SUPasswd can be freely distributed, however any publicly modified version must also have publicly available source.
If you want to include this in your firmware distribution, please leave the database blank, as setting a default would defeat the purpose :>
* TODO:
Modify Term.apk to have a config option that throws 'su\nPASSWD' into the shell after launching it. This should make the security transparent while still
keeping a phone safe from naughty apps.
Make SUPasswd less cruddy and add home / shell options.
* Thanks to plusminus from anddev.org for the helpful example database app!
Alternate dl: http://g1.fnord.to/newsu-0.9.tgz
Gah! This is exactly the kind of sandboxing off of su i've been attempting to do for the past week. Good job Fnord!
Can somebody explain to me why we can't just create passwd file, change the root password by 'busybox passwd' and then use 'busybox su' to get root access?
Dimath said:
Can somebody explain to me why we can't just create passwd file, change the root password by 'busybox passwd' and then use 'busybox su' to get root access?
Click to expand...
Click to collapse
You can but either (a) you have an exploitable 'passwd' or (b) you're locked out if you forget.
A better way to do this is to leave a normal root su (sh) sitting in /system/bin and chown it to a custom group, of which the SUPasswd application userid is a member of.
Then the SuPasswd application can expose a <permission> that other applications can apply for (via <uses-permission>). Another application can fire off a intent to start a su confirmation Activity to request access to su.
SuPasswd handles that intent (the Java permission to even launch the activity is handled automatically by the Android system), and pops a dialog verifying that you want to give that application access to su. If accepted, SuPasswd then uses su (which it obviously has access to) to add the requesting application to the su group.
Don't need to mess around with databases then, and because su is using the standard Linux/Android security model. And any Java application can request access to su in a user friendly fashion, if allowed.
http://code.google.com/android/devel/security.html#manifest
Note: I had planned on implementing this myself, but there's so many other cooler things I wanted to work on first.
Koush said:
A better way to do this is to leave a normal root su (sh) sitting in /system/bin and chown it to a custom group, of which the SUPasswd application userid is a member of.
Then the SuPasswd application can expose a <permission> that other applications can apply for (via <uses-permission>). Another application can fire off a intent to start a su confirmation Activity to request access to su.
SuPasswd handles that intent (the Java permission to even launch the activity is handled automatically by the Android system), and pops a dialog verifying that you want to give that application access to su. If accepted, SuPasswd then uses su (which it obviously has access to) to add the requesting application to the su group.
Don't need to mess around with databases then, and because su is using the standard Linux/Android security model. And any Java application can request access to su in a user friendly fashion, if allowed.
http://code.google.com/android/devel/security.html#manifest
Note: I had planned on implementing this myself, but there's so many other cooler things I wanted to work on first.
Click to expand...
Click to collapse
Yeah, what he said. Sounds good.
How do you use the ?
put dist.newsu/su into /system/bin/su
Just got premission denied when using put command.
bunny0007 said:
How do you use the ?
put dist.newsu/su into /system/bin/su
Just got premission denied when using put command.
Click to expand...
Click to collapse
Assuming you have a modified RC30, run adb remount first.
bunny0007 said:
How do you use the ?
put dist.newsu/su into /system/bin/su
Just got premission denied when using put command.
Click to expand...
Click to collapse
If you have rc30_full_xda-dev_v1.2 installed, run these:
> adb remount -or- >adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
> adb shell rm /system/bin/su
> push su /system/bin
> adb shell chmod 4755 /system/bin/su
> adb install SUPasswd.apk
Koush, i'm looking forward to seeing that implementation ;-)
edit: Doh, forgot /system ro
Koush said:
Then the SuPasswd application can expose a <permission> that other applications can apply for (via <uses-permission>). Another application can fire off a intent to start a su confirmation Activity to request access to su.
Click to expand...
Click to collapse
It's posible to set custom permissions like that? I figure that would require modifying stuff in /system. I stuck with the KISS principle
Yup, custom permissions are pretty easy to use.
I was also wrong earlier about my previous hypothetical implementation: The Android version of Linux is considerably different when it comes to security: you can't use 'busybox addgroup' to add a user to a group: it works but it doesn't actually do anything (Android doesn't use/care/have a /etc/group).
But, what you CAN do is the following:
chown 0:10026 sh_26 (this gives the root user and app_26 group ownership of a copy of shell).
chmod 4750 sh_26 (this setuids the sh_26 to root, and gives app_26 execute permissions, but no one else)
-rwsr-x--- root app_26 86936 2008-11-21 17:25 sh_26
That should work, right?
The problem with this approach is that there are X copies of the shell laying around for however many applications need them.
You can, however, put give applications the same uid by signing the APK with the same private key, and using the <sharedUserId> attribyte. http://code.google.com/android/reference/android/R.attr.html#sharedUserId
This is equally bad though, because then the user confirmation is taken completely out of the equation, and then you introduce private key distribution or some sort of signing process.
So, it probably is just better to use a custom su, and include have applications make requests to get the password from the database using the <permissions> thing I mentioned.
Actually, you can probably just chown a single copy, and so long as execution is started by the given app before another one requests it, it should work fine-- even if the permissions change underneath it while it is running.
Koush said:
Actually, you can probably just chown a single copy, and so long as execution is started by the given app before another one requests it, it should work fine-- even if the permissions change underneath it while it is running.
Click to expand...
Click to collapse
Great app now i have no worries bout su !
Modified an icon from here to use for the SU Passwd applet. You can get the modified file here. Just open the Passwd.apk file and substitute it for the one in \res\drawable, then sign the apk with SignApk.jar. Here's what it looks like in the ui:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
usmc2k said:
Great app now i have no worries bout su !
Click to expand...
Click to collapse
I just started working on the application I described. I'll be done shortly.
Ok all, it's working. Will release it tonight. I wrote a custom terminal app called Shell to confirm it works. This Superuser application will provide a clean, standard (as in no custom version of su needed), way of exposing su to Java applications, and also close the security hole on your phone.
Shell tries to run su, but can't:
Shell requests access to su from the Superuser application I wrote:
User gets confirmation to grant Shell Superuser access.
Shell can now run su:
I'll be releasing the source to both Superuser and Shell so you guys can double check the security and also learn how to use the intents.
koush, nice job man. i was just avoiding the use of su until something could be done. for root access i limited myself to adb shell.. now i can safely use su, thanks to you.
Koush said:
Ok all, it's working. Will release it tonight. I wrote a custom terminal app called Shell to confirm it works. This Superuser application will provide a clean, standard (as in no custom version of su needed), way of exposing su to Java applications, and also close the security hole on your phone.
Click to expand...
Click to collapse
Hmm not sure if I prefer that method, but I may alter mine slightly; Writing a simple program (pwupdate) that updates /etc/passwd & /etc/shadow entries based on the SUPasswd database. This would be globally executable as well, but in theory as it takes no arguments it wouldn't matter (since the db is secure), and SUPasswd would call it after writing the db. There would be no need for a wrapper to getpwuid etc, though I'm not sure if bionic supports those functions. crypt() would need to be ported for pwupdate.
I'll implement this method next week - unless it's hectic.
jashsu said:
Modified an icon from here to use for the SU Passwd applet. You can get the modified file here. Just open the Passwd.apk file and substitute it for the one in \res\drawable, then sign the apk with SignApk.jar.
Click to expand...
Click to collapse
Thanks! I'll add this to the next version if that's ok?
Fnorder said:
Thanks! I'll add this to the next version if that's ok?
Click to expand...
Click to collapse
Knock yourself out.
Summary:
There have been a few threads about the root setuid su being a potential security hole on modified RC30 phones. We all want to have root on our phones, but we don't want malicious programs/people to take advantage of it.
To that end, I came up with the following program that fixes the security hole, and also allows you or any application to get root when authorized.
This program works with any application that may use su: no special code or support needs to be written. Just use su like normal from within both Java applications or a terminal.
To install, simply install the Superuser application on top of modified RC30 V1.2.
If Superuser does not install properly automatically, do the following to install it manually:
Make sure you have the adb tool from the SDK.
Unzip the ZIP file (it will create a folder called Superuser).
Run install.bat (or install.sh if you are on Linux) from the Superuser directory.
Here's the script that the install runs:
Code:
adb push bin/su /system/bin
adb shell chmod 4755 /system/bin/su
adb uninstall koushikdutta.superuser
adb install bin/Superuser.apk
How it works:
The modified su command looks in a whitelist database for uids that is allowed root access. That database is only accessible by the Superuser application and root.
If a database entry is found, it decrements the white list counter by one (so, an application can access su 10 times, 1 time, etc, depending on the count).
If no database entry is found, it will show the Superuser confirmation activity and wait for 10 seconds for the user to respond. If the user presses yes or always, it adds the user id to the white list. (If yes is pressed, the white list counter is just 1).
If access was granted, su will setgid/setuid and call /system/bin/sh.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Implementation:
The Superuser Java application was written by me.
su was based on the su implementation built by Google for the Android platform. http://android.git.kernel.org/?p=pl...eb00e56211962786ff89d0e7940f73d7e914e;hb=HEAD
Source code and binaries are attached to this post.
[*]The standard RC30 install will have a setuid /system/bin/su. (if you deleted disabled it, reenable it for setup)
Click to expand...
Click to collapse
v1.2 and up only, correct? Not the setuid sh of v1.1.
jashsu said:
v1.2 and up only, correct? Not the setuid sh of v1.1.
Click to expand...
Click to collapse
Edit: Yeah, you need a setuid su in /system/bin. Having a setuid sh won't work.
?
Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?
cookzitall said:
Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?
Click to expand...
Click to collapse
Yup, of course you can delete the su command from the handset so you can only adb shell for root.
However, then legitimate uses of having root on your handset would not be possible:
For example, I am currently working integrating the G1 WiFi router instructions sticked in this forum into the Android WiFi settings application.
I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.
Great work by the way!
persiansown said:
I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.
Great work by the way!
Click to expand...
Click to collapse
They can use the Intent that is exposed by Superuser, that Shell uses to get root:
Code:
final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!
Then, if the user presses Yes or Always, that Java application can call su just like normal:
Code:
Runtime.getRuntime().exec("su -c <your privileged command here>");
Otherwise, that command will fail.
Koush said:
They can use the Intent that is exposed by Superuser, that Shell uses to get root:
Code:
final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!
Then, if the user presses Yes or Always, that Java application can call su just like normal:
Code:
Runtime.getRuntime().exec("su -c <your privileged command here>");
Otherwise, that command will fail.
Click to expand...
Click to collapse
Sounds good. Great job. Hopefully apps that require root in the future use this method rather than trying to force it.
Hi Koush,
I have Jf's modified RC30 but I am not that tech savy. Before I could access su in terminal emulator but now i am locked out. I downloaded both your apps off the mark but when I request superuser I get an error. Also terminal emulator now doesn't work when i enter in su. I think that was the point though.
However the error message on shell when i request superuser says;
error: permission denied: starting intent {action= android... and so on....
What should i do to get root back?
PLease advise.
Thank you,
hbguy
question
i change the "su" to a different word...thinking it wouold help with security a little while back..does that effect your program?
hey can anyone tell me what empty whitelist means?
I am having the same issue. I cannot execute su from terminal, permission denied. and when i try to get su access with the new shell program i get and error with "android.permission.ACCESS_SUPERUSER.
now my root job is all for nothing and im wondering how to get it back to normal.
Do i have to reflash from the backup image?
Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.
Leeah said:
Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.
Click to expand...
Click to collapse
Yes, don't worry: it is not possible to "lose" root with Superuser. You can always adb shell in for root; and if worst comes to worst (and it shouldn't), you can reflash.
I am updated to Jesusfreke's newest modified version 1.2 but I still get the same error when i request superuser off of shell ( i also remembered to run superuser before requesting access in shell too). I just re-flashed ( i think that's what its called) JF's modified and now I can run root on terminal emulator again if DONKEY still trying to figure out how to get it back.
I'd like to use superuser and shell but I think I'm missing something lol.
Sorry, clearly a noob here.
I think what we need is a combination of fnord's and koush's approach .
I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).
So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.
The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.
Thoughts?
Anyone wanna take this on? If not, I may have to do it myself
JesusFreke said:
I think what we need is a combination of fnord's and koush's approach .
I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).
So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.
The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.
Thoughts?
Anyone wanna take this on? If not, I may have to do it myself
Click to expand...
Click to collapse
IMO, su should act like normal su in every respect from a scripting perspective. IE, it never prompts for password on stdin. Piping in passwords from Runtime.exec is sort of kludgy. Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.
That is my primary aversion to fnord's implementation; it makes development a pain, and future compatibility scary.
I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.
This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?
Edit:
Or conversely, you can modify a normal su to block on a call to an Android Activity that asks for user confirmation. That's actually probably the better way to do it: avoid the Java code unless absolutely necessary.
I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.
This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?
Click to expand...
Click to collapse
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. In any case, the difference would only be relevant for Android apps that use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.
Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.
Click to expand...
Click to collapse
Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.
jashsu said:
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. So the only benefit would be for Android apps that specifically use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.
Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.
Click to expand...
Click to collapse
Yeah, I admit the su script isn't ideal. Which is why I edited my post and suggested that su block on an Android Activity (the other way around) when necessary.
Off the top of my head, there are several applications that I am working on or have planned that will require su:
Fully configurable WiFi Router UI (that basically automates the instructions found in the sticky in this forum)
Screenshot Application
Auto Screen Rotation
And there will be even more applications that will require su as we move forward: and they won't just be reduxes of a console/shell, where it is reasonable to prompt for a password on stdin. So for that reason, I want the su implementation to be as transparent as possible, so future usage from Java applications isn't a pain in the ass.
Jf, you are the man! and yes i am making sure that this message is over the required character and it is indeed a message with a profound meaning...
hbguy
I saw in the SDK this permission for apps to request:
public static final String FACTORY_TEST
Run as a manufacturer test application, running as the root user. Only available when the device is running in manufacturer test mode.
Constant Value: "android.permission.FACTORY_TEST"
Click to expand...
Click to collapse
Our current model with superuser whitelist is not very secure because a malicious person could bundle their own su binary and circumvent the restrictions. It would seem that having our custom roms run in test mode would provide a great solution: using Android's own permission/security model for apps to run as root. This should force all apps to visibly request root permissions at install time.
I am in favor of anything that will improve the security of my phone. It concerns me that anyone who knows what they are doing can so easily boot into recovery mode on my phone, wipe and flash any ROM they want. Granted, they would not have access to my information if the wipe and flash. But, it makes it trivially simple to hijack my phone. I would like to have some password protection for Recovery and Fastboot.
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
what's a adp device? and explain how they could possibly do this again?
android developer phone.
jaaronmoody said:
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
Click to expand...
Click to collapse
well, technically, if we have root, dont have an "ADP" device?
when I do a fresh install, it says welcome to Android Developer Phone 1 (in most ROMs)
the adp device was a specific phone release for developers to be used with the sdk.
jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
I know that, but the hardware is the same as ours (they just get the awesome battery cover)
jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
Most roms especially cyanogen Roms are based on SDK/ADP1 directly and thus making our devices recognizable as ADP Devices.
Simple solution could be to restore the original su binary at boot.
1) keep a copy in the boot image ramdisk
2) scan the path at boot for su
3) compare md5sum with the original
4) delete if md5sum is different
5) restore original trusted su
and also just for paranoia:
6) scan system for setuid binaries and report to the user
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
lbcoder said:
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
Thanks for clearing that up.
The idea posted earlier about recovery menu password should be lofted at Cyanogen (or anyone willing to take that on). Should we make a thread for it?
Keep in mind that it is physically impossible to secure your phone against somebody who gets their hands on the actual device. You can only make it harder to get at it. If somebody wanted to they could just read the flash chip directly or use JTAG to get at it. However, I agree that adb could be made a bit more secure.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
I have one thing to say to you:
http://en.wikipedia.org/wiki/Setuid
Now that you've made a complete and utter fool of yourself, how do you feel?
FYI: your regular user can NOT chown root. Go ahead and try it.
alapapa said:
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
Click to expand...
Click to collapse
It is a moot point whether the setuid bit can be restored since a regular user doesn't have the ability to change the owner to anything but self, which means that the best they could do is create an su binary that will give other users THEIR OWN permissions.
A regular user can change ownership *only* to self -- i.e. if they have group or other write permission, then they can chown the file. They can also change the group, but only to groups to which they are members -- and this requires that they already have some form of write permission on the file.
Note that extracting a file is no different than actually *creating* the file, which means that if the user couldn't simply MAKE the file, then they can't *extract* the file either.
If any of this was untrue, there would be nothing to stop any user from doing something like this to take over any Linux computer (except from within a chroot jail, but that doesn't apply here);
cp `which sh` ~/su; chown root:root ~/su; chmod 4755 ~/su
** but that most definitely won't work.
I'm evaluating MDM system which says that relays on Android system mechanisms to detect root.
1. Does this mean SELinux policies or any API for that?
2. How exactly daemonsu binary work? If I understand corectly it start with system by some hook, and by another registers channel to communicate with su binary. Do I understand this process correctly? If yes what exactly are those hooks?
I renamed /system/xbin/su and busybox to my own names. But there is
/system/xbin/daemonsu
Click to expand...
Click to collapse
which won't work if I rename it. I have read that it's due to pass SELinux filters. But I want to rename it, is there source of it avalible anywhere or option to rename some symbols? As far as I understand linux we can remove privileges from daemonsu, but stat call on it will beahave different privileged aplications
Please don't forward me to Xposed or backed apk's for this purpuses, I want to understand mechanisms behind this.
Hi,
IT MIGHT BRICK YOUR DEVICE.
Always ensure you have a way back.
Here is a thread about my fork of Koush's Superuser, to handle SELinux: https://github.com/seSuperuser/Superuser
So I would like your help to make this SuperUser a proud opensource SU app!
If you have an application that requires root, and which needs specific SELinux configuration please ask!
Build bot: https://superuser.phh.me/
Currently, four flavors of su are available on the build-bot:
- "eng" which puts "su" in permissive mode. This is the most compatible mode, but you should trust the apps you give root to. This does NOT put SELinux in permissive mode.
- "noverity" is eng and dm-verity disabled
- "nocrypt" is eng, dm-verity and dm-crypt disabled
- "user" is meant to give a safe su. su-apps won't be able to access to your Android Pay (for instance) informations, or keep persistent su access without your consent
Please note that user is in heavy development and isn't up to its promises at the moment.
I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/
I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
Supporting new devices might mean some additional work on http://github.com/seSuperuser/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.
You need to install the APK from PlayStore afterwards: https://play.google.com/store/apps/details?id=me.phh.superuser
Bot-supported devices
Here are some devices, but there are many more !
- A *lot* of Archos devices
- All Nexus-es, including Pixel C (if some Nexus is missing, just ask!)
- nVidia Shield TV
- nVidia Shield Tablet
- Fairphone 2
update.zip format
The zip is available at https://superuser.phh.me/superuser.zip
It should be able to root any device supported by super-bootimg from TWRP (and possibly other custom recoverys)
You still need to install the APK afterwards. https://play.google.com/store/apps/details?id=me.phh.superuser https://f-droid.org/repository/brow...lob/master/known-imgs/nexus/hammerhead/MRA58N describes a firmware, nothing device-specific). This only requires to do some PRs to add a device, or on updated firmwares
- Testers
- UI designer: The current UI dates back from 4.1...? It is really ugly and not really usable.
- Testers
- Root-related devs: SELinux policies are still being written
- Testers
- Security reviewers
- Testers
Bug report
If some app doesn't work, please ask me, not the dev.
I consider I have to fix support for other apps, not the other way around.
ChangeLog
2016-01-31 r170: superuser.zip can be included in other update.zip
2016-01-27 r166: Add support for Viper4Android
2016-01-15 r162: Add su --bind and su --init commands
2016-01-10 r154: Files are no longer copied multiple times. Fixes MultiROM, and multiple install for update.
2016-01-06 r152: Fix support for ChromeOS-like format (Pixel C)
2016-01-01 r144: Detect chromeos-style signature, and don't try to resign it in that case
2015-12-30 r143: Improved compatibility with apps.
2015-12-28 r142: Changed naming convention to include device name and release
2015-12-28: Added "nocrypt" target
2015-12-13: Added "noverity" target to buildbot
2015-12-13: Add options for noencrypt, noverity
2015-12-03: Fix TitaniumBackup
2015-11-24: mount --bind to /system/xbin/su if it exists to override ROM's su
2015-11-23: Fix CF.Lumen
2015-11-14: Add super-bootimg's version in boot.img, several network/firewall-related permissions
2015-11-11: Access to Android's services
2015-11-10: Recursive su access
2015-11-09: Fix pm disable command
Do you mean that latest galaxy s5 neo sm-g903f might be rooted soon ?
(Exynos5 & Mali T-720)
It seems like many people still haven't understood the purpose of apps like SuperSu and Superuser. They are no exploits and don't gain your root access. What they do is they manage the root access and enable you to select which apps to grant root access, otherwise every single application on your device would have it. They are root managers. So this project won't help you in getting root for your device as long as there's no method (exploit) to gain it.
Not much activity here, but a lot on my side.
Android 6.0 is now out, with its new SELinux policy, which makes it impossible to update the policy after the boot, and dm-verity becomes mandatory (so no /system change without boot.img)
I'm thus totally retargetting my work:
- I've created https://github.com/phhusson/super-bootimg which will edit boot.img (the complicated part, because it needs A LOT of testing across many devices)
- change sepolicy
- Add su in /sbin/su
- Enable su daemon
With various options to disable dm-verity, encryption, etc. (please note that this is NOT required, since only boot.img is changed)
dude - you should kickstarter this. SuperSu is pretty much a mandatory install for every rooted device. this is big for the XDA community and we would love to support you.
Cannot express enough how much i want this project to succeed
And, at least for myself
"I also wonder about displaying an user-understandable SELinux policy, so that root applications can be "more secure
Would anyone be interested in such a feature?"
......Hell yeah, that most certainly does interest me.........controllable levels of su right?
Obviously, if its possible to do........even if android denies this possibility, an open source su is most assuredly welcome from this neck of the woods
I wish this project major luck
Edit
"(I'm thinking that I'm trying to be even more secure than "standard" non-rooted ROMs, that's perhaps a bit optimistic.)"
I love that mentality, and im enjoying immensley your discussions on github with lbdroid........i love that your taking security more seriously then most...love where your coming from on this.....major props
To better test on shell of recovery without making an update.zip , I modified the sepolicy-inject.c so that the usage() no longer blocks the "booting.sh"
on sepolicy-inject.c:377, insert a line "if ( NULL == optarg ) break;", as in my shell there will be a parameter value with null on last entry of "char** arguv", which will trigger the default switching case and exit the sepolicy-inject unexpectedly.
......
while ((ch = getopt_long(argc, argv, "a:f:g:s:t:c:Z:z:n", long_options, NULL)) != -1) {
if ( NULL == optarg ) break;
switch (ch) {
......
kennylam said:
To better test on shell of recovery without making an update.zip , I modified the sepolicy-inject.c so that the usage() no longer blocks the "booting.sh"
on sepolicy-inject.c:377, insert a line "if ( NULL == optarg ) break;", as in my shell there will be a parameter value with null on last entry of "char** arguv", which will trigger the default switching case and exit the sepolicy-inject unexpectedly.
......
while ((ch = getopt_long(argc, argv, "a:f:g:s:t:c:Z:z:n", long_options, NULL)) != -1) {
if ( NULL == optarg ) break;
switch (ch) {
......
Click to expand...
Click to collapse
I'm not sure I understand...
When calling what command do you need this?
phhusson said:
Hi,
IT MIGHT BRICK YOUR DEVICE.
Always ensure you have a way back.
I'm the author of a fork of Koush's Superuser, to handle SELinux: https://github.com/phhusson/Superuser
It is in early-stage, but thanks to recent events related to SuperSU, it got some spotlight.
So I would like your help to make this SuperUser a proud opensource SU app!
I have mostly two sides of things left to do:
- Device compatiblity/update.zip
- Application compatbility
I've tested my Superuser on Qualcomm/CAF 5.1 devices, on MTK 5.1 devices, on CAF 6.0, on Nexus 5/9 6.0, and I believe it should work on most devices which are close enough to AOSP.
I have missing steps to be compatible with SuperSU (see https://github.com/phhusson/Superuser#todo-list ).
I'd like to have feedback from app developers about which features they need the most.
If you have an application that requires root, and which needs specific SELinux configuration please ask!
There are main two types of builds, and some sub-types in it:
- @doitright did an integration in an AOSP tree, to make it suitable for ROM integration, https://github.com/lbdroid/AOSP-SU-PATCH/
- I did http://github.com/phhusson/super-bootimg/ which integrates su in a binary boot.img, and outputs a root-ed boot.img
@doitright's source solution currently has one SELinux policy, which is fully enforcing, and currently works in most cases.
My solution currently has two different policies, one which has su permissive, meaning it can do anything, which is not as safe as source-based s solution, and one which is WIP (basically unusable, because almost nothing is allowed to root).
I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/
I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
Supporting new devices might mean some additional work on http://github.com/phhusson/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.
The plan is to have a third method for rooting:
super-bootimg will work from a recovery, so that you can root any ROM from recovery.
Thanks !
Click to expand...
Click to collapse
my question is how to change a file label to u: object_r:system_file:s0
i modify system.img to add some additional apps into /system/app/ directory i did modification then build a new system.img after flashing phone with new system.img the app was appear in menu but once i am trying to open it gives me error (com.xxxxxx.andriod) stopped working then i execute ls -Z command in /system/app/ directory to see the different and i realize that the new app i copied in system/app/ directory it has a different label than others
so i tried to change .apk file label to (u: object_r:system_file:s0) using chcon command but failed
chcon: Could not label u: object_r:system_file:s0
can you please guide me how to do it ?
zameer_yus said:
my question is how to change a file label to u: object_r:system_file:s0
i modify system.img to add some additional apps into /system/app/ directory i did modification then build a new system.img after flashing phone with new system.img the app was appear in menu but once i am trying to open it gives me error (com.xxxxxx.andriod) stopped working then i execute ls -Z command in /system/app/ directory to see the different and i realize that the new app i copied in system/app/ directory it has a different label than others
so i tried to change .apk file label to (u: object_r:system_file:s0) using chcon command but failed
chcon: Could not label u: object_r:system_file:s0
can you please guide me how to do it ?
Click to expand...
Click to collapse
Can you check in audit log?
How did you put the file?
Don't you have any other message?
Maybe in your intro you can eloborate on the naming convention of your bot built .img’s?
one which has su permissive (power?), meaning it can do anything, which is not as safe as source-based s solution (user?), and one which is WIP (eng?)
Your HTTPS link to superuser.phh.me is refusing connections?:
This webpage is not available
ERR_CONNECTION_REFUSED
ReloadHide details
Google Chrome's connection attempt to superuser.phh.me was rejected. The website may be down, or your network may not be properly configured.
Check your Internet connection
Check any cables and reboot any routers, modems, or other network devices you may be using.
Allow Chrome to access the network in your firewall or antivirus settings.
If it is already listed as a program allowed to access the network, try removing it from the list and adding it again.
If you use a proxy server...
Check your proxy settings or contact your network administrator to make sure the proxy server is working.
If I do a flash-all.sh of mra58r, reboot to bootloader, fastboot flash boot your-boot.img, would you expect this to boot fine?
Can you detail which phones can take a custom keystore?
For https, I know it is a must, but i'm waiting for let's encrypt.
For naming convention, I have to rethink those, and i'll update first post.
Anyway it's user < power < eng.
User has only safe permissions, power has all known permissions, eng is permissive. There is nothing source based.
For custom keystore, at the moment I have only seen CAF 5.1/6.0 bootloader with verity enabled to work, and it doesn't display key ID, so it is useless everywhere.
I should get a hand on a Nexus 5X soon, to test properly and get screenshots if it works as advertised.
For your last question, yes. I always work with factory image's partitions, and only change boot.img
I welcome any suggestion about naming convention.
Some times I dont know where to post, here or the Nexus 6 doitright thread. Anyway, I found this interesting.
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
"• We relax some security policies in eng/userdebug loaders to make life less annoying for development • Persistent Data Block ignored, device always unlockable"
If this is true of the boot.img's you build, the only one we could trust is user or are they talking bootloader? Maybe the factory bootloader (user) that google is distributing does not have the verification functionality? Is the bootloader AOSP? If so, what would prevent someone from creating a bootloader, boot.img and /system that circumvents all the verification?
I used your bot built mra58r.
Unfortunately, if forced encryption is on, local.prop does not get parsed and I dont get my custom LCD. This means unless you offer variants of the auto built boot.img with forced encryption off or the ability to pass a noencrypt parameter to the update.zip or build.sh for modifying fstab, I will be forced to modify source and build myself. As for mount -o bind /data/local/tmp/hosts /system/etc, as long as the custom hosts has chcon ubject_r:system_file:s0, things work great.
I still like idea of having the ability to establish a trust between boot.img and a config file in /data/ that do things like custom hosts file, lcd density, iptables (one of my favorites: iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53; iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53)
havealoha said:
Some times I dont know where to post, here or the Nexus 6 doitright thread. Anyway, I found this interesting.
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
"• We relax some security policies in eng/userdebug loaders to make life less annoying for development • Persistent Data Block ignored, device always unlockable"
If this is true of the boot.img's you build, the only one we could trust is user or are they talking bootloader? Maybe the factory bootloader (user) that google is distributing does not have the verification functionality? Is the bootloader AOSP? If so, what would prevent someone from creating a bootloader, boot.img and /system that circumvents all the verification?
Click to expand...
Click to collapse
They are talking about the bootloader, but as it is built in the Android build system, they are using Android build system flags.
I know the Nexus 6/9 doesn't have this functionnality. I'm waiting to get a Nexus 5X in my hands to say for 5X/6P.
Either way, we can't circumvent the verification, all we can do is have a YELLOW state instead of ORANGE, which displays the fingerprint of the keystore.
I forgot this presentation from Intel, so I thought I'd give it a try on Nexus Player. Intel has a proper implementation of the bootloader of Google's recommendation, it sounds logical the Nexus Player would implement it.
Oh wait. Google's logic striked again. No they didn't implement it on Nexus Player.
There is no AOSP bootloader... Or there are three (there are two LK and one u-boot), but neither of them are supported, and neither of them support the different verified boot states.
CAF bootloader handles the four states, but doesn't display them. Thanks to you I checked Intel reference bootloader, and it DOES implement the full spec \o/. Though I have no device to test. But basically, there is no opensource arm bootloader implementing it, and that makes me rant a lot against Google.
havealoha said:
I used your bot built mra58r.
Unfortunately, if forced encryption is on, local.prop does not get parsed and I dont get my custom LCD. This means unless you offer variants of the auto built boot.img with forced encryption off or the ability to pass a noencrypt parameter to the update.zip or build.sh for modifying fstab, I will be forced to modify source and build myself. As for mount -o bind /data/local/tmp/hosts /system/etc, as long as the custom hosts has chcon ubject_r:system_file:s0, things work great.
Click to expand...
Click to collapse
Two sides:
1. For LCD density, have you tried just doing adb shell wm density? Possibly it doesn't even break SafeNet
2. My plan on the matter is to keep my current builds as is, but add a configuration file, and when I'll make an update.zip, the user will be able to change the config file directly in the update.zip
I still like idea of having the ability to establish a trust between boot.img and a config file in /data/ that do things like custom hosts file, lcd density, iptables (one of my favorites: iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53; iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53)
Click to expand...
Click to collapse
Well for iptables, I put it in standard su permission. Well ATM because of some bugs it's only in "power", but I expect it to get into "user" when a bug concerning pts is fixed.
phhusson said:
Two sides:
1. For LCD density, have you tried just doing adb shell wm density? Possibly it doesn't even break SafeNet
Click to expand...
Click to collapse
Yay! As su in Terminal Emulator, wm density 360 worked. The launcher didn't work until #am start -c android.intent.category.HOME -a android.intent.action.MAIN and other apps also needed to be killed before they would display at the new density like lock screen and existing notifications. There are a few issues with the status bar and nav buttons depending on what app you try to run. I assume that if you set this early enough with a hook from init.rc, (nudge nudge) say a trusted file from /data/ that there would be no problem.
LCD density set from setprop, local.prop and wm density all break SafeNet. Even worse, SafeNet now checks /sbin/ for su, requiring a mount bind to a copy of sbin without su. Next thing you know, it will check for bind mounts!
How about a build of SuperSU, su in a random directory with random names? I know, name it the hash of boot.img or the public key from the user generated keystore.
Dont read on, I fixed it , the /data/setlcd.sh 560 needed quotes around it.
I created a Terminal Emulator widget in an attempt to make it easy to switch between resolutions. Interestingly, when set with #wm density 360 and then #am restart, the density sticks across reboots, I was not expecting that!
Ive tried the widget with different combinations of explicit paths for su with options like --context and -c with wm density and am restart and even with a /data/setlcd.sh that is chmod 750 and chcon ubject_r:system_file:s0. Any tricks to accomplish this? I would expect the widget to prompt for root permission and then run my setlcd.sh taking the DPI as argument $1 I am envisioning one main .sh that has a function for each of my customizations, wm density, hosts, iptables and mount bind to a /sbin that has no su. I dont want to keep building boot.img's with special init.rc's.
The closest I have gotten is a widget with command /sbin/su with the arguments -c /data/setlcd.sh 560
This results in a terminal launching that asks for su permission and then:
$"/sbin/su" -c /data/setlcd.sh 560
sh: /data/setlcd.sh: can't execute: Permission denied
nothing in dmesg
Click to expand...
Click to collapse
So I made a test of verified boot feature here: http://forum.xda-developers.com/and...rified-boot-disk-encryption-testings-t3248161
The tl;dr is that verified boot is IMO a great feature of 5X/6P, and we have to find a way to have su enabled with this feature.
But this requires to have working OTA.
I have finally gotten the functionality I need with the exception of iptables which I understand you are working on adding. I am testing with shamu mra58r and the boot-su-power.img.
Here is my setup that features:
custom hosts file for browsing without advertisements
set the LCD density to tablet mode
quickly disable su and revert density when I want to use Android Pay
As root, I created a script in /data/android.sh and set the context to system via chcon ubject_r:system_file:s0 and chmod 700 here are its contents:
Code:
#!/system/bin/sh
#bind mounts transcend am restarts
#wm density transcends reboots
function lcd
{
/system/bin/wm density $density
/system/bin/sleep 3
/system/bin/am restart
}
function hosts
{
mount -o bind /data/hosts /system/etc/hosts
}
function nosu
{
/system/bin/wm density 560
cp /sbin /data/sbin -r
rm -f /data/sbin/su
mount -o bind /data/sbin /sbin
/system/bin/am restart
}
function dns
{
#not working yet in phh
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53
}
density=$2
case "$1" in
lcd) lcd ;;
hosts) hosts ;;
nosu) nosu ;;
dns) dns ;;
esac
The hosts file was copied from http://winhelp2002.mvps.org/hosts.txt and placed in /data, its context was also set chcon ubject_r:system_file:s0 and chmod 644. The local host entries were modified to match those found in /system/etc/hosts. It was important that the contents of this file were terminated on each line and with a blank line at the end.
The tricky part was creating launchers on a home screen using the Terminal Emulator Widget. It seemed that you could not just type in /sbin/su, instead you had to browse to it. Screenshot of widget config attached.
I learned a few interesting things during testing.
Using a /data/local.prop with an encrypted disk resulted in the local.prop not being read during init.
Once wm density is set, it is persistent.
Using mount -o bind gives persistent mounts if you reboot using am restart from the terminal
SafetyNet now checks for su in /sbin
SafetyNet for AndroidPay checks for LCD density regardless of setting it via local.prop (if unencrypted), setprop or wm density
This will be easy for me to reproduce across all my devices without granting persistent root to any app and without adding any app but superuser and terminal emulator.
Thanks for your test! It's really interesting.
You must be the first user of something other than eng
iptables does work for me (in adb shell). Looking back, it should have been fixed by https://github.com/phhusson/super-bootimg/commit/31d3a635eea4fe66071346e05913acfb00d60144
That made me realize that if I don't do releases, I still need to know what users are using, so I added /super-bootimg which contains the git version of super-bootimg repo
For local.prop I'm happy to see you don't need it. I really feel like user shouldn't be allowed to change it (but I'm thinking only about some properties which are in /default.prop so it can't be overriden. perhaps local.prop is safe enough)
am restart is not a reboot, so it's normal mount bind stays
I think you could just mount bind an empty folder to /sbin. The only risks are if adbd/ueventd/watchdogd/healthd restarts, but they shouldn't
Any idea why busybox nslookup is not working?
[email protected]:/data # ls -Z nslookup busybox-android.bin
lrwxrwxrwx root root ubject_r:system_data_file:s0 nslookup -> busybox-android.bin
-rwxr-xr-x root shell ubject_r:system_file:s0 busybox-android.bin
[email protected]:/data # ./nslookup superuser.phh.me 8.8.8.8
Server: 8.8.8.8
Address 1: 8.8.8.8
nslookup: can't resolve 'superuser.phh.me'
1|[email protected]:/data # dmesg
[39764.686702] healthd: battery l=91 v=4144 t=28.1 h=2 st=3 c=-439 chg=
[email protected]:/data #