I see, thank you for info. So, GrapheneOS is no good from this point of view. And took Android so many years and version to finally understand that completely sandboxed apps should not share clipboard by default.
By the way, in Android user can have root access and limit firewall settings quite flexible and per app using something like:
You can consider phones supported by LineageOS project.
…aaah yes that reminds me about a pet gripe I have with android.
Apps will routinely demand (as in, refuse to run without) access to all of my storage.
All they really need is access to whatever directory they want to store their configuration and data in. Instead, you have to go whole-hog and give it permission to access everything. Of course that would let the app access everything on your phone and possibly send it back home.
I gather (and please, please correct me if I’m wrong) the permissions aren’t “granular” enough to let you grant only permissions to access one folder. If they were I’d be a lot more willing to install apps.
(The peak of insanity was when the OEM photo gallery would, after an update, refuse to run at all unless you gave it access to your contacts. The theory being you can’t share your photographs without that, but what if all I want to do is look at my own pictures? You won’t let me do that, you arrogant piece of crap? Uh, that’s a hard NO.)
OK, with that side-rant out of my system I’ll look at Lineage. Thanks for the tip!
How strong is the compartmentalization between different profiles? Is it comparable to Xen VMs?
The Linux kernel handles device admin
which is responsible for multi-user.
This is weaker than a Xen domain, although some GrapheneOS
mitigations like the hardened user-space heap allocator will make
many bugs more difficult to exploit.
Read more about the problems of the Linux kernel
here
GrapheneOS does say that they’d like to move to
virtualization-based isolation in the future
OK, with that side-rant out of my system I’ll look at Lineage.
How does clipboard sharing work in GrapheneOS? Is the situation similar to Android, where all applications have access to it for reading?
Within a profile, I think yes. There is a setting (IDK what the default is) that can notify you when an app reads the clipboard fwiw.
Once again, after many years google realized that users like you and me want to give access to only some directory, not whole flash storage. Starting from ~ Android 10 it works differently, it opens dialog for directory you want to give access to.
And what can be done if e.g. whatsapp or other proprietary app is reading clipboard all the time on every change? They would say that they do it to make some rare cases more comfortable for users.
Is not convincing. Looks like something written by general Google developer for Android who does not understand enough about security and privacy.
I cannot agree with the statement that having some original Samsung or Xiaomi stock Android on the phone is better for security and privacy than LineageOS with root access (e.g. allows to install firewall and other stuff). Android sucks in security and especially privacy, it was like that for many years.
It’s written by one of the Whonix devs, I’m fairly confident they understand security and privacy better than you do.
Great article, well written, and valuable given that it’s coming from the point of view of a Whonix dev. LineageOS provides a good strawman argument in favor of GrapheneOS for mobile, but I wonder how a fork like DivestOS would fare in their analysis. In terms of privacy, I’ve heard some FOSS advocates argue in favor of DivestOS over GrapheneOS, but without a clear discussion of the security tradeoffs like madaidan’s article provides. The former has one clear advantage over Graphene in that it provides a FOSS alternative to Google’s eSIM management, while also addressing some of madaidan’s criticisms of Lineage.
Getting back to the OP question… It seems to me that, at a high level, prioritizing security hardening makes sense in the mobile context, while prioritizing virtualization/compartmentalization makes more sense in the x86 world, not that these strategies are mutually exclusive.
DivestOS is good if you can’t use GrapheneOS, but you can’t compare the two.
If all you care about is privacy and FOSS then DivestOS is a good choice, if you want the most secure Android device you run GrapheneOS.
You can compile GrapheneOS for any Android device, but only Pixel is officially supported because it’s the most secure platform. It’s not the OS alone that makes the device secure, the device needs to have specific security features, it needs to receive fast firmware updates, and you need to be able to lock the bootloader.
Bootloader relocking is one of the Lineage security issues that DivestOS addresses. From the website: “Bootloader relocking is restored and has been tested working on 23 devices and is available for 26 more. Verified boot is also restored on 36 of those devices and is enforcing once locked.”
And out of the 23 that are working how many are Pixel phones?
Very few phones are able to lock with a custom OS, Fairphone and Pixel are the only ones I know officially supports using a custom OS.
Many phones soft or hard brick if you try to relock the bootloader, I think that is the reason why LineageOS doesn’t support relocking.
I don’t see how GrapheneOS and Qubes are even in the same class of OS’s. If someone would add a community template running GrapheneOS, yes I would use it. I have been looking for a usable Android AppVM but have so far not been able to get any variant running properly thus far. GrapheneOS would be my go-to choice during to the security centered choices made in that OS. The problem is the supported hardware required for it is extreemly narrow and the likelyhood of standing up an x86 derivative is pretty slim. Running it under emulation in Xen isn’t going to be easy.
Could it supplant Qubes? Not even close. Could it be used under Qubes? Doable, but who is going to cross compile it and build the Qubes utilities needed to make it useful?
I would love to see this but it likely won’t happen in my lifetime.
There is already such comparison post on this forum, however, it’s only available to users with Trust Level 2 or higher:
I use both GrapheneOS, on two phones and a tablet, and QubesOS on a Protectli Vault. I wouldn’t say there’s a huge difference in difficulty setting up either to work.
Installation on both was fairly straight forward, both require specific hardware but work simply if you have it. Both I’ve had issues with some programs and had to make sacrifices to get them to work how I need.
It’s not really a choice for me between the two OS’s as both serve their purposes for the job I use them for.
Could you just make this page public? What’s the reasoning behind requiring a threshold trust level?
Graphene OS is just another free Android.
Tried all kinds of Mobile OS’s and on none of them it is possible to activate essential applications for eID and payment without a Google account or Apple ID, not in my country that is.
So i stopped using smartphones totally and returned to a classical GSM (2G)
And for the time the 2G GSM network will be fased out (2028 in my country) i already bought a LTE version that can work on 4G
I’ll only use a smartphone again when the essential payment and eID apps are available for GNU/Linux mobile and can be activated whithout a Google-account or Apple-ID
The initial premise “mobile OS are more secure than desktop ones” is faulty.
I wish it was more open. It’s discussed here: New "general admin, security & privacy" category? - #55 by fsflover.
The “All Around Qubes” category is discussions not directly pertaining to Qubes OS. As for whether it should be public or not, that is decided by the Qubes OS forum team.