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.
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?
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
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.
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.
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.
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.
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?
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.
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.
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.
Why are you saying this like it’s some hidden fact? I quite literally made an account here with the same name and avatar as I use everywhere else. matchboxbananasynergy - GrapheneOS Discussion Forum is my GrapheneOS forum account.
I felt compelled to make an account here and debunk what you’re saying because people were being misled. We’ve had similar conversations before on other platforms, but unlike those other platforms where you block people so that your statements cannot be debunked, this can’t be done here.
This is literally contradicting the documentation I have linked. Being able to only build something in a particular environment means nothing. You again seem to think that you can do privilege escalation to root, which would be a vulnerability, and is not possible.
You can install Google Play Services or Google Services Framework which doesn’t even have a declaration of android:sharedUserId="android.uid.system or android:sharedUserId="android.uid.root and instead has a declaration of android:sharedUserId="com.google.uid.shared" (so they can talk to each other, which is a standard part of Android, this is working as intended) (anyone can crosscheck this by decompiling with apktool) or any other app which has android:sharedUserId="android.uid.system" or android:sharedUserId="android.uid.root declared in its manifest just fine on any Android OS as a user installed app (obviously you can’t install Google Play Services as a user installed app on a GMS Android OS).
GmsCompat does not change the ability for users to install apps which have sharedUserId declarations. To state otherwise is objectively wrong.
Verified boot doesn’t factor in here because user installed apps are architecturally not installed to read only partitions.
I encourage users reading this who have doubts to try install Google Play Services or Google Services Framework on an AOSP variant of the Android emulator (not Google Play Services variant, since those already have the apps preinstalled of course) in Android Studio by installing Google Play Services apk into it and seeing for themselves that it is possible, and then you can use a decompilation tool such as Apktool to clearly see that there is no android:sharedUserId="android.uid.system" or android:sharedUserId="android.uid.root declaration in AndroidManifest.xml, which even if there was, would do nothing since the signatures would not match that of the OS they are running on. You can also demonstrate the ability of being able to install applications with android:sharedUserId="android.uid.system" or android:sharedUserId="android.uid.root" by just building an app with that declaration in its AndroidManifest.xml in an AOSP build environment and trying to install it.
Here is a GIF showing the installation of Google Play Services as a user app on the AOSP emulator.
This is completely false. Please see my prior responses along with cited sources. You are objectively wrong here and I’m hoping that people will take the time to read through these replies and try this stuff out for themselves to see that this is the case.
There are absolutely no “tricks” here. I’m merely providing evidence that what you’re claiming isn’t the case. If you’re going to be making claims like this, they should stand up to scrutiny, and people who are being convinced because they may not know any better should have the chance to see the other side of the coin (with sources) and try things out themselves.
I am happy to leave things here and don’t want to violate any rules, but I similarly don’t want to let people be misled, so I had to provide an explanation.
Here you go. You could’nt help yourself and started posting links.
By the way, you just replied to my month-old post on Reddit and then immediately blocked me so that I couldn’t respond. LOL.
I am not playing these silly games. As I’ve said. I am done here. Forum users can read and form their own opinions.
End of transmission.
Edit: @triptamine, another ‘profie’ created 10 minutes before posting:
I understand what you are saying, but uid ## on Android don’t mean the same thing as on Linux. Example: check System Update in your rom. It will have a number similar to that of any third party app like ‘10256’, not ‘1000’. Yet, System Update can write to ALL phone’s partitions, which means total control.
Links that are 100% relevant to what is being discussed, yes.
Very much agreed! Hopefully the next time you try to make this claim, you’ll point people to this conversation, so that they can actually hear from the other side and make up their own minds. Thank you for the opportunity.
I just checked, I sideloaded a temporary root, and set App Manager with root permissions via KernelSU so I could see the signatures of all Sandboxed Google Play apps and the UID’s of the apps. This is what they are really installed as:
Google Play Services: UID: 10252 (shared /w Google Services Framework) 3 Signatures signed by Google Inc. NOT by my system certificates, which are signed by me, Tryptamine, or GrapheneOS (my own build. On regular releases by GrapheneOS ALL system apps are signed only by GrapheneOS. Same signatures and UID for Google Services Framework {Shared UID}).
Google Play Store: UID 10251 3 Signatures signed by Google Inc. Same as above.
System apps on GrapheneOS (that have full system permissions) have UID of 1000. Root apps have UID 0. I have NEVER seen a single app in an official GrapheneOS build, or my own build with UID 0, full root privileges! It would be unnecessary and giving too much privilege to any one app. Even the base “GrapheneOS” app is only “1000!”
Most system apps in GrapheneOS also may be signed by my build keys (release key, not the higher trust platform key), but they don’t have UID 1000. They don’t need full system permissions, so they don’t get them! Only very few system apps need full system permissions. This is a sign that GrapheneOS is working on the principal of least privilege. Which is a great thing!!
Yes, also I can see the SELinux policy is also not the same for the Sandboxed Google Apps as it is for the system apps:
System:
Closed the topic to take the heat off. Kindly take it to PM like Optimum already received request. @optimumpro@mbananasynergy
This forum can very well do without personal hitting and heated arguments. Kindly refrain from doing so, to maintain harmony.
Have reopened and I wish everyone follows sensibility and let us have this data driven and not personal, unless positive in nature.
Also, let us just have no finger pointing.