PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2025-02-20 18:31:35 -05:00
Code

Rearrange more sections

Browse Source 
Signed-off-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
friendly-rabbit-35 2024-05-20 21:48:59 +00:00 committed by Friendly Rabbit
parent 73e6589ce9
commit f25f6a1fa2
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
content/posts/android/F-Droid Security Issues.md
View File

@ -116,7 +116,7 @@ allow untrusted_app_25 proc_tty_drivers:file r_file_perms;
This is a mere sample of the [SELinux exceptions](https://android.googlesource.com/platform/system/sepolicy/+/refs/tags/android-12.0.0_r21/private) that have to be made on older API levels to demonstrate why SDK level matters.
It turns out the official F-Droid client doesn't care much about this since it lags behind quite a bit, **[targeting the API level 29](https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/build.gradle?ref_type=heads#L39)** (Android 10) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients such as [Droid-ify](https://github.com/Iamlooker/Droid-ify) or [Neo Store](https://github.com/NeoApplications/Neo-Store). The best F-Droid client is actually [F-Droid Basic](https://f-droid.org/en/packages/org.fdroid.basic) for the following reasons:
It turns out the official F-Droid client doesn't care much about this since it lags behind in SDK level quite a bit, **[targeting the API level 29](https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/build.gradle?ref_type=heads#L39)** (Android 10) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients such as [Droid-ify](https://github.com/Iamlooker/Droid-ify) or [Neo Store](https://github.com/NeoApplications/Neo-Store). The best F-Droid client is actually [F-Droid Basic](https://f-droid.org/en/packages/org.fdroid.basic) for the following reasons:
- Compared to the official F-Droid client, F-Droid Basic targets a higher SDK level (API level 34 to the official client's 29) and has a reduced attack surface, as some features found in the official client (such as [Nearby Swap](https://f-droid.org/tutorials/swap/)) are not present in the "Basic" client.
- Compared to Droid-ify and Neo Store, F-Droid Basic supports repository mirrors properly and removes an extra party of trust, as it is maintained by the F-Droid team.
@ -125,12 +125,12 @@ Furthermore, F-Droid **[doesn't enforce a minimum target SDK](https://gitlab.com
- Since August 2023, the Play Store requires new apps to target at least API level 33 (Android 13), and existing apps must target Android 13 or higher for updates to be submitted.
There is little practical reason for developers not to increase the target SDK version (`targetSdkVersion`) with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. An app can still ensure backwards compatibility in such a way that it can run on older platforms: the `minSdkVersion` attribute informs the system about the minimum API level required for an application to run. Setting it too low isn't practical though, because this requires having a lot of fallback code (most of which is handled by common libraries) and separate code paths.
Keeping the **app ecosystem modern and healthy** is necessary, though it may seem bothersome. As shown above, F-Droid's lack of enforcement on this front sends the wrong message to developers (and even users). They should care about an modern and healthy app ecosystem, and this is why many of us think F-Droid's [relegation of this upkeep](https://gitlab.com/fdroid/fdroiddata/-/issues/2210#note_440967209) to individual app developers may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 "Ice Cream Sandwich". Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.
There is little practical reason for developers not to increase the target SDK version (`targetSdkVersion`) with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. An app can still ensure backwards compatibility in such a way that it can run on older platforms: the `minSdkVersion` attribute informs the system about the minimum API level required for the application to run. Setting it too low isn't practical though, because this requires having a lot of fallback code (most of which is handled by common libraries) and separate code paths.
At the time of writing:
- Android 12 is the oldest Android version that is [getting security updates](https://endoflife.date/android).
- Android 12 is the oldest Android version that is [receiving security updates](https://endoflife.date/android).
- [~80% of the Android devices](https://developer.android.com/about/dashboards) used in the world are running **at least** 8.0 Oreo.
*Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.*
@ -138,20 +138,20 @@ At the time of writing:
## 5. Confusing UX
It is worth mentioning that the F-Droid website has, for some reason, always been hosting an [outdated APK of F-Droid](https://forum.f-droid.org/t/why-does-the-f-droid-website-nearly-always-host-an-outdated-f-droid-apk/6234). This is still the case today, which leads many users to wonder why they can't install F-Droid on a secondary user profile (due to the downgrade prevention enforced by Android). "Stability" seems to be the main reason mentioned on their part, which doesn't make sense. Either your version isn't ready to land in a stable channel, or it is and new users should be able to access it easily.
F-Droid should enforce the approach of prefixing the package name of their alternate builds with `org.f-droid` for instance (or add a `.fdroid` suffix as some already have). Building and signing while **reusing the package name** ([application ID](https://developer.android.com/studio/build/configure-app-module)) is bad practice as it causes **signature verification errors** when some users try to update or install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.
F-Droid should enforce the approach of prefixing the package name of their alternate builds with `org.f-droid` for instance (or add a `.fdroid` suffix as some already have). Building and signing while **reusing the package name** ([application ID](https://developer.android.com/studio/build/configure-app-module)) is bad practice as it causes **signature verification errors** when users try to update or install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.
This results in a confusing user experience where it's hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.
## 6. Misleading permissions approach
F-Droid shows a list of the [low-level permissions](https://developer.android.com/reference/android/Manifest.permission) for each app. These low-level permissions are usually grouped in the standard, high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it's often a **misleading** and inaccurate approach for the end user. Since Android 6, apps have to [request the standard permissions at runtime](https://developer.android.com/guide/topics/permissions/overview#runtime) and do not get them simply by being installed, so showing all the "under the hood" permissions without proper context is not useful and makes the permission model unnecessarily confusing.
F-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have [install-time permissions](https://source.android.com/devices/tech/config/runtime_perms). Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn't run an 8 years-old version of Android that has not received security updates for years.
F-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have [install-time permissions](https://source.android.com/devices/tech/config/runtime_perms). Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn't run an outdated version of Android that has not received security updates for years.
A [discussion about this](https://gitlab.com/fdroid/fdroid-website/-/merge_requests/834) took place on F-Droid's GitLab repository. In short, F-Droid downplayed the issue with their misleading permission labels, and their lead developer proceeded to call the Android permission model a "dumpster fire" and claim that the operating system cannot sandbox untrusted apps while still remaining useful.
*To clear up any confusion, even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android; instead, these apps display a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app's `targetSdkVersion`. And even if this were the case, the OS package installer on modern Android would've been designed to show the requested permissions for those legacy apps.*
For example, the low-level permission `RECEIVE_BOOT_COMPLETED` is referred to in F-Droid as the *run at startup* permission:
For an example of the misleading way F-Droid displays low-level permissions, let's look at the low-level permission `RECEIVE_BOOT_COMPLETED`, which is referred to in F-Droid as the *run at startup* permission:
> *Allows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.*
@ -161,9 +161,9 @@ In modern Android, the background restriction toggle is what really provides the
Another example to illustrate the shortcomings of this approach would be the `QUERY_ALL_PACKAGES` low-level permission, which is referred to in F-Droid as the *query all packages* permission that "allows an app to see all installed packages". While this description is somewhat correct, it can also be misleading: apps do not need `QUERY_ALL_PACKAGES` to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default [since Android 11](https://developer.android.com/training/package-visibility)). If an app needs more visibility, it will declare a `<queries>` element in its manifest file. In other words, `QUERY_ALL_PACKAGES` is only one way to achieve visibility. Again, this goes to show how low-level manifest permissions are not intended to be interpreted as high-level permissions that the user should fully comprehend.
The Play Store for instance conveys the permissions in a far less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by tapping "About this app" then "App permissions - See more" at the bottom of the page. The Play Store will inform the user that the app may request access to the following permissions; this kind of wording is more important than it seems. *Update: since July 2022, the Play Store doesn't offer a way to display low-level permissions anymore.*
The Play Store, for instance, conveys the permissions in a far less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by tapping "About this app" then "App permissions - See more" at the bottom of the page. The Play Store will inform the user that the app may request access to the following permissions; this kind of wording is more important than it seems. *Update: since July 2022, the Play Store doesn't offer a way to display low-level permissions anymore.*
Moreover, [the Play Store restricts the use of highly invasive permissions](https://support.google.com/googleplay/android-developer/answer/9888170) such as `MANAGE_EXTERNAL_STORAGE`, which allows apps to opt out of scoped storage if they can't work with [more privacy friendly approaches](https://developer.android.com/guide/topics/providers/document-provider) (like a file explorer). Apps that can't justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually shine, particularly with a review process to protect end users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place...
Moreover, [the Play Store restricts the use of highly invasive permissions](https://support.google.com/googleplay/android-developer/answer/9888170) such as `MANAGE_EXTERNAL_STORAGE`, which allows apps to opt out of scoped storage if they can't work with [more privacy friendly approaches](https://developer.android.com/guide/topics/providers/document-provider) (like a file explorer). Apps that can't justify their use of this permission (which again has to be granted dynamically) may be removed from the Play Store. This is where an app repository can actually shine, particularly with a review process to protect end users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place...
## Conclusion: what should you do?
So far, you have been presented with referenced facts that are easily verifiable. In the next part, I'll allow myself to express my own thoughts and opinions. You're free to disagree with them, but don't let any disagreements overshadow the facts.
@ -178,7 +178,7 @@ This is how you may proceed to get the app certificate:
apksigner verify --print-certs --verbose myCoolApp.apk
```
Also, as written above: the OS pins the app signature (for all profiles) upon installation, and enforces signature checks for app updates. In practice, this means the source doesn't matter as much after the initial installation.
Also, as written above, the OS pins the app signature (for all profiles) upon installation and enforces signature checks for app updates. In practice, this means the source doesn't matter as much after the initial installation.
For most people, I'd recommend just **sticking with the Play Store**. The Play Store isn't quite flawless, but emphasises the adoption of modern security standards which, in turn, encourages better privacy practices. As strange as it may sound, Google is not always doing bad things in that regard.
@ -186,7 +186,7 @@ For most people, I'd recommend just **sticking with the Play Store**. The Play S
> Should I really care?
**It's up to your [threat model](https://privsec.dev/posts/knowledge/threat-modeling/)**, and, of course, your personal preferences. Most likely, your phone won't turn into a nuclear weapon if you install F-Droid on it --- this is far from the point that this article is trying to make. Still, I believe the information presented will be valuable for anyone who employs a **practical approach to privacy** rather than an ideological one. Such an approach is partially described below.
**It's up to your [threat model](https://privsec.dev/posts/knowledge/threat-modeling/)**, and, of course, your personal preferences. Most likely, your phone won't turn into a nuclear weapon if you install F-Droid on it --- this is far from the point that this article is trying to make. Still, I believe the information presented here will be valuable for anyone who employs a **practical approach to privacy** rather than an ideological one. Such an approach is partially described below.
> But there is more malware in Play Store! How can you say that it's more secure?
@ -198,7 +198,7 @@ I've seen this comment repeatedly, and entertaining it would be dismissing all t
> Aren't open-source apps more secure? Doesn't that make F-Droid safer?
You can still find and obtain your open-source apps elsewhere. And no, open-source apps [aren't necessarily more private or secure](https://seirdy.one/2022/02/02/floss-security.html). Instead, you should rely on the strong security and privacy guarantees provided by a modern operating system with **a robust sandboxing/permission model**, namely those provided by modern Android, GrapheneOS and iOS. Pay close attention to the permissions you grant, and avoid legacy apps as they could require invasive permissions to run.
You can still find and obtain open-source apps elsewhere. And no, open-source apps [aren't necessarily more private or secure](https://seirdy.one/2022/02/02/floss-security.html). Instead, you should rely on the strong security and privacy guarantees provided by a modern operating system with **a robust sandboxing/permission model**, namely those provided by modern Android, GrapheneOS, and iOS. Pay close attention to the permissions you grant, and avoid legacy apps as they could require invasive permissions to run.
When it comes to *trackers* (this comes up quite a lot), you shouldn't believe in the flawed idea that you can enumerate all of them. The *enumerating badness* approach is [known to be flawed in the security field](https://www.ranum.com/security/computer_security/editorials/dumb/), and the same applies to privacy. You shouldn't believe that a random script can detect every single line of code that can be used for data exfiltration. Data exfiltration can be properly prevented in the first place by a robust permission model, which again **denies access to sensitive data by default**. This is a simple, yet rigorous and effective approach.
@ -224,6 +224,6 @@ It's also worth keeping an eye on the great work **GrapheneOS** does on [their f
This article aims to be **purely technical**. It is not an attack on F-Droid or their mission. It is meant as an informative piece for end users and a springboard for improvement of the F-Droid project.
In spite of this, the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who seem to take a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals go as far as engaging in harassment campaigns against projects and security researchers that do not share their views. Hopefully, they realize that such unethical behavior undermines their own project and reputation. Creating a rift between developers and security researchers is not in anyone's best interest.
In spite of this, the release of this article has unfortunately triggered a mostly negative response from the F-Droid team and some of their community, who seem to take a dismissive stance toward this article rather than bringing relevant counterpoints. Some of these individuals go as far as engaging in harassment campaigns against projects and security researchers who do not share their views. Hopefully, they realize that such unethical behavior undermines their own project and reputation. Creating a rift between developers and security researchers is not in anyone's best interest.
Some individuals have also falsely associated this article with GrapheneOS. _This article is an entirely independent work and unrelated to the GrapheneOS project. It was not written by a GrapheneOS developer and does not claim to represent the GrapheneOS project in any capacity._ Either way, dismissing the article on the basis of association instead of addressing the actual technical content is silly and not helpful to anyone.