Dianne and Will, thank you for your responses and pointing me towards some other resources.
Let me try to clarify what I meant by "API call," because upon reflection that may not have been the best term to use. I meant anything in an Android app that requires a permission to complete execution (to simplify, only considering Android-defined permissions, not app developer defined). So I want to include any code accessing content providers, URI's and all relevant component IPC. In both ActivityManagerService and PackageManagerService I've mainly just seen checks if a given gid or uid has a specific permission string. What I want to know is how Android knows which permission string to check for. Somewhere before the low-level "does uid/gid X have permission Y" check there needs to be something that says, "Ah, the app is trying to do X. What permission does it need for X to complete?" and then from there the user or group can be verified to contain that permission. This is what I would like to find. Though ideally I would consider permissions created by app developers and analyze the possible interactions between apps given their individual permissions, for now I plan to analyze one app at a time in isolation. Will, thanks for contributing work that aids users in understanding Android, I found your article in IEEE S&P magazine as well as TaintDroid and "Semantically Rich Application-Centric Security in Android" very useful. -Clint On Oct 28, 6:22 am, William Enck <[email protected]> wrote: > 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 > > athttp://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.
