Ubuntu Touch and User Privacy

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.

My Mythbuntu setup

I watch a lot of TV. Although I would really like to get rid of my satellite provider and switch to streaming the shows I like off of the Internet, living in Canada means a lot of the streaming video services aren't available, and even if they were, the bandwidth required to watch them would bust my download quota.

I'm also really picky about video compression, and some of the streaming services compress so much that watching their shows on the 55” TV I have in my living room is painful. Also, for some reason, half the shows and movies on Netflix have audio sync issues on my setup.

MythTV plays a large part in my household. All shows I watch are scheduled and recorded in HD off my satellite provider. While I wait for Ubuntu TV to take shape, I've recently upgraded my MythTV setup to Mythbuntu 12.04.

Backend

My MythTV backend is running on an HP Pavilion a4310f, with 4GB or ram, and a 1TB HDD. It's hooked up to a Hauppauge HD-PVR which records the video stream coming from my satellite provider's box. I have set the satellite provider's box to output 720p, as that gives me reasonable file sizes with an acceptable picture quality. Video is recorded over component cables, and sound is recorded in 5.1 over a TOSLINK cable. I use the IR blaster included with the HD-PVR to switch stations on the satellite box.

Instructions for setting up the HD-PVR in MythTV can be found in the wiki. This pretty much works out of the box with Mythbuntu. Although I originally had stability problems with the HD-PVR where every couple of months it would switch to recording audio at 25fps resulting in audio drift, a firmware upgrade to version 1.6.29353 has made it rock solid. I haven't risked upgrading to the most recent 1.7.x firmware as I don't currently have any issues.

You can obtain the script I use to change channels, my lircd configuration files, and the rc.local file I use to set the audio input here.

To set the picture control values to reasonable settings, I change the defaults for all channels in the MythTV database by running the following SQL command:

update channel set contrast=16384,brightness=32768,colour=16384,hue=3840;

I schedule programs to record using the MythTV web interface, and recorded shows are streamed in HD over the built-in UPnP server to any one of the three Playstation 3s I have around the house which also serve as Blu-ray players. I also have a dedicated MythTV frontend in the living room, which allows me to view TV shows without commercial interruption, and to delete shows once they've been watched. These are all connected using the wired gigabit network I installed during house construction, preventing the problems associated with streaming HD video over a wireless network.

Frontend

In the living room, which is my main TV viewing area, a dedicated MythTV frontend is used. I am using a Jetway HBJC600C99-352W-BW mini computer. I chose that model because it came with a built-in remote control, which allows me to power it on and control it from my Sony RMVL610 universal learning remote. It also features Nvidia Ion2 graphics, which enables me to use VDPAU with MythTV in order get the performance necessary to decode HD video.

I added a 1GB SO-DIMM to it, along with a cheap 32GB KingSpec SSD. It is also running Mythbuntu 12.04, and is hooked up to the gigabit wired network.

Getting the remote to work was a bit of a challenge. The device has a bogus HID report descriptor, resulting in a compatibility issue with the kernel HID drivers. Before a kernel fix was available, I discovered an application called “hid-mapper”, which allows converting any HID event into a keypress event. This is what I use on my frontend. I have packaged hid-mapper, along with some fixes, and all of the configuration scripts necessary to get it working on my frontend in my PPA.

If you do use my configuration files, please be aware that since I use a universal remote, I opted to make use of all buttons on the original remote without any regard to their placement or function. If you intend on using the original remote, you may want to reconfigure the button mappings to your liking.