1. Group Members List
Matthias Bahlke (mbahlke@mit.edu)
Ellen Finch (finche@mit.edu)
Carter Huffman (whuffman@mit.edu)
Chrisantha Perera (cperera@mit.edu) 

2. Motivation
	Android permissions currently are well-designed for an ecosystem comprising of clever, aware developers and for permission-aware users. System resources are turned “ON” or “OFF” but there is no middle ground. Although the burden of verifying app security could be something that an end user should address, it isn’t something that the average Android user considers when downloading an app. It is also particularly difficult to verify security because apps request permissions opaquely. They do not justify their request for permissions; it is simply up to the user to determine whether Words With Fools really needs the location data it is requesting. Furthermore, some phones that build on Android even introduce security vulnerabilities by adding unnecessary “bloatware;” phone manufacturers and networks in particular are quite dedicated to adding unsafe applications that cannot be removed from phones. Users may be shy of “rooting” their hardware due to the fact that installing custom ROMs voids the phone’s warranty, but this is one of the few effective methods of determining permissions delegation strategies.

We think that mechanisms that exist at the OS level could be better utilized for end users and developers to verify the privacy of the information they are sharing. In particular, sandboxing apps and providing them with varying sets of data (possibly generated by a user) might allow a finer granularity of permissions delegation. For example, if an app requests Location data, the user may not wish to grant this because then the app provider will be able to gain a wealth of information about the user, up to and including where they live, where they work, etc.  Thus, one might want to spoof their location in order to allow the app to still work, but to still protect their privacy. There currently exist attempts to create granular permissions for Android OS, such as Cyanogenmod’s Privacy Guard and Google’s AppOps; but these systems require rooting one’s phone (the former) or haven’t been fully integrated into Application development and user access (the latter). There is also some work that has previously been done in the space. 

3. Previous work
We examined three pieces of previous work that use custom ROMs: “TaintDroid,” “TISSA,” and the CyanogenMod ROM’s “Privacy Guard.” We also examined one resource that is soon going to be part of the Android source, called AppOps. Our project is intended to demonstrate the need for Android integration of additional useful privacy guarding practices and tools.

TaintDroid (http://appanalysis.org/) is a system meant to help developers and security analysts evaluate information leaks in Android Apps. It does so by providing “realtime privacy monitoring on smartphones” using the “tainting” of sensitive information. If TaintDroid were included in every Android system, it would be more likely that Users would realize the necessity of being security-aware. In TaintDroid, data provenance is tracked when passing information or using it. As the site states though, “to use TaintDroid you must flash a custom-built firmware to your device, similar to a number of popular community-supported Android ROMs.”

TISSA (http://www.cs.ncsu.edu/faculty/jiang/pubs/TRUST11.pdf ) is a system designed to interpose between apps making request using systems permissions and the retrieval of that data. It provides essentially the functionality that we were interested in, sending real, bogus, anonymized, or no data back to the requesting app. Unfortunately, in order to provide this functionality, the TISSA authors had to modify the Android source to reroute requests using systems permissions to go through their modified request handler. We wanted to do something very similar to this, but without the requirement to modify the Android source, since using a modified source requires rooting the device.

AppOps is a Google-supplied tool that is included in the most recent version of Android, but is inaccessible to the user without a third party app to simply call the manager. It is intended to allow users to modify the permissions settings for apps that it has installed, so for example if an app that was installed with the Location permission but doesn’t actually need it the user can revoke that permission. However, this feature is not fully functional due to its limited accessibility, and the API is not really intended for third party use. In fact, as of December 13, 2013 it has further been hidden from users. Google’s official justification for this change is that AppOps was meant as an internal development and debugging tool never meant for users or third party developers.

For users who are not concerned about rooting their devices, Cyanogenmod, a custom ROM can provide much of this finer-grained control through its Privacy Guard feature. However, once again, many users do not want to root their devices because of the warranty, so it is important to provide solutions that do not require this.

4. Our App

We built an app called Sandbox, that receives requests for system-permission-requiring data and returns a user-specified result to the requesting app. The settings the user can select for a Sandboxed app are Real, Bogus, Custom, and for Contacts, Name Only. If the user has selected Real for this permission and this app, then Sandbox (which does have the permission to read this data) gets it from the OS and passes it back to the Sandboxed app. If the user has selected Bogus, Sandbox returns a random value (currently completely random; in a real version this would probably be randomly generated attributes of the object or value requested). For Custom, the user is supposed to input a string that is the value they would like returned. Name Only means that the Sandboxed app can get contact info, but only see names, not names and numbers. The Custom option is a unique feature of our solution; in all of the previous work that we saw, no option to provide your own values to certain applications was included. We think that this is a particularly useful option to include, because only being able to allow an app real or nonsense data is fairly limiting to the user.

To demonstrate Sandbox, we created a couple of smaller apps, AppA and AppB, which simply have buttons to request various data values from Sandbox. By running both AppA and AppB but setting their permissions differently, you can see how Sandbox controls access to data. We also modified an open-source app to use Sandbox instead of system permissions to access location data. The app is called GPS Share (package Sharelocation), and its intent is to allow the user to send a text or email message to someone which includes a link to a google map centered on their gps coordinates.  By overwriting the code that GPS Share used to fetch the location from the phone with code that requests the location from Sandbox, we successfully integrated our Sandboxing service with a real-world app. (Note: the modified GPS Share source code is included in the project source code that we submitted.  If you want to run this app, you will need Google APIs installed [if you’re using eclipse: Go to Window, Android SDK manager, Android 4.4, and click on Google APIs].  You will also need to use an emulated device with Google APIs enabled, which is an option in the Android Device Manager.  Also, note that the maps do not show in the app because the emulator cannot fetch them from the internet - but it still accomplishes its main purpose of sending texts using your location data).
 
Our solution was limited by the fact that we didn’t want to require root access, so we couldn’t build anything that interfered with system permissions on an OS level. This means that our Sandbox app cannot force anything that isn’t written to use Sandbox to go through Sandbox to get information. In order to build in additional provenance guarantees, we could use a ROM incorporating TaintDroid’s source code.

A more complete solution would be something like Dr. Android and Mr. Hide (Dr. Android and Mr. Hide: Fine-grained security policies on unmodified Android - http://drum.lib.umd.edu/bitstream/1903/12852/1/CS-TR-5006.pdf) which includes a rewriter in addition to a sandboxed supply of data. We felt that this was too wide a scope for our project. Our design as is would be primarily useful if it became well enough known that an app developer could advertise their app as able to be Sandboxed, in which case they would probably do that so long as they consider themselves trustworthy. Data thieves would be less of an issue for users, because their app would still work but users would feel more secure and thus more willing to use the app.

5. How it works
The interaction between a Sandboxed app and Sandbox is as follows: 

When the Sandboxed app is opened, it sends a broadcast message to Sandbox (labelled with a Sandbox-specific signature permission so that only Sandbox can receive it) containing its name and a permission label that Sandbox should send its data back under.

When Sandbox receives a (name, broadcastLabel) pair, it checks to make sure that it has nothing with that label already stored, because no two Sandboxed apps should be able to receive each other’s data sent from Sandbox. If there is no such collision, Sandbox saves the name and broadcastLabel and creates permissions settings entries with the default Bogus setting.

When a Sandboxed app requests a piece of data, it sends a broadcast message to Sandbox (again, permission-labelled so as to be only to Sandbox) with its name and the data type it wants. Sandbox checks the permissions settings it has for that app and sends back a broadcast, under the broadcastLabel permission it has saved for that app, containing the requested data.

6. Assumptions
As is clear from the previous section, there are some serious assumptions being made about the trustworthiness of the Sandboxed app. Sandbox is neither intended to nor able to fully protect a user from developers who are deliberately trying to take advantage of them. If an app lies about its name or sends a broadcastLabel that is not unique to itself, then data can be leaked. The assumption that we make is that unless an app is trustworthy, the user will not elect to give it full access to their data.

An advantage of our system is that data leaks require a pair of apps to be conspiring together. A single app can never fool the system into making the user give it excessive permissions (unless it would have been able to regardless of the Sandbox), because any single app cannot act to give itself a false name or a useful false permission setting. 

The primary danger in our system is an app giving a bad broadcastLabel, since this is what restricts access to the data sent back from Sandbox. If an app uses a permission that is not limited to that app, then other apps with that permission can listen in and steal the data. Alternatively, if a pair of apps give swapped broadcastLabels relative to their actual permissions, then the user might give one of them more access than the other, but because of the swapped labels the data would go to the opposite app instead of being delivered as the user expected. As stated in the intro to this section, our assumption is that a user will not give sketchy apps full access to their data.

A trustworthy app’s data can never be stolen by an untrustworthy app if the trustworthy app is set up correctly. This is because the label the trustworthy app shares is supposed to be a signature permission, which can only be held by other apps by the same, trustworthy developer. Thus, broadcasts to this app can only be heard by this app. If a different app lies about its label and claims that it should be sent broadcasts under this permission, it won’t matter since that app won’t be able to receive those broadcasts.

6. Future Work
Sandbox is currently rather feature-limited and as can be seen from the above sections, has limited security guarantees. Future work on Sandbox would obviously include the implementation of more permissions (currently Sandbox implements read location, profile, IMEI, carrier, and contacts). We could put it in a ROM, but honestly we just wanted TaintDroid and/or TISSA to be in the default Android Source, but in such a manner that a developer could access it.

The security problem is unfortunately difficult to solve without rooting the device, as tracking data provenance at a system level requires system permissions in any case. TaintDroid does allow some testing of inter-app information sharing, so including it in the source as well could solve any In any case, we must remember that Security is a negative goal; an objection might be that it’s a bad idea to put all this power into one small, sandy box per app. We would argue that the box may be sandy, but at least it’s easier to keep contained.