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.

How to disable the guest account in Oneiric

Ubuntu 11.10 now ships with the guest account available at the LightDM login screen.

This new feature isn't really a security issue, since by default using it requires physical access, and it is confined with an AppArmor profile. If an attacker has physical access to your laptop, all bets are off.

The guest account can be disabled by editing /etc/lightdm/lightdm.conf and adding "allow-guest=false" to the "SeatDefaults" section.

Introducing the Pasaffe password manager

For the past few years, I had been storing my passwords in an application called GPass. What I liked about it when I started using it at that time was its simplicity, and the fact that each entry in the database has a notes field that can be used for any additional information that the predetermined fields don't handle.

Unfortunately, it doesn't seem to be actively developed anymore, and has been dropped from the Debian and Ubuntu archives. What's more, I've never looked closely at how secure the database format is, and there is no way to open the database it creates on other devices, such as my phone.

I started looking for a replacement about six months ago, and I didn't like most of the ones I tried. Some of them used a cross-platform GUI toolkit which made the app cumbersome to use. Others were too complex, didn't have a place to store notes, or were no longer actively maintained.

Since I've been wanting to learn GTK programming for a long time, this presented itself as a great opportunity. I started by looking at the popular password database formats, and the one that stood out was the one used by PasswordSafe. It is well documented, well designed, and has implementations available on numerous platforms. I implemented a Python library to read and write the database format, and then proceeded to use the excellent Quickly tool to create the initial GTK user interface. Since I want my app to run on the latest LTS release, Lucid, I decided to stick with PyGTK for now instead of PyGObject. I plan on converting it to PyGObject for the next LTS release. After having developed it for a while, I feel it's in a good enough state to be used.

Introducing: Pasaffe!

You can find the upstream project page here.
You can install it from a PPA here.

If anyone wants to contribute to it, there's a list of currently unimplemented features and other things that need to be done in the TODO file.

GNOME Keyring

For the past week or so, people have been talking about a “security issue” in Seahorse. This sums up my opinion on the matter:

This isn't a security issue, and there is no good way to fix it.

There, I've said it. Now, here's some background:

Although people are talking about Seahorse, the actual application that manages passwords is called GNOME Keyring. GNOME Keyring is an application that manages a user's authentication information, such as user names and passwords. It stores the authentication information in one or more encrypted databases, called keyrings. A password, supplied by the user, is required to unlock a keyring, at which point all the information contained within is decrypted and is made available to applications via the libgnome-keyring library. It is similar to the Keychain in Mac OS X, and Protected Storage in Microsoft Windows.

Traditionally, a desktop application that needed to remember a user's password, such as an email or an instant messaging program, would store the password in a hidden config file in the user's home directory. Appropriate permissions would be set on the file to make sure other local users can't read it.

Sometimes, passwords stored in this manner would be obfuscated using a reversible scheme, as the password needs to be converted back to plain text in order to be used. This would provide a false sense of security. Users inspecting the file would think the passwords were encrypted, but a myriad of little recovery scripts and on-line converters were available to anyone who knows how to perform a Google search.

A password managing daemon, such as GNOME Keyring, increases the security of stored passwords for the following reasons:

• Passwords are stored in a database that uses real encryption, not just an obfuscation scheme
• A single code base needs to be audited to make sure no vulnerabilities exist in the encryption algorithms that are being used
• The database is protected by a password that is known only to the user who unlocks it
• Since the database is encrypted, no other user or bootable CD can recover the stored passwords if the unlock password is not known

So, if GNOME Keyring increases the security of user credentials, why can you see your passwords exposed in plain text when you open Seahorse? Because you've unlocked the keyring using your login password.

Although GNOME Keyring supports multiple keyrings, there is only one by default, called “login”. This keyring is automatically unlocked by a PAM module when logging into a GNOME desktop. When the desktop session is closed, the keyring is locked. When the keyring is in an “unlocked” state, the database files are decrypted using the decryption password and all the contents are in memory for gnome-keyring-daemon to access.

Now, the attack scenario that has been talked about this past week has been leaving your computer unattended, and an attacker using Seahorse to access your clear text passwords. This has been criticized as being a security issue, and a few “solutions” have been suggested to “fix” the issue. Here are some of the scenarios proposed:

Scenario 1: Ask for the user's password before displaying the clear text keyring contents.

This scenario doesn't work in practice. Once the keyring is unlocked, the contents are available under the user's security context. Since the GNOME Keyring daemon is under the user's security context, the intruder has every privilege necessary to simply bypass the authentication step and directly read the unencrypted keyring from memory. Even if Seahorse asked for a user password, nothing could prevent the intruder from simply downloading a “reveal passwords” application from the Internet or a USB key. There is no difference in time or skill required to open Seahorse and display passwords, or to type “gnome password revealer” in Google and execute the first application available for download. The GNOME Keyring project has a web page to explain this.

Even worse, the fact that a password would be required in Seahorse would make the user think that a password is required to see the clear text information. This would give the user a false sense of security. If Seahorse asks for a password, but a five line python script can bypass the password, bug reports would change from “Seahorse displays clear text passwords” to “Seahorse authentication can be easily bypassed”. This scenario doesn't solve the problem.

Scenario 2: Make keyring session expire automatically after a certain time.

If the keyring session expires automatically, such as every 15 minutes, it becomes useless. The purpose of the keyring is to store passwords that are needed by applications. With keyring session expiration, Evolution can't automatically check for new mail, Empathy can't auto-reconnect to instant messaging networks, the wireless connection can't re-authenticate to access points.

If you expire the keyring session every 15 minutes, you will probably need to type in your password every 15 minutes. Besides, if you leave your computer unattended, 15 minutes is long enough for an intruder to steal your passwords. This scenario doesn't solve the problem.

Scenario 3: Make the keyring daemon run as root or as a dedicated user.

The idea behind this is to have a central daemon that would authenticate users and applications before giving out passwords. Since the daemon doesn't run under the user's security context, no amount of hacking by an intruder in an unlocked desktop session would result in gaining access to the unlocked password database.

Although this scenario may seem appealing, it would probably be less secure than the current approach. If we have a central daemon that serves all users, a programming vulnerability could result in other users gaining access to your confidential information. Besides, if your desktop applications, under your security context, can gain access to the passwords they need, so can an intruder in your security context. The intruder's script can simply spoof the desktop applications themselves to get the passwords, or get them out of the application's memory. This scenario doesn't solve the problem.

Scenario 4: Stop using GNOME Keyring.

Well, GNOME Keyring was created to solve the problem of people writing down their passwords everywhere, including text files or their computer, and the problem of applications storing passwords in text files. Removing GNOME Keyring would decrease security to the state it was before. This scenario doesn't solve the problem.

Scenario 5: Locking the desktop session when stepping away from the keyboard.

Now we're getting somewhere!

Since the attack vector that's being discussed is an intruder gaining physical access to an unlocked desktop, the simplest way to prevent this from happening is to lock the desktop when you leave it unattended.

If someone gains access to your desktop, your passwords are not the only thing they can access. Who needs your email password, when they have access to your whole mail file?

Even if we assume GNOME Keyring could be made attacker proof, we would need to do the same for every desktop application. An intruder could, in a few seconds, install a Trojan horse downloaded off the Internet that runs in the background and emails him your passwords as soon as your desktop applications use them. The same application could intercept your sudo password, and become root to access the GNOME Keyring data. Absolutely no technical skill is required to do this.

Leaving your desktop unattended exposes all your confidential data to an attacker, not just your passwords.

Game Over.

Recommendations:

• Always lock your screen when you leave your computer unattended. This is akin to locking your front door when leaving the house. Hit Ctrl-Alt-L, select “Lock Screen” from the user switch applet, or put the “Lock Screen” applet somewhere in your panel for easy access.
• Set a low screen-saver idle timeout, for example, 5 minutes. If you forget to lock your session, it will do so automatically after a couple of minutes, reducing the time your confidential data is exposed.

And remember: This isn't a security issue, and there is no good way to fix it.

Aide (Advanced Intrusion Detection Environment) improvements

At the Karmic Ubuntu developer summit, we had a session on filesystem integrity checkers. The main purpose of the session was to see what the current state of them was, and if we needed to replace Aide in main with a newer alternative.

I don't traditionally like filesystem checkers. While they are very useful to detect files that get modified during an intrusion, an administrator needs to invest an incredible amount of time in analyzing the log files that they produce every day. This is compounded by the fact that servers don't remain static: they get security and stability software updates installed. The more that servers get updated, the more they divert from the original database that was generated by the integrity checker, and the more false positives get reported in the log.

Wouldn't it be great if the integrity checker was smart enough not to report on files that were changed by operating system updates?

I introduced this very feature in the Aide package in Karmic Koala. It is disabled by default. To activate it, simply modify the /etc/default/aide configuration file and set “FILTERUPDATES” to “yes”. I also recommend changing “COPYNEWDB” to “yes” in order to get changes reported only once.

This new configuration option will filter out files that were modified by operating system updates from the daily email sent to the administrator. It will not filter them out from the main log file.

Of course, overwriting the pristine database every day and filtering out the files changed by system updates may slightly reduce Aide's effectiveness, but I think it's a compromise worth having if the alternative is to not use Aide at all because of administrative overhead.

If you've never used Aide before on your Ubuntu server, and would like to give it a try on Karmic, here are the steps necessary to get started:

1- Install aide:

apt-get install aide

2- Create the initial database (this may take a while):

aideinit

3- Customize the MAILTO, COPYNEWDB and FILTERUPDATES parameters in /etc/default/aide

4- You should now get a daily email report on filesystem changes!