Hello I am trying to find out how is guid and UID assigned to a particular app in android. I know roughly what goes on in zygote and also that during package installation UID is assigned to that app, however I want to know where exactly this takes place and how ?
If anyone could point to the source files it would save a lot of my time.
I don't have a detailed answer for you, but you could start here:
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.3.5_r1/com/android/server/PackageManagerService.java#PackageManagerService.HandlerParams.startCopy%28%29
The PackageManagerService handles installation. I am guessing it delegates the task of setting the GUID, but it's a starting point.
Related
Other questions on this topic have been asked here:
Classes for Permission Checks Android
how are android security permissions checked at run-time?
How does Android enforce permissions?
But none of them answer what I am trying to figure out. I want to know where exactly I can find the functions or methods that literally check the permissions I'm requesting to see if I'm allowed to have that permission. More specifically, I want to find out what happens with Android Instant Apps permissions, since IA allows only a fraction of all Android permissions (the list can be found here https://developer.android.com/topic/google-play-instant/faqs).
For them there has to be a check somewhere, a whitelisting method that takes the permissions I'm requesting, understands that my application is an Instant App (rather than a normal one) and so it knows to check what I requested against that limited list only. That way it ensures I cannot ask permissions that are not even supposed to be allowed.
I want to understand and see where this happens, source code of these checks, especially for Instant Apps. I have started from the checkSelfPermissions() function used when implementing the Android Runtime Permissions. Through the function call trace feature in Android Studio and the xref (http://androidxref.com)
I went back as much as possible until I found the Context.java file (http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/java/android/content/Context.java) which has the prototype declarations with comments for each function.
public abstract int checkPermission(#NonNull String permission, int pid, int uid);
I just don't know where to find the definitions with the actual function body and code for it though. Context.java doesn't have them. And I think I am going more and more down a rabbit hole and a bit too low-level with these:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/java/android/content/pm/PackageManager.java#532
http://androidxref.com/8.1.0_r33/xref/frameworks/native/libs/binder/IPermissionController.cpp#39
http://androidxref.com/8.1.0_r33/xref/frameworks/native/libs/binder/IPermissionController.cpp#39
especially the last two, which not only do I not know if I'm on the right path with them, but I'm trying to figure out that remote()->transact function now and where it's defined, but we're in android native c++ territory now...
Any help or pointers would be immensely appreciated, it shouldn't be that hard to just go through the AOSP source code, right?
For future reference, in the end I have managed to solve it. It took way longer than I thought, but as it happens with most things, the answer was a lot simplier than thought.Turns out that yes, I was definitely going down lots of rabbit holes, but only up to a point. This whole process of search was actually useful in realizing where the answer would lie.
So the first step was successfully finding the actual proper, "low-level" implementations of the permission check or the permission granting action, and the functions are grantRuntimePermission and checkUidPermission, both in the PackageManagerService.java class. Here are the interesting bits, of each function:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java#5655
http://androidxref.com/8.1.0_r33/xref/frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java#5335
That is where the checks are being performed, but the system somehow already "knows" about the permission and that it is runtime or not, instant or not. The crucial bit (which also kinda hinted to me what eventually I found the answer to be) is to look at the BasePermission objects created.
I found that the Android OS treats permissions in a more modular way, where each permission, rather than left as a simple string to do a check against, gets transformed into an independent BasePermission object. This gives it a more defined importance, as these objects now contain, besides the permission name, attributes such as the sourcePackage name, permission type, UID that owns the permission, and most importantly, the protectionLevel, amongst others. Here is the BasePermission.java class:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/services/core/java/com/android/server/pm/BasePermission.java#23
It seemed that the BasePermission objects get created within each application, based on that application. So in the context of an instant app, the Android OS attributes the permissionLevel to each individual permission object accordingly as it learns the application is, in this case, Instant. Here is the important bit of code:
if (isUidInstantApp) {
BasePermission bp = mSettings.mPermissions.get(permName);
if (bp != null && bp.isInstant()) {
return PackageManager.PERMISSION_GRANTED;
}
} else {
return PackageManager.PERMISSION_GRANTED;
}
So it's possible to see how it creates the BasePermission object, based on permName, from a list/array of pre-created permission objects (mSettings.mPermissions) that the System somehow builds for the current application only. This only answers the "where is the permission check made?" question, but now the problem is "how does the system know how to create the BasePermission objects and assign to each of them the correct protectionLevel?". Initially I was completely unable to find where the "mPermissions" list gets populated. Then it hit me: I didn't actually need to know that.
All Android permissions and their names are defined in the global AndroidManifest.xml file. Whenever you use permissions in your application code, you call the Manifest.permission.PERMISSION_NAME string, right? I thought that the manifest would only contains the names of each permission, declared as a string. What I didn't expect was that the only other tiny piece of information the manifest declares is (you guessed it)... a per-permission protectionLevel value. For each permission it would state if it is a "normal" permission as opposed to the "dangerous" ones, as well as if it can be used for instant apps or not. And as expected, only the 10 (at the time of this writing) defined permissions for instant apps from the official docs had the "instant" attribute beside the other available protection levels. Here's one of them:
http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/res/AndroidManifest.xml#773
That is how the system knows to build the BasePermission objects, wherever it does that. And there was the whitelisting that I was looking for.
Even if I did look at the manifest as first step in my research, I probably wouldn't have known that the answer was right there in front of me. The knowledge of BasePermission objects was crucial to understand how the permission model and checks are implemented.
Next step now would be to actually find where exactly the system creates the base permission object based on these protection level strings in the manifest. I am guessing there should be an association of those strings to a binary integer such as "normal" or "normal|instant", number which is then used by the BasePermission class to construct the objects' protection level and ultimately define if they're instant.
is it possible to retrieve all the data that the app has accessed in your phone and print it out? For instance the app retrieve my imei, my location and I would like to print it out to a log, like imei:123456789, location: 40° N, 74° W.
I know that in xprivacy it is possible to manually check what have been accessed and restrict the access to some information. But I'd like to know if there's an app or an alternative already to export the data in that matter.
Thanks and happy new year.
Not really. Technically, there are a couple of ways you might get quite a lot of the information, but they aren't very practical.
For example, if you had sufficient privileges, you could monitor your app with strace. This would catch kernel calls. The kinds of data access you're talking about would all involve system calls. Or you could straight up debug an app and gather information that way (not at all practical).
Making that information available constantly would kill performance, so it's not something you can get at normally.
I'm looking for a way to get the current active user in Android. I'm building a system app so I can use hidden methods, but specifically it has to be the current ACTIVE user, and not the user for a given process.
For instance, if you install an app using ADB the process is going to say the user id is the owner. This means that UserHandle.myUserId() will not work for what I need :(
So I found a method that does exactly what I need it to do. There is a static method in ActivityManager that is hidden (so you need to work some magic to have access to it) but here it is:
ActivityManager.getCurrentUser();
That's all there is to it.
I'm investigating the possible ways of obtaining superuser privileges in a Java Android application and/or its own JNI. The well-known answer seems to be that it's only possible to run a "su" subshell and command line commands from there, which is neither neat nor very practical. I am willing to accept this resolution but still I'd like to hear an opinion on this "what if" scenario.
Reading through Android sources near java.com.android.server.am.ActivityManagerService, java.android.os.Process and the dalvik_system_Zygote.cpp file, it seems to me that during application launch, the application record is examined for the UID and (a list of) GID(s) and all these values are passed to the Zygote through a socket. Z subsequently picks the data up and passes it, without further checks, to setuid() posterior to a fork() call. Therefore, it seems to me that if the Activity Manager pathway was altered, a simple passing of --setuid=0 and perhaps --setgid=0 to the Zygote socket should result in running my Activity with the root UID.
It all seems almost too simple, I suspect that something would go wrong along the way. Unfortunately, there's too much code and new stuff for an inexperienced programmer like me to actually go and try. Has anyone gone this way, or is there any obvious reason why this would NOT work?
I think I just found the answer to my own question. Credits go to #Chris Stratton who pointed me at using the emulator and also pointed out how ridiculous a situation this would be.
The key was in one place where I did not look, between sending commands through the Zygote socket and the Zygote binary itself. The point where the check takes place is com.android.internal.os.ZygoteConnection, method applyUidSecurityPolicy. If the caller process belongs to root, the UID of the spawn may be indeed requested to be zero (or anything else, for that matter). A regular user may use the socket as well but asking for a new UID or GID results in a ZygoteSecurityException.
I am getting started on Android & iOS development and hence links to relevant resources will also be appreciated, just that I couldn't find anything much relevant.
Case Detail: I have to build an app that holds some critical information in a variable that is created, sent over a ssl-encrypted connection and destroyed. This variable shouldn't be read by any other process on the device. So far, I know of two cases that can happen:
[1] a service or program monitors the foreground app(which here would be my app) and then if it can inject some code(getting the foreground to bind to the rogue service for example) to read off the variable contents in question. I know OS safeguards exist, but are there any proofs out in the wild that demonstrate this ability of injecting code?
[2] a service or program monitors the network connections and logs the data being sent over the wire. Is there a possibility of apps reading network data like this? I know apps exist which can log the amount of data exchanged per app, but I have no clue as to whether they read system log files or actually monitor the connection.
It will be appreciated if details could be provided for both the platforms.
I work only with android, so this is valid for android only:
No, a service cannot inject code in foreground up, due to (at least) 2 reasons:
Each installed application gets it's own user id, and each process, and their data is protected by the user id. So one process cannot access the memory of another process. So no process can modify the memory either (by inserting code)
The java bytecode is converted to dalvik code, and stored in a place where only the system process can write. So no other process can inject code by changing the compiled dex files.
That is the protection provided by the system. Of course hackers might find an exploit in a certain library, and using buffer overflow might be able to run some snippet of code, but that's a different story. Also note that the data files of the process are private by default (no other process can see it), but processes could have read access to the code. Which means storing private keys in the code is probably not safe.