Replicant

h1. ApplicationsSecurityModel

h2. Warning

This article is a work in progress. It might (still) contain mistakes at this early stage.

h2. Introduction

Android is an operating system currently made mainly by Google and various device manufacturers[1] to make money by selling devices[2], applications that are not necessarily free software, violating people's right to privacy through online services, etc.

Devices often come with a nonfree applications like "Google Play":https://en.wikipedia.org/wiki/Google_Play (or equivalent software made for/by device vendors) that steer people toward installing applications, which often are nonfree. This has a huge impact on the security model of the applications.

In GNU/Linux many applications are not sandboxed by default, as most of them are free software and don't necessarily pose any threat to users, unless they are vulnerable to security issues like remote code execution. As they are trustworthy, sometimes the application sandbox themselves: at the beginning, when they start running they have access to many files and resources, and very early on once they are done with the resources (like they read the file content for instance), they sandbox themselves through mechanisms like "seccomp":https://en.wikipedia.org/wiki/Seccomp or privilege drop. Other mechanism like stack protection implemented in compilers like GCC and in the Linux kernel (for features like ALSR) also help making GNU/Linux secure transparently as it just crash the applications when conditions that create security issues are detected, and/or make it very hard to exploit security issues. The advantage of these measures is that it's completely transparent to users and don't restrict them in any way. However they don't protect against untrustworthy application whose code is not available and malicious.

In contrast, with Android, many people run nonfree applications, some of which try to actively exploit the users through surveillance, manipulation (through advertizing or "digital addictions":https://en.wikipedia.org/wiki/Digital_media_use_and_mental_health , for instance), or even "steal money":https://en.wikipedia.org/wiki/Android_(operating_system)#Common_security_threats for malwares that are sometimes present in app stores until they are found and removed by the company managing that appstore.

Probably because of the public pressure and to gain a market advantage, since many of the applications that people run cannot be trusted at all, the Android security model had to be adapted to that. This doesn't fix any of the issues at all but rather limits the potential for damage and the probability of such issues, which are still very present.

This has lead to the sandboxing of applications and the Android permission system which is not always clear nor fine grained enough.

As Replicant is based on Android, we inherit this security model.

h2. Documentation and issues

h3. Applications and keys

Android applications (including system applications like the dialer, default SMS application, etc) have an internal name (like fil.libre.repwifiapp for RepWiFi) and they are signed with keys. So the application with its internal name and its public signature gives it access to some internal storage that is dedicated to that application. This is for instance where the contacts are stored.

This has some consequences:

* You cannot update an application if its internal name or signing key changes, you need to uninstall it and reinstall it instead.

* If you uninstall an application, the content of the internal data storage is removed / lost.

This also makes backuping applications data more difficult.

h3. System applications

During the build of Replicant, some certificates are generated to sign various applications. 

The issue here is that when the developer doing official builds changes, or when users want to run their own build, you end up with different signatures, and the new system applications can't access their data. This can lead to crashes. A Replicant developer verified that by removing all the checks preventing to install of a new Replicant image with system applications signed with different keys: After booting the device, the launcher always crashed, making the device unusable.

h3. Changing signing keys.

Despite the default behavior, it is possible to change the signature expected by an application data. This enables to keep the data of an application while upgrading to a new version of this application that is signed with a new key.

Software to do that is being developed for Replicant.

References:

fn1. "Developer: Various (mostly Google and the Open Handset Alliance)" from "Wikipedia":https://en.wikipedia.org/wiki/Android_(operating_system)

fn2. "A group of companies known as the Open Handset Alliance (OHA), led by Google, originated Android. Today, many companies—both original members of the OHA and others—have invested heavily in Android. These companies have allocated significant engineering resources to improve Android and bring Android devices to market." from https://source.android.com/setup#governance-philosophy