Clint, It depends on what you view as an "API call". Your example leads me to believe you want to include access to content providers. For completeness's sake, let's assume you mean all "method APIs" and all component IPC.
I view the ActivityManagerService as the main reference monitor for component interaction. It enforces the protection policy in the different package manifest files. Therefore, I'd start with the manifest files. For example, you can get a mapping between a content provider's authority string and the read and write permission strings. You can also start mapping the action strings in intent filters to access permissions. You may or may not want to consider the other intent filter properties that influence component resolution, e.g,. category and data mime-type. Second, there are a number of APIs that have their own "checkPermission()" calls. You can only find these by looking at the source code. I'd start with grep in the Android source code. From there you'll have to work backwards to the specific API call. You may find many of these are RPC methods for service components included with the core system. Note that to be complete for a specific phone deployment, you need to have knowledge of all applications installed on the phone. Third-party apps can define new permissions and new "APIs" with their service components. Third, some permission enforcement is performed with gid checks by the underlying OS. Android has a configuration file (somewhere) that will add an application to different gid's based on the permissions granted at install. For example, this is how the INTERNET permission is enforced. There aren't many of these, so I'd just run through them by hand. Finally, don't forget about Android's "protected-broadcast" functionality. You may remember the creation of the BROADCAST_SMS permission. This was created to keep a rogue application from forging SMS arrival on the phone. In reality, this attack is more pervasive than SMS (and the few other "broadcast" permissions defined in Android). When reading through the ActivityManagerService code (not sure if it's documented anywhere), I ran across the code enforcing "protected-broadcast"s. It turns out that in one of the core AndroidManifest.xml files, there's a list of "protected-broadcast" definitions, that according to my understanding of the source code ensure that only the system can broadcast. It's a bit of a hack from the original permission model, but it seems to be easier to manage, as it doesn't require third-party apps to protect their broadcast receivers with permissions (something they most likely will forget to do). Hopefully I didn't forget anything. Android's security enforcement is scattered about and difficult to capture if you want to model it formally. For example, I haven't even mentioned the delegation provided by URI permissions. If you're interested, I wrote an article for IEEE S&P magazine (Jan/Feb 2009) that has a bit more detail. Good luck! I'm interested in seeing the policy map you create. I can think of a lot of really cool uses for it. -Will On Oct 26, 2010, at 2:21 PM, Clint Gibler wrote: > Hello, > > I would like to correlate series of API calls with the permissions > required > for the code to execute properly. A simple example of this would be > seeing: > > Cursor c = getContentResolver().query(Contacts.CONTENT_URI, ...); > > and knowing it requires READ_CONTACTS. Many cases will require > considering several statements rather than one and possibly tracking > the > values of variables that get passed into the API calls. > > There are two ways I was thinking about gaining this information: > 1. Reviewing the source of existing applications and examining both > the > permissions they require and the specific code that exercises that > functionality. However, this is limited to the permissions used in > applications of which I have the source. True, I could create > prototypes > that use every permission, but that would be very time intensive. > Furthermore, a greater problem is that there are a large number of > ways and API calls that require a given permission. This approach > would not be a good way to capture all the ways an application can > (for example) read the contacts. > > 2. As permissions need to be enforced to work, I thought there might > be > some place in the Android source that checks if an app should be > allowed > to complete the current API call based on its permissions. Previous > threads > pointed me towards ActivityManagerService.java. However, the > PermissionController class defined in it does not seem to contain the > correlation > information I seek. checkPermission() and other functions appear to > primarily > check the uid and pid of the current application against a permission > string, > there's no <this function> with <these args> needs <this permission>, > as I > would like. > > Is there a better / more complete way of finding out this correlation > that I > haven't considered? > > Thanks for your time, > Clint Gibler > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > -- William Enck PhD Candidate Department of Computer Science and Engineering The Pennsylvania State University [email protected] -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
