Starting with Android 4.4 SELinux's MAC is enforced. Does this mean that if an app somehow can get installed and exploit the kernel to get root privileges, that MAC will still prevent that app with root privileges from accessing private app data?
Android Documentation says: "SELinux can be used to label these devices so the process assigned the root privilege can write to only those specified in the associated policy. In this way, the process cannot overwrite data and system settings outside of the specific raw block device." source - http://source.android.com/devices/tech/security/se-linux.html#use-cases
As a reference I am implementing a Mobile Device Management system and in the process I have to determine how secure Android OS is itself. That is why I need to know how secure corporate data stored on a device is to root-kits, spyware, and other malware.
p.s. This has been posted on the "Unix and Linux" StackExchange site with no one being able to answer yet. I'm hoping XDA's hands on experience with the Kernel will be able to help get this answered, Thank You .
milleraj66 said:
Starting with Android 4.4 SELinux's MAC is enforced. Does this mean that if an app somehow can get installed and exploit the kernel to get root privileges, that MAC will still prevent that app with root privileges from accessing private app data?
Click to expand...
Click to collapse
The answer is: "It depends."
Mandatory access controls systems like SELinux are very good at constraining application behavior to what is allowed by the security policy. In many cases, it can eliminate huge chunks of security vulnerabilities by sandboxing privileged applications so that exploitation of those applications is ineffective.
You may want to take a look at http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf, specifically slides 7-9. This will give you an idea for what SELinux can and can't defend against.
Related
Hello XDA-Forum users,
I ask you a question: How does Android Root works ?
I mean, for example, How does it works in Nexus One ?
This would be an understanding question to know more about how I get root from my Phone (Nexus One, for example) from scratch, from sources.
upupupupupup
Rooting basics:
http://lifehacker.com/5342237/five-great-reasons-to-root-your-android-phone
For details on how to do it on your device, Google or use the forum search. Lots of rooting information that is device dependent out there.
It basically gives your phone permission to do almost anything. It is similar to giving a user in Windows Administrator rights. It is called super user. You can do many things such as removing unwanted apps and overclocking.
This is not what I mean, I asks for an explaining in which the question is "How the root is possible? What active the root ?" Probably a kernel exploit, or stuff like that, to understand the underground passage to take it, from an hack view.
So, How works a root utility (such SuperOneClick) to set gid to 0 ?
Valid question, I am also interested in learning this.
In other words, if I were to perform the rooting manually, where can I find such info?
And some of the question is why su must be in some diredctories, and can't be run from /data/local/tmp for example?
Someone can enlighten us?
diego.stamigni said:
Someone can enlighten us?
Click to expand...
Click to collapse
The general approach is taking advantage of bugs in the android OS
The process works something like this
User crafts some special data that contains a "payload" (the script/executable that we want to run)
User runs a system process that has root privileges and gets it to open the special data
The bug causes the system process to get confused by the data, and ends up running the embedded script
The embedded script runs with the same privileges as the system process, and thus can stuff that normal users aren't allowed to do (e.g. installs the SU app)
Commonly, things such as buffer overflows are used
So after gaining root access, which apps can run as root?
Or the user becomes root(as in desktop), and can run all types of apps?
Can root app(run as root) access everything?? Or app permission still applies?
Is it that system exploit is always used to run root apps?
can someone explain in technical details? not how to root.
are rooting programs open source??
What is the root procedure
Bayint Naung said:
So after gaining root access, which apps can run as root?
Or the user becomes root(as in desktop), and can run all types of apps?
Can root app(run as root) access everything?? Or app permission still applies?
Is it that system exploit is always used to run root apps?
can someone explain in technical details? not how to root.
are rooting programs open source??
Click to expand...
Click to collapse
Hi guys!
I have the same question and after searching and asking find this!
it is good!!
hope it works!
http://stackoverflow.com/questions/...hat-are-the-pre-requisites-for-it-to-work-wha
also look at the suggestedpages at the right of this page!
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 ?
Has a write-up ever been released on exactly how SuperSu works? After searching around for a while I found mostly guides on who to use the app, no the implementation details.
I did, however, find this official resource that is mostly directed at explaining how to use the root privileges programmatically, but explained things fairly well. The article gives information about SELinux, but not so much how its enforcement is circumvented.
There appears to be a lot of context switching to allow execution of certain events (from the point of view of those using SuperSu) otherwise denied under SELinux, but how did SuperSu get to the point at which it was able to "legally", as far as SELinux is concerned, patch SELpolicies?
It seems that the objective is to force the init process to spawn a new shell that runs the su daemon, but there does not appear to be any patching of the init process, but from the article linked:
On firmwares that use SELinux, su is generally implemented as a proxy to a daemon started from init
Click to expand...
Click to collapse
and
You might wonder why - if we're already running as the init context, as the root user ..
Click to expand...
Click to collapse
-------------------------------------------
tl;dr; How does SuperSu execute in the context of the init process?
Given as:
u:r:init:s0 - Highest init context
u:r:init_shell:s0 - Shell started from init
Click to expand...
Click to collapse
SuperSU does not provide root privilege. Root privilege exists or it doesn't. Someone more knowledgeable can explain it better than I can, but either you have access to the system partition (root), or you don't. What SuperSU and similar apps do is act as a gatekeeper for other apps that utilize root access. Primarily to allow or disallow apps, or certain functions within apps, to do whatever it is they do. And of course, it's also a safety precaution against malware, because malware with root access can cause serious damage.
As for the other questions, I'm not the one to reply; that stuff is beyond me.
OEMs use root/admin and then lock it away like on Linux so Its SuperSU tht is the admin and grants root*admin permission
Planterz said:
SuperSU does not provide root privilege. Root privilege exists or it doesn't. Someone more knowledgeable can explain it better than I can, but either you have access to the system partition (root), or you don't. What SuperSU and similar apps do is act as a gatekeeper for other apps that utilize root access.
Click to expand...
Click to collapse
This is likely misunderstood by many. You are thinking of the SuperSU app that can be downloaded from the app-store. In this regard, you are correct in that it manages root access. However, the application portion of SuperSU is only the front-end; there is an entire back-end solution to SuperSU that patches the system to achieve elevated permissions to be managed by the front-end in the first place. Check out the write-up linked in the OP.
arshad145 said:
OEMs use root/admin and then lock it away like on Linux so Its SuperSU tht is the admin and grants root*admin permission
Click to expand...
Click to collapse
This sounds like a plausible method, but I did not see any mention of this in the article linked in the OP. Could you provide further details or sources for your thought?
Android uses *linux* based kernel
So I know the root part is true but for the OEM just a guess ;p
---------- Post added at 19:07 ---------- Previous post was at 19:01 ----------
If you want to learn more about root just use a linux and go explore its deepest secret
Can be tricky to learn about the function of linux kernel but android is more or less the same
*Simplified description*
arshad145 said:
Android uses *linux* based kernel
So I know the root part is true but for the OEM just a guess ;p
---------- Post added at 19:07 ---------- Previous post was at 19:01 ----------
If you want to learn more about root just use a linux and go explore its deepest secret
Can be tricky to learn about the function of linux kernel but android is more or less the same
*Simplified description*
Click to expand...
Click to collapse
I have used Linux for some time now. It is not the architecture of Linux that I am curious about, though.
You are correct in that root access is locked away in most production phones. This is done simply by allowing the user of the phone to execute as a separate user with lower permissions. SuperSU somehow patches the system to execute a daemon in the same context as the init process, which presumably has the most privileged access from the set of contexts. I am wondering of the architecture of SuperSU such that it is able to achieve this execution.
Oh my sorry for misunderstanding :/
but no idea for SuperSU privilege accesses or loop
but if you debug it on pc u can find something?
*Hopefully*
:fingers-crossed:
---------- Post added at 19:29 ---------- Previous post was at 19:23 ----------
One thing am curious too
Why can't superSU gain permanent root unless bootloader is unlocked???
Like if there is OTA update root is gone unless bootloader unlocked ...
WHY?!
**Curious**
arshad145 said:
One thing am curious too
Why can't superSU gain permanent root unless bootloader is unlocked???
Like if there is OTA update root is gone unless bootloader unlocked ...
WHY?!
**Curious**
Click to expand...
Click to collapse
As far as I know, when a bootloader is "locked" is prevents any sort of reflash of the device unless you otherwise provide some kind of proprietary key (.e.g. to authenticate genuine OEM updates). So, you first need to unlock the bootloader in order to flash a custom recovery, which then gives you support for patching the system with the necessary SuperSU files.
Presumably, just as an educated guess, when you receive a genuine OTA the core patched files for SuperSU are overwritten, thus disabling your prior rootkit.
SuperSU is closed source. Just curious to see if anyone has any background knowledge of its implementation.
It seems not. Although this is disappointing, it was somewhat expected.
hello,
sorry if this isn't the right place to ask this question, and please redirect me, this is a fairly huge site.
I know this question has been asked many times, but I didn't see a clear answer to it from security experts, or it is from several years ago and things might have changed.
My question is double:
first of all, nowadays, how does the process of rooting an android phone work (please detail if there are various alternatives) ? Does it rely on a security hole, or is it a kind of attack (such as physical access to the device) that is not part of the security perimeter of android ? In the first case, why is it that it's not fixed, as there are open bounties for the android system ? Note that I'm just talking about the android system itself (such as a Nexus Phone), with the latest patches.
Second related question: What would be the security risk of rooting an android phone ? If I am not mistaken, these could be grouped in at least two issues: the rooting process itself, and the aftermath.
a. Regarding the rooting process, is there any open source procedure (or at least closely reviewed) to root a nexus phone that could guarantee that there's no malware installed in the process ? (see also first question)
b. From what I understand, having a rooted android is no different than having a linux OS with a root account. Are there any (free, open source?) apps that can monitor (what commands have been launched, etc) and prevent apps from getting access to the root account without my agreement ? (so that it is linux OS where any account that requires root privileges must go through 'sudo' and ask the user to enter their password).
Please tell me if I'm asking in the wrong part of the site.
"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