CopperheadOS should not be used at all. It’s insecure and a scam. Daniel Micay was kicked out and James Donaldson (the CEO) spread lies about him among many other terrible things.
LineageOS weakens security a lot by weakening SELinux polices, disabling verified boot, requiring users to use an insecure third party recovery, not shipping firmware updates, not having good update security like rollback protection etc.
Also applies to eelo.
Neo900
“The owner of neo900.org has configured their website improperly. To protect your information from being stolen, Tor Browser has not connected to this website.”
Not sure how much I’d trust an OS who’s devs can’t maintain a website properly.
OnePlus
Openmoko
PiTalk
Plasma Mobile
PostmarketOS
Replicant
Not privacy/security focused.
Linux and/or open source does not immediately mean secure. In many cases it’s the opposite as you’d lose all the security advantages of android.
Weak privacy policies: The Google privacy policy applies to all Google services and ecosystems. This includes the right to collect information such as:
Google’s privacy polices only apply to Google’s services. Android is not a service but an open source project. AOSP doesn’t have any spyware by default. “Google Play Services” are the things that collect all that data and they aren’t even included in AOSP.
As the title of this page says: »overview«, »related«, »projects«, and, obviously, not: »strongly recommended secure and privacy enabled mobile OSs« (;
Most of them (any not) are at least source-available?
The purpose of that page is to list any project which probably will come up in a discussion about mobile Debian / mobile Whonix / mobile security whatsoever.
Even if there are negatives about any of the projects there, at best these negatives would be listed there as a bullet point.
It’s not a list of “things we recommend you should look into for better mobile security” page.
I’d rather change
Overview of Mobile Projects
That focus on either/and/or security, privacy, anonymity, source-available, Freedom Software.
to make the title fit the content than remove any contents of the page.
Well, the title of this forum thread Overview of Libre Software related Mobile Projects is outdated. That was before the scope was extended, after more interesting projects were added. Will update.
Then I think there should be different sections for each attribute so people don’t get confused and assume they’re all privacy/security/freedom related.
This is a quick and dirty page. I don’t want to spend too much effort on it. It’s very low priority. Even fairly categorizing these projects can open a can of worms - also keep up to date. Better to add any disclaimer on top as required.
Target audience are developers who are researching what kind of projects exist so they can decide which ones to work on or fork as well as advanced users. All of them need to take the information with caution and research independently on their own if the provided information (is still) accurate of if they disagree for some reason.
Blanket disclaimer:
All statements are either false or incomplete.
I previously didn’t reply since I am not that deep into Android. And it would have taken a long time to form an opinion reviewing your technical points.
Your technical arguments against even opt-in root decreasing security may be true. Likely, they are true. I will assume in my reply, that they are in fact true.
I think our disagreement is prioritization. You seem to prioritize security over user freedom. [1]
Here is the freedom restriction that I am seeing:
The 4 original essential software freedoms as defined by the Free Software movement are granted. However, since the inception of the 4 original essential software freedoms, other issues came up sometimes called tivoization, malicious feature, antifeature, tyrant software, treacherous computing or DRM (digital restrictions management).
Non-root enforcement can be considered a lesser form of tyrant software or antifeature since it doesn’t restrict flashing an alternative, but cripples the system in major ways. You might argue you can use userdebug version or software fork and compile a version that doesn’t do this, but then the networking effect and scale of a project becomes so great that rolling an own fork has negligible effects and upstream choices are the de-facto state of things.
Non-root enforcement is also similar to DRM. While DRM is about applications which don’t allow users to easily, freely copy data on their own devices, non-root enforcement here leads to users not able to backup/copy/migrate their application data from one phone to another. Either the application has a backup / data export feature or data is “trapped” inside the phone. Even with a app dependent app data backup feature, it’s better if users who choose so can get access to the raw data stored by the app for convenience (not using tons of different data export features rather than scripting backups, data export feature may be incomplete, analysis of app data by user).
Non-root enforcement also aids DRM enabled applications. If GrapheneOS gets more popular, perhaps picked up my phone manufacturers or resellers, mobile carriers it will be easy for application developers to utilize DRM. To prevent the user from accessing application data. Making phone work in the interest of the application developer rather than phone user.
Phone manufacturers or resellers, mobile carriers couldn’t be blamed for refusing root access. That would already be the GrapheneOS default. They could conveniently blame it on “security”. Some power users might be able to flash a root-enabled version but the effect would be negligible. In practice, this will result in a lot users having their freedom restricted.
[1] But even the security vs user freedom view is a false dichotomy. Bootloaders allow for flexibility to boot into a root-enabled mode. There could be a key combination and/or boot menu which allows users to boot into root-enabled mode. There could be timeouts [user has to wait 5 seconds before proceeding a anti-root warning] / strong warnings. Booting into root-enabled mode could make subsequent boots into non-root enabled mode show a warning that the device may be compromised due to previous boot into root-enabled mode.
The question is rather, how much time/effort/money would be required to grant user freedom (root) in a secure way (such as alternative boot options)? If you were offered 1 million USD and had time, could you implement root access in a secure way? This is unrealistic and just and example to encourage imagination of solutions. Is this really a question of unsolvable security issues vs user freedom? Or is it rather prioritization effort/time/money required to implement user freedom (root) vs other goals (just don’t prioritize on user freedom, make something work for novice users, more quickly monetize (understood, we all need to eat)).
That’s not true. If users want root, they can unlock their bootloader and make whatever modifications they want. Users that don’t need root shouldn’t have it exposed at all.
Some manufacturers don’t allow unlocking the bootloader but that’s the fault of the manufacturer, not Android. Would it be the fault of Whonix if someone made a fork which ripped out the superroot boot mode?
You can’t allow root in production if you want security. If you allow unrestricted root, the attacker will just go for that.
I don’t think that statement can be shrunk to a single line and I think
I’ve already elaborated why I came to that conclusion.
Some manufacturers don’t allow unlocking the bootloader but that’s the fault of the manufacturer, not Android. Would it be the fault of Whonix if someone made a fork which ripped out the superroot boot mode?
No, because Whonix implemented superroot and someone else ripped that
out. Can’t be responsible for action of third party and neither are any
actions by Whonix useful to justify that. Would be different if Whonix
didn’t implement superroot by default. Plus I would criticize that and
argue for superroot boot mode.
You can’t allow root in production if you want security.
I don’t understand that premise. bootloaders allow for that flexibility.
If users want root, they can unlock their bootloader and make whatever
modifications they want. Users that don’t need root shouldn’t have it
exposed at all.
My previous post describes how bootloaders allow for that flexibility.
It’s a question of usability vs freedom vs security vs priorities vs
economical realities.
About how hard will it be to gain root. Unlock bootloader (more
difficult) or key combination during bootloader (easier). It’s very
similar just combination during bootloader might not be implemented due
to low priority.
If you allow unrestricted root, the attacker will just go for that.
Meaning, it needs to have bad usability, otherwise users will do it?
It’s not that simple. One of verified boot’s main purposes is protection from physical attacks. If you allow someone to just boot into a different mode with root without unlocking the bootloader, the physical security is nil.
Looks doable to me in principle. Looking at some arbitrary unblock bootloader guide. The procedure:
Steps include, simplified:
do something on your computer - skipable [1]
boot in normal mode and enable something (USB debugging and OEM unlock) in android settings (usability still good if this is kept)
connect USB - skipable [1]
do something on your computer - skipable [1]
automatic factory reset (I don’t see need for this except DRM which is a bad reason.)
I don’t see why this procedure couldn’t be simplified in principle.
boot in normal mode and enable something
reboot
bootloader now allows to boot into root mode
It’s an usability enhancement and unrelated to security.
Also for physical security root mode could require (a special) PIN code or whatever. (What’s good enough physical for normal boot is also good enough for root enabled boot.)
[1] This an certainly be skipped, doesn’t provide security (rubber ducky).
It’s necessary to prevent the attacker from getting your data. It’s a security feature and has nothing to do with DRM. Would you rather an attacker unlock your bootloader, modify the system and make a rootkit to steal your data once it’s decrypted?
It is related to security. A physical attacker can easily gain root and access everything.
With the way it is now, the attacker has to compromise the device remotely first to enable OEM unlocking and then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.
If user choose to to enable root mode and choose root boot in boot loader, I don’t see how any attacker has any advantage.
A local attacker can try to boot into either non-root or root mode. Either way, there is encryption / access controls. I don’t see why in one case encryption / access controls are weaker.
Encryption doesn’t cover everything such as the bootloader. If you allow the attacker to unlock the bootloader without wiping user data, the attacker can just replace the bootloader with a malicious one that uploads all of your data the next time you decrypt it.
Encryption + verified boot is necessary for any meaningful physical security.
We don’t have local attackers in our threat model. Android does.
They don’t need the password to modify unencrypted parts.
The purpose of verified boot is to prevent the attacker from persisting as root. It doesn’t matter if the attacker has unlimited capabilities, verified boot will still revert their changes.
I see. For phones, that’s because of “BIOS” is root of trust is read-only in hardware, which verifies the first stage, the bootloader which then verifies in a chain kernel and so forth.
Verified boot can work in principle also on computers using SecureBoot and/or heads. It uses a TPM and measured boot. Doesn’t extend to user space but that’s just a lack of implementation rather than conceptual impossibility.
I am writing this to show that I don’t see the conceptual differences between computer hardware and phone hardware which somehow introduce a (conceptual) difference which in one case allows for secure root-enabled boot mode without user data wiping (computer) but not in another case (android) that’s not possible.
Indeed but there’s also no strong reason why bootloader contents would have to remain secret.
That’s a rather complex attack. Similar to installing a hardware keylogger, microphone (can guess keystrokes) and/or miniature camera during the absence of the victim into/near a computer.
Also “just replace the bootloader” sounds simple but for phones there are many phones where people would like to unlock the bootloader but that freedom is refused by the device vendor. For many phones, mortals cannot replace the bootloader.
That feature might have a point. But should have an opt-in or opt-out. (Probably opt-out since it’s default already.) If it’s possible to securely implement booting into normal boot mode, enabling OEM unlocking in android settings, then it conceptually must also be possible to add an option to disable “wipe user data when bootloader gets unlocked”.
Let’s consider local attackers. If figured out it’s infeasble it can be ignored but would be good to at least consider and describe why that is. heads / insurgo make that seem realistic to cover some local threat models.
For that purpose, I’ve refined (better wrote down the concept) of multiple boot modes just now.
Agreed but I don’t see how that’s related.
Modified unencrypted parts would be hopefully caught by verified boot implementation.
That is independent of let’s say app X vs app Y is installed. I.e. it doesn’t matter if the fully booted android allows root or not.
The only thing required in step 1) is enable OEM unlocking. Remote root compromise (suppose which would be undone by verified boot) to enable OEM unlocking would be the only thing the attacker would care about. The attack would succeed so far.
My premise is:
remote exploit that gained root on android → can enable OEM unlocking in android settings
If that is the only thing the attacker does… And accept premise verified boot will undo attacker root… Then still, after reboot OEM unlocking is still activated. Now back to what you said…
And again my summary / rewrite of the current model into steps.
in this threat model suppose a root exploit gained root temporarily and enabled OEM unlocking
then have physical access
Again, the current model:
As I wrote before:
I don’t see why this procedure couldn’t be simplified in principle. Slightly refined:
boot in normal mode and enable something
reboot
bootloader now allows to boot into root mode (require physical button press)
What you said “With the way it is now, the attacker has to compromise the device remotely first to enable OEM unlocking and then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.” is still the same under my proposed model. Just that has better usability, because less steps required.