I suppose I could, and will when I get around to it; but that’s not what I made this post for.
Yes, I will.
I’m still not sure why you did
Apps crash? Report to their devs
Apps crash ONLY ON ONE OS? Report to the OS devs (too)
F-Droid should not be in the middle of those reports (unless the app is NOT reproducible, and the app installed from F-Droid has the issue BUT the app installed from the dev does not)
If you reread the first QUESTION (OP), you should see why.
Well no where in this post did I say it should, but if you want to include it here, ok.
It was merely a question to see if anyone (which sounds like an official F NO, from your replies and everyone’s silence) agreed to the logic that it should, since it is the platform the hosts these apps, and would be helpful to both the users & the developers? to do so ( in my trivial opinion) for reasons I mentioned in another post.
That’s all.
Grapheneos? Love it!
2 Likes
How do you like it’s interface with F-Droid?
Any details you like/dislike?
My main suggestion is: stay away from GrapheneOS.
Here is one example, their Gmscompat feature, which, they claim, prevents Gapps from exercising high level permissions. The feature allows to install Gapps into data partition where 3rd party apps also reside. The claim is, Graphene ‘sand boxing’ doesn’t allow System level permission, if the app sits in Data partition.
Some references to AOSP code:
-
Gapps are built as System apps, i.e., with system_uid flag. That’s a fact. No third party app can be built with even a single system-level permision: the build WILL stop with an error - ‘system level permissions not allowed in third party apps’.
-
Gapps also built with a root_uid flag, as otherwise, Google services framework etc., won’t be able to have the full control over your device, which it does.
-
AOSP code automatically grants permissions to anything with system_uid and root_uid flags. Here are just 2 examples from the code:
Look at lines #1065 through 1069. The java code is this:
if (uid == Process.ROOT_UID || uid == Process.SYSTEM_UID) {
// Root and system server always pass permission checks, so don't touch their app // ops to keep compatibility.
return; }
Look at lines 8388 through 8391. The same flags and same granting of permissions:
private boolean verifyPackage(String packageName, int uid) {
if (uid == ROOT_UID || uid == SYSTEM_UID) {
//System and Root are always allowed
return true; }
Note AOSP dev’s comments: Root and system server always pass permission checks’ and ‘System and Root are always allowed’. That tells you all. In addition, location of the app doesn’t matter. You can have any root app in Data and yet it would still be able to exercise Root. The only difference between root apps and Gapps/GSF is that the latter acquires those permissions silently.
So, Gmscompat isn’t just a failure, it’s a dangerous failure, because users get a false sense of security, while in reality, they have NONE.
MOD EDIT: These are personal opinions. Also post edited to clear off the heat.
EDIT: I had no idea opinions were forbidden, but I guess mods can do whatever they want. Also, AOSP code is not a bunch of opinions, but hard facts, and so is the fact that Gapps are built as System apps with high level permissions.
2 Likes
Huh. To tell you the truth honestly even though I am a grapheneOS user I never trusted the compat layer anyways. Or them for that matter
Cause even if it wasn’t for that I do still believe that the google services can still grab way too much sensitive information as it is which the devs have openly admitted to being a issue still.
Then you get to the issue of requiring a google account for the play store is problematic as it can be troubling if there’s a app you want to use that uses the playstore install as a anti tampering mechanism. I don’t really have any of these apps but still.
One of the extra benefits that comes with a microG installation ofc. The main takeaway here is that sadly no matter what you do installing google play services or microG in any form is going to bring a big decrease in both privacy and security. No “solution” or “reimplementation” should be trusted whatsoever
1 Like
The purpose of my post was not the failed Gmscompat, which was just an example, but to show credibility or lack of it in the development.
Gmscompat is one of the main advertising puffs. GOS claim they can literally ‘teach’ Gapps to behave well. You saw the proof to the contrary above.
So, if GOS developers don’t know that Android grants permissions automatically to System and Root Uids, then they don’t know much about Android at all and can’t be trusted. If they do know about permissions, then they are misleading users, i.e., their claims are false, You pick which one is worse.
There isn’t a third option here… .
2 Likes
I am not very familiar with Android, or general phone, code; but I know a thing or two about statement/scripted text code, and it seems you are correct about the couple of lines you provided.
Assuming you are also correct about your observations of GOS; what is a user with a Pixel7 to do?
What other practical, user install (and F-Droid) friendly OS is there available for Android (pixel 7 specifically) users?
2 Likes
You’d be better off with CalyxOS or even Lineage, and if you need Gapps, you can use MicroG.
2 Likes
I personally am wanting to switch to divestOS as I am very much fond of the developer and their works. But sadly I don’t think there is a release for a pixel 8 pro yet provided there will eventually be a release that is.
CalyxOS is good but I’m not really sure how much of a incentive it would be for me to switch to that apart from the obvious. Will have to do some research
Until then I guess I will wait. Gives me time think about how to backup my data too as I am still looking for a effective way to backup data locally and effectively. Preferably without a computer
1 Like
Not a fan for various reasons.
The first thing I noticed about GOS was how they go around literally everywhere and bash other developments. Here is a typical GOS quote: ‘Others just pretend to have security’. Next, they shamelessly insert links to their own development. They even do that in other developers’ threads. That is, in my view, a reprehensible behavior.
Divest dev is known for doing the same.
But it is your choice, of course.
2 Likes
This is completely incorrect and betrays a fundamental misunderstanding of how AOSP works, which for someone who makes their own OS, is pretty unfortunate.
You have been trying to spread this narrative about how GmsCompat works for years now, mainly on Reddit, and it seems you’ve moved to try and do it elsewhere since people on Reddit have started realizing that you’re making stuff up.
None of what you’re saying makes sense. Apps that are installed in the regular app sandbox (which is the only way to install Google Play on GrapheneOS) have zero access to anything that privileged apps would have access to. The entire approach has to do with the fact that the apps do not get additional access over other apps. The code you’re pointing to is completely and entirely irrelevant, something which you would know if you’d taken the time to actually look at GmsCompat.
Please stop trying to make people believe something that is so very obviously incorrect across every platform. You don’t have to like GrapheneOS, but stop lying about it.
3 Likes
LOL. Here we go: a typical GOS hysterical response: cry ‘foul’ ‘lies’ and ‘disinformation’.
Don’t believe me, look at the code. Also, while there think about Root applications which can happily execute Root while sitting in Data partition in your ‘sand box’. LOL again.
I won’t respond to childish personal insults.
There are no insults in my post. The information you have posted is incorrect. Google Play apps on GrapheneOS sandboxed like all other apps. The code you’re referring to does nothing on GrapheneOS because the apps are not privileged. It is not clear whether you know this and are trying to make other people believe it, or if you genuinely don’t understand it.
I would invite you to do the same. How GmsCompat works is very well documented, and the code is open for you to look at and inspect.
This sentence makes no sense. Regular apps on GrapheneOS aren’t given root access. Ironically, I believe that’s something that your project does.
2 Likes
You are talking Gibberish. An app that is built with System_uid or Root_uid gets automatic permission check (allowed) in AOSP regardless of where it is sitting. The only way to prevent that from happening is to remove those flags together with the corresponding code and rebuild the apps, which in the case of Gapps and Google Services Framework is IMPOSSIBLE due to closed sources.
All that GOS literally does in Gmscompat is telling Gapps not to crash and it works. But it can’t prevent them from executing high level permissions available to Root and System apps.
Edit: GOS doesn’t need to do anything to ‘give Root’, it’s already done in AOSP. Gapps, unlike various Root applications, acquire root silently.
if (uid == Process.ROOT_UID || uid == Process.SYSTEM_UID) {
// Root and system server always pass permission checks, so don't touch their app
// ops to keep compatibility.
return;
}
All this code is saying that if a process running on the OS has root or system UID (which user installed apps cannot have) then permissions don’t apply to them.
Since the OS is trusted and only trusted OS components can have those UIDs.
This is de facto false. If Android apps actually worked this way, that would be a de facto privilege escalation hole. Your understanding of the Android platform is fundamentally wrong here.
See my prior comment. And there is no need to modify the apps when you control the OS, which is one of the major concepts of Gmscompat, which introduces shims, for example the GMS app can request the IMEI normally on a GMS device, and on GrapheneOS if the user chooses to install sandboxed Google Play, we allow the GMS app to call it but we stub out the response so it gets no IMEI by doing that within the Android framework instead of modifying the app.
I have no idea what you mean by this. The standard security model forbids user installed applications from obtaining root access of any form, this would be a major privilege escalation issue.
This is architecturally not possible, as they are installed as user installed apps, which cannot do this. The applications run in the same sandbox as any other app, they are not special in that regard. You can easily check the SELinux confinement of any of the user installed apps you install and see that they are confined within “untrusted_app” in SELinux using ADB to verify this.
Are you implying now that Google made apps use 0day/n-day privilege escalation bugs in the wild? That would be very major news, I would love to see some proof of that, maybe we can report this issue to Project Zero together?
2 Likes
Nothing that you’ve said advances any viable argument. Again, look at the code I referenced. It is from AOSP. If you can’t read Java, ask someone who can. What those code quotes say is this:
If an app or process has System_UID or Root_UID flags, they automatically pass permission and app verification checks. They don’t need to ask for or escalate anything. That’s precisely what the AOSP dev’s comments say: Grant permissions and don’t touch them. Also, those flags are shared meaning, more than one app or process can have them.
As far as Gapps: there is no escalation or zero day tricks. Gapps and GSF are DESIGNED and BUILT with System and UID flags. They are by definition TRUSTED. No OS can function without certain processes and/or apps having those flags. Normal apps cannot be built with those flags or any System level permission: the build will stop with an error: ‘this is a System level permission’ which is not allowed in third party apps. Gapps are NOT third party apps.
Again, your argument is not with me, but with the code.
P.S. By the way, you think calling someone a ‘liar’ who spreads ‘misinformation’ is not a personal insult?! LOL.
Edit:
All this code is saying that if a process running on the OS has root or system UID (which user installed apps cannot have) then permissions don’t apply to them.
It is simply WRONG. If an app or process has System or Root UID flag, it is granted permissions regardless of the location. You don’t get high level permissions by putting a third party app into System, because that app is not BUILT with System_UID flag. Similarly, a System app does not magically lose its high level permissions, if you put it into Data.
1 Like
The code allows processes running as system or root UID to bypass permissions. Only trusted OS code is able to run with system UID or root UID.
Processes will only be able to obtain system UID or root UID if they were built into the OS. You can see more information on how sharedUserId declarations work here: <manifest> | Android Developers Now last I checked, we don’t sign GrapheneOS with the signing keys used for Google Play Services (we are not Google and even Google uses different signing keys for the stock Pixel OS), and we don’t modify/resign any Google apps as part of how sandboxed Google Play works. So due to the signature mismatching, the apps literally by architectural design of Android cannot obtain the ability to run under the system UID or root UID.
See my prior answer, because they are installed as user installed apps and their signing certificates do not match that of the OS, the sharedUserId value in their AndroidManifest is simply ignored. This is just a complete misunderstanding of how Android works. You appear to be under the impression that anyone can just set their app to use system UID or root UID, which would be by definition a privilege escalation vulnerability.
I eagerly await your proof of concept app for achieving root on GrapheneOS by declaring android:sharedUserId="android.uid.system" in its manifest.
I think it should be clear to everybody reading this thread that what you’re claiming is straight up incorrect. I also understand that no matter how much I explain this to you, and how much many sources I point to to explain why you’re incorrect, you are never going to admit to being wrong, because that would be embarrassing. The only reason I’m engaging and debunking your claims here is because you’re wording things in ways that make what you’re saying plausible to people without a technical understanding of how Android or GmsCompat works.
3 Likes
You haven’t explained anything except for this:
We don’t sign GrapheneOS with the signing keys used for Google Play Services (we are not Google and even Google uses different signing keys for the stock Pixel OS),
And even that statement doesn’t make any sense, except identifying you as a part of GOS. LOL.
What you don’t understand is that when an app has System_UID or Root_UID it is already trusted regardless of the signature, because such an app can only be built in a rom environment. In other words, you can’t build it by using Android SDK outside of the rom environment. So, on a device with locked bootloader that uses a different flavor of Android (custom rom), such an app can’t be installed into System, because it would break the verified boot. But, thanks to Gmscompat, you can install that app into Data, which GOS users do. As a result, they have a perfect Trojan horse, i.e., an app that has System and Root UID in Data partition, an app that passes all Android permission checks and verifications. That plus the sense of false security.
What else could go wrong?
Edit: I just got a friendly notification that we could take this discussion private. So, I am ending it here. Please abstain from usual GOS tricks, like posting numerous links to the project.
Best regards
1 Like