Application Confinement
When we started thinking about how to design the security infrastructure in Ubuntu Touch, one of the important criterias was user privacy. For Ubuntu Touch, and the converged desktop in the future, we are moving from a model where people install software provided in an archive maintained by packagers to a model where applications get uploaded by the authors themselves directly into a software store. While this allows users to quickly gain access to the latest and greatest applications, it also brings with it a new problem: how to prevent malicious applications from stealing the user’s private data.The traditional archive model in Ubuntu is based on trust, barrier to entry, and time. In order to get something uploaded or modified in the archive, a developer needs to demonstrate trustability by contributing a significant amount of work before upload rights are granted. Learning how to create and modify packaging, and successfully getting contributions sponsored is complex, time consuming, and is a barrier to entry. Once a package does get uploaded or modified, it is generally done in the development release. This allows a package to be in the archive for a certain amount of time before it becomes part of an official release. Hopefully, if something malicious does make it to the archive, it will be discovered in the development release before it gets published in an official release.
This long and complex process results in a software archive that can be trusted, but prevents software developers from being able to quickly get new versions of their software into the hands of their users. One of the goals of the Ubuntu Software Store is to allow a software developer to perform a few simple steps and have their application available to be installed by users in minutes, not in months.
How do we trust software that can be made available to users in minutes? Simple: we confine it, and prevent it from accessing the user’s private data.
The Permissions Problem
At some point, an application may need to access some of the user’s data for it to be useful. For example, an image editing application is quite useless if it can’t open any of the user’s pictures. There needs to be a way to give applications permission to access certain data.
On another mobile platform, this is solved in two ways: having each application ship with a list of required permissions, and implement a shared storage location where applications can freely access the user’s files. When a user installs an application, a dialog box is displayed listing all the permissions that are required for the application to work correctly. The user then has two choices: they can either continue with the installation and grant the required permissions, or they can cancel the installation process.
As a user, this is a difficult choice to make.
In order for a user to make an informed decision about a security question, there needs to be some context. If a flashlight application I am attempting to install indicates that it requires access to my address book, I have no idea at this point in time why that access is required. Does the application feature a “Recommend this app to friends!” button which would require access to my contact list, or does it contain adware that wants to data mine me? At this stage, I am unable to make an informed decision on the trustworthiness of the application, and will most likely install it even if I’m not in complete agreement with the permissions that are being requested. This is an all-or-nothing proposition: there is no way for me to use an application if I don’t accept the complete list of permission it requests.
This results in a software store loaded with no-cost applications that exist solely to data mine personal information for profit. Users are walking around with mobile devices completely unaware of the fact that the trivial applications they’ve installed are tracking every move they make.
Trusted Helpers
In the security model we’ve developed, users get to make decisions on sensitive actions at the moment they are needed, instead of at application installation time. This is performed by system components called “Trusted Helpers”.
Ubuntu Software Store applications are confined by default. They can only access their own directories, and their own data. Instead of granting permissions to access user data, we grant access to request user data using Trusted Helpers. This allows applications to access specific data as approved by the user instead of granting permissions to access it all.
For example, instead of granting permission to directly access all of the user’s contact list, an application can request access to a contact. The system address book will then display a list of contacts to the user and only the specific contact selected by the user will be sent to the application. The application only has access to the contact which was specifically authorized by the user.
If a flashlight application needs access to a user contact in order for a “Recommend this app to friends!” button to work, the user will be making an informed choice, as the request will be the direct result of having pressed the button. The flashlight app can be used without fear of it accessing contact information during normal usage.
The same idea exists to exchange data between applications. If the user wants to edit a picture using an image editing application, the application will ask a system service known as the Content Hub to obtain an image. The Content Hub will then request a picture from the application which owns the data, in this case the Gallery application. The Gallery application will display a picker dialog to the user allowing them to select a specific photo to which the image editor will be granted access.
A similar approach exists for access to other system services that are security-sensitive, such as the device GPS. At the moment an application wants to access the user’s location, a dialog will be displayed asking for permission. If the user accepts the request, the decision is cached, and the application can now access the user’s location in the future. If the user declines, the application can continue functioning normally, but without the location information. A user will be able to revoke the granted permissions at any time.
Trusted Helpers allow users to specify, in a fine-grained way, which private information can be accessed by applications. The decision to grant these permissions is done at the moment the access is needed, giving the user the appropriate context for making an informed decision. Applications can be installed and used without fear that private data is being collected in the background.
Policy Groups
Applications in the Ubuntu Software Store are confined with technology called AppArmor. In order to facilitate the creation of AppArmor profiles by application developers, Ubuntu comes with a predefined list of “Policy Groups”. These Policy Groups are specified by application developers when creating packages for submission to the Ubuntu Software Store.
Some of the Policy Groups simply give access to the APIs necessary to communicate with Trusted Helpers. For example, the “location” Policy Group allows an application to communicate with the location service which uses the GPS, but does not give access to the GPS directly. The location service is a Trusted Helper which will prompt the user for authorization, so the mere presence of this Policy Group doesn’t directly affect user privacy.
Some of the other Policy Groups, such as “networking”, grant access to common services that aren’t really suitable for user prompting. Since most applications need network access, it would be inconvenient and inefficient to prompt the user for each one.
Although Policy Groups weren’t designed to be visible to end users, there is a utility in the Ubuntu Software Store called “Permy” that will display the ones being used by each installed application.
Power users who would like to experiment with restricting Policy Groups for installed applications can currently do so by editing the security manifest files. Each package in the Ubuntu Software Store ships a security manifest file that enumerates the Policy Groups granted to the package. When the package is installed, its security manifest file is available in /var/lib/apparmor/clicks/ and it can be edited by the admin of the system. For example, if you wanted to remove the “networking” Policy Group from the hello-world application:
$ adb shell vi /var/lib/apparmor/clicks/ar.com.beuno.hello-world_hello-world_0.1.json
change:
{
"policy_groups": [
"networking"
],
"policy_version": 1.0
}
to:
{
"policy_groups": [],
"policy_version": 1.0
}
Then apply the changes to the AppArmor policy with:
$ adb shell aa-clickhook -f
At the moment, application upgrades will reset any modifications done to Policy Groups, but we will be introducing override files in this development cycle. The override files will allow power users to revoke application Policy Groups in a way that will survive application upgrades.
In the future, we intend to develop the required system service to allow power users to easily revoke Policy Groups with a simple graphical interface.
The User is in Control
We believe the user should ultimately be in control of all access to their private data, and security should be more fine-grained than the all-or-nothing access inherent to a set of predetermined permissions associated with an application. Allowing the user to selectively share data with applications on a use by use basis as is done with Trusted Helpers makes Ubuntu Touch and the Ubuntu Software Store the ideal platform for privacy conscious users.
