Okay, so I was looking for something like answered here. The only problem is I've been looking at that zygote fork code but I have no idea what is going on. I'm trying to figure out where exactly permissions are enforced for native method calls in Android. More basically, I want to know how the Linux Kernel is enforcing permissions. Something like enforcePermission() which I've seen in some of the android source code, except I want to know where it is at the kernel level. If someone can point me in some sort of direction or make sense of what that zygote fork code is doing I'd appreciate the hell out of it.
If that doesn't make sense it's probably because I'm an idiot or something.
Thanks!
What that post says (which is true) is that there is no special enforcePermission()-style call for native code: each permission granted effectively translates into a specific supplementary group id. Individual permissions checks are performed either using the standard Linux permissions/capabilities model, using specific code in IPC routines (so for example when you bind to certain services the services can check the calling processes membership in the appropriate group) or using specific patches the the kernel/libraries (for example network permission is explained here).
Related
I want to call functions provided in com_android_bluetooth_hid.cpp in android source from my own app. Target Android versions are >=4.4 and <=5.x. I understand JNI, and can compile my own code and call from my own app.
Would it be possible to call android's library from my app? How
Also, to call functions in that specific cpp file, are BLUETOOTH and BLUETOOTH_ADMIN permissions sufficient or something else (other permission, or root) would be required?
The cleanest way to call Android's CPP code is, generally, copying the relevant pieces to your repository and building as part of your app. Following this approach, your app will only call the public APIs - either Java or C/C++.
But this may not be relevant in cases when this code must run with special permissions, as system service, like mediaserver or Bluetooth stack.
I am afraid that the code you wish to run belongs to this second category, therefore none of the available tricks will not help.
On the other hand, a custom ROM may be a solution you are looking for. It may happen that you don't need to forge a full system. It may be enough to use a rooted device and replace the bluetooth service with your custom one.
I would still advise you to provide the missing callbacks for the service, instead of calling the functions directly from your app: you better not mix contexts between a user-space app and system service.
I've got the source code for an Android app and its manifest includes a lot of uses-permissions, some of which I think it doesn't need. Aside from testing the whole app, is there an easy way to find which classes or methods use a specific permission?
delete all permission in Manifest, then run App. Then the logcat will show you what permission needed.
As this paper points out, the API documentation is frequently wrong about which permissions are needed, and many application are 'over-privileged' meaning the manifest declares permissions which are not necessary for the classes and methods used.
Unfortunately, the Stowaway tool described in the paper is currently off-line, and I know of no other tool that is specifically designed to perform the analysis you're looking for. One problem with such a tool is that the method->required permissions mapping must re-accomplished based on the Android source code every time a new version is released. The paper is based on Gingerbread and obviously a lot has changed since then. Maybe they are having trouble keeping it relevant.
So at this point, the quickest way to do a one-off check would be to remove all of the permissions and then add them back one-by-one based on the security exceptions you see in the logcat.
How does Android perform security checks on native code? Suppose we declare permission X in AndroidManifest.xml, does it mean we inherit that same permission X in our native code?
How does Android perform security checks?
There are basically two ways the permissions are enforced.
First of all on kernel level: each installed app is assigned a unique (linux) user id and each time your app is started Android will spawn a process and sets the user id of that process to whatever your app userid is. Now accessing e.g. the filesystem or certain hardware features like network is enforced by using the standard linux group permission system. E.g. access to network is only allowed for a network group and your app user is part of that group if you request the network permission in your manifest.
Security in userspace like accessing certain ContentProviders or sending broadcast messages and so on simply can't be relayed to the OS. So once you call a method from either Java or native code you can be (pretty) sure that there is some software check in the end that ensures that you can't do things you have no permission for. The NDK API will most probably simply call (maybe indirectly) some Java method so there is probably no need to have separate checks for native and Java code (but Idk exactly how that is done).
It is likely that you can circumvent some of the Java checks by using native code like networking on the UI thread should work (if you have the network permission). It is also possible that there are loopholes that can only be exploited by using native code but that should be rare. It should not matter in the end what type of code you use.
#user827992
the NDK just produce some digested machine code for the dalvik, there aren't API available in C/C++ for Android; you don't have a problem about using a particular set of API that requires a certain permission because you simply can't even code that and access the API in the first place.
Not true, native code written in C/C++ is at compile time of the app compiled in native machine code for the CPU and at runtime executed directly by the CPU, no dalvik involved. You get back to dalvik if you call some Java method via JNI (through the NDK API) though.
Also there is a lot of Android API available through the NDK, thats the reason it exists.
According to the "Android logic" there is no point to do that for at least 2 reasons:
you always need to code some java lines to make your app, so your entry point will always be the java language and your java app; you can't do an apk with only C/C++ code.
the NDK just produce some digested machine code for the dalvik, there aren't API available in C/C++ for Android; you don't have a problem about using a particular set of API that requires a certain permission because you simply can't even code that and access the API in the first place.
In the end just think about an android as a java application where you can code in C/C++ your own business logic for the heavy computational stuff, everything that Google provides you in terms of API and policy is supposed to be related only with the Java language.
What is happening under the hood? somehow this is passed down to the OS, and someshow the OS will find the right activity / activities, and launch it? Is there a service / lib running in Android handling this? I am trying to modified the OS to override the logic of startActivity across the board, is this possible?
Thanks.
I would take a look at the Android source! Whenever I'm developing and I run into an issue I read through the source to discover what is happening under the hood; it's quite interesting! It's an insight into what's actually going on, and also very good guidelines for documentation and code formatting!
http://source.android.com/source/downloading.html
A good starting point might be ActivityManagerService
Basically, when an app is first launched, startProcessLocked() in ActivityManagerService creates a new ProcessRecord (if necessary) and then calls Process.start(), which in turns builds the arguments for zygote and sends to zygote's socket using zygoteSendArgsAndGetResult(). Of course there's more to it than that, for example if an app shares a uid, is isolated, etc. But that gives you the basic process.
Looking over the source is indeed a good way to understand what's going on. However, unless you're planning on modifying it, don't bother downloading AOSP, just use GrepCode. Easier to browse, search and everything is hyperlinked so it's easy to follow through to classes, find usages, derived methods, etc. If you download AOSP, you'll be stuck with grep, ack-grep if you're lucky and a text editor. Also, you'll only have the one version you picked to checkout. GrepCode has the code for almost every version since 1.5.
The linked text above will take you to the relevant source at GrepCode. Try it out! The only downside is that GrepCode doesn't include the native C++ layer.
A coworker and I were talking (after a fashion) about an article I read (HTC permission security risk). Basically, the argument came down to whether or not it was possible to log every action that an application was doing. Then someone (an abstract theroetical person) would go through and see if the app was doing what it was supposed to do and not trying to be all malicious like.
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing. Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
Can I get some input one way or the other? Is it completely impractical to even attempt to log what a foriegn application is doing?
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing.
Not so much "hack Dalvik" but "hack the android.* class library, and perhaps a few other things (e.g., java.net).
Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
You might be able to do some fancy pattern matching or something on the output -- given that you have determined patterns of inappropriate actions. Of course, there is also the small matter of having to manually test the app (to generate the output).
Is it completely impractical to even attempt to log what a foriegn application is doing?
From an SDK app? I damn well hope so.
From a device running a modded firmware with the aforementioned changes? I'd say it is impractical unless you have a fairly decent-sized development team, at which point it is merely expensive.
This is both possible and practical if you are compiling your own ROM. Android is based on Linux and I know several projects like this for Linux, like Linux Trace Toolkit. I also know of research into visualizing the results and detecting malicious apps from the results as well.
Another thing functionality like this is often used for is performance and reliability monitoring. You can read about the DTRACE functionality in Solaris to learn more about how this sort of stuff is used in business rather than academia.