Securing your android after ROOT - XPERIA X10 Android Development

Hello everyone,
Its been great to have root on your X10 using the method posted here:
http://forum.xda-developers.com/showthread.php?t=711907
Well, this method works all right but I did some investigating of my own to audit the state of the system after its been rooted. Thanks to the discussions you may find here: http://forum.xda-developers.com/showthread.php?t=712178, the original developers soon chose to update the Rooting tutorial with some additional steps (See post #2 and #4 of the rooting thread). This is all good, because now you have the real power to act as a the *real* superuser i.e uid 0.
Most of the discussions that follow are only intended for users who are well versed with general *NIX security and concepts about user ids, permissions and other things. So please disregard this post if you have no ideas of these concepts.
Ok, so first things first. I basically followed the root tutorial as it is all the way upto step3 (or step3a as in my case). Remember, you essentially have a rooted phone right after step2, step3/3a just adds the updated baseband firmware, which has no effect whatsoever on the subsequent things that you do to your phone.
Well essentially, what I did do was install the "su" binary and the "Superuser.apk" following in the lines of step4v2 (post #2 in root thread). These are essential to give you control over your system as without them you are simply relying on a hacked "sh" binary which runs with elevated privileges. Here are the file permission masks for the "sh" binary which gets installed after the FOTA in step2:
Code:
# ls -l sh
ls -l sh
-rwsrwsrwx root root 86944 2010-06-28 18:08 sh
#
Wait!!! This is *not* quite ok. What this means is that any process can use this binary to gain super user privileges. This binary is setuid and setgid root!!!
Well you might say that... so is the case for "su":
Code:
# ls -l su
ls -l su
-rwsrwsrwx root root 22120 2010-06-28 08:08 su
#
But, this is different because its use is controlled by the Superuser Whitelist application that was installed with Superuser.apk.
This difference is crucial because if any non-privileged application and process forks and execs "su", the Superuser Whitelist app would immediately post a notification screen on the phone and provide options to allow or disallow.
With the "sh" binary installed on your phone as it is, you are basically inviting *any* application to be able to do anything it wants to your phone... and all this without your knowledge!!!
To test this theory, all you need to do is simply install one of the terminal emulators floating around the market or use the one provided in the rooting thread under the step4/app folder and launch it. It straight away, launches you into a root shell. Here is a screen shot of what you can do this way:
{
"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"
}
(Remember, no warnings, no notifications and all this can be done by any app under the hood)
Here is what you can do to make your phone more secure.
Step1: Download an alternative shell or simply change the permissions on the "sh" binary:
Code:
# cd /system/bin
# chmod 755 sh
Step2: In case you downloaded an alternative shell like "bash" and copied it under your /system/bin folder, simply get rid of the original "sh" binary and create a symlink to the one you download, for ex: bash:
Code:
# cd /system/bin
# rm sh
# ln -s bash sh
(Note: the above steps assume that you have /system mounted as rw, if you don't know what that means, then you should not be reading this, sorry)
Remember, when installing any alternative shell make sure that its permission mode is set to 755 or lower. I recommend to *never* set the setuid and setgid bits on the shell!!!
Here is what I did personally:
Installed bash from here: http://forum.xda-developers.com/showthread.php?t=537827
Installed it under /system/bin *without* the setuid and setgid bits
Removed the "sh" binary
Created a symlink named "sh" to the binary "bash"
This way, whenever I launch "adb shell" or use any terminal emulator on my phone, I always get a un-privileged shell. To get root, simply fire "su".
PS: This information is not intended for casual users who have limited or no knowledge of UNIX or UNIX like sytems like Linux, Adrdoid SDK commands like adb or don't know their way around if faced with a command line!!!
PS: Another post with some steps to properly secure the system: http://forum.xda-developers.com/showthread.php?t=712945

---

lmao..
http://forum.xda-developers.com/showthread.php?t=712945

---

zephyrix said:
lmao..
http://forum.xda-developers.com/showthread.php?t=712945
Click to expand...
Click to collapse
lol, you must've done this while I was writing mine!!
Anyways, its good to have this info out and I do point out some concepts detailing *why* this is a problem.

---

Definitely.
Make sure people have installed a proper way to elevate to root before attempting to change sh to not setuid, or they may screw themselves over lol

---

Thanks for your guide! Much appreciated would be an understatement.

---

is there any other way of testing that as using tht method in ur given picture now says read only error does this mean i successfully secured my root?

---

bcool15 said:
is there any other way of testing that as using tht method in ur given picture now says read only error does this mean i successfully secured my root?
Click to expand...
Click to collapse
Oh... I think I forgot to show this, but essentially you need to get the system partition into read/write mode as well. So it will be one more command before the write is attempted:
# mount -o remount,rw -t yaffs2 /dev/mtdblock2 /system
...
...
# echo "I can...

---

j4mm3r said:
Oh... I think I forgot to show this, but essentially you need to get the system partition into read/write mode as well. So it will be one more command before the write is attempted:
# mount -o remount,rw -t yaffs2 /dev/mtdblock2 /system
...
...
# echo "I can...
Click to expand...
Click to collapse
thats the command which stoppped wrkin so i just redid whole rooting procedure with new v3 update does it still need securing?

---

bcool15 said:
thats the command which stoppped wrkin so i just redid whole rooting procedure with new v3 update does it still need securing?
Click to expand...
Click to collapse
Dont worry about the example shown in the screen shot. That is just to illustrate what a setuid "sh" binary can do to your system.

---

j4mm3r said:
Dont worry about the example shown in the screen shot. That is just to illustrate what a setuid "sh" binary can do to your system.
Click to expand...
Click to collapse
this securing procedure isnt working on my new root any suggestions?
please
Regards,

---

bcool15 said:
this securing procedure isnt working on my new root any suggestions?
please
Regards,
Click to expand...
Click to collapse
Exactly what procedure are you referring to? The post is just meant to be a set of guidelines of a vulnerability that existed on the phone after it was rooted using "the root procedure" at the time this was posted.
If you have a "sh" binary on your phone which is setuid and setgid, then you have this vulnerability. I haven't updated the post with results from any new root procedures that have been posted since, but I suspect even the newer methods posted so far in the "root thread" don't get rid of the compromised "sh" binary.
Please ignore if you don't know what setuid and setgid means.