3 ms·

I couldn't immediately find whether GrapheneOS grants READ_PRIVILEGED_PHONE_STATE to Google Play. It might very well be that the GrapheneOS sandbox spoofs a fak

by asnelt 25d ago

I couldn't immediately find whether GrapheneOS grants READ_PRIVILEGED_PHONE_STATE to Google Play. It might very well be that the GrapheneOS sandbox spoofs a fake IMEI, and I do hope so. In any case, my parent comment was meant for stock Pixels, as mentioned by armadyl further up in this thread.

nickspacek 25d ago
https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play > Google Play receives absolutely no special access or privileges on GrapheneOS as opposed to bypassing the app sandbox and receiving a massive amount of highly privileged access. It doesn't mention IMEI here, but hopefully READ_PRIVILEGED_PHONE_STATE is included in "privileged access."
- exceptione 25d ago
  There is an AppStore app, I am not sure if this is the one we are talking about? <https://github.com/GrapheneOS/AppStore/blob/main/app/src/main/AndroidManifest.xml https://github.com/GrapheneOS/AppStore/blob/main/app/src/mai...> That one lists: ACCESS_NETWORK_STATE ENFORCE_UPDATE_OWNERSHIP FOREGROUND_SERVICE FOREGROUND_SERVICE_SPECIAL_USE INSTALL_PACKAGES INTERNET POST_NOTIFICATIONS QUERY_ALL_PACKAGES RECEIVE_BOOT_COMPLETED REQUEST_DELETE_PACKAGES REQUEST_INSTALL_PACKAGES UPDATE_PACKAGES_WITHOUT_USER_ACTION
  - gruez 25d ago
    That's grapheneos's own app, separate from the play store or play services.
    - exceptione 25d ago
      True. I think this one is closer to the truth: <https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/blob/17/AndroidManifest.xml https://github.com/GrapheneOS/platform_packages_apps_GmsComp...> There is no READ_PRIVILEGED_PHONE_STATE mentioned there.
      - gruez 25d ago
        That's also incorrect, because the gmscompat app is just a helper app. Play services can and does request additional permissions. Those permissions are handled by the OS under the play services app, not gmscompat. If you want RCS for instance, you must grant play services and google messages phone and ICC auth access, which isn't seen in gmscompat at all.
        exceptione 25d ago
        > That's also incorrect, because the gmscompat app is just a helper app. Hmm, ok. I was reasoning the helper app was needed to get around the default assumptions from Google Play Services. > Those permissions are handled by the OS under the play services app Yes, but I assume you don't mean that as that GOS makes special hard-coded provisions for the play services. GOS claims to run Play Services like any other unprivileged app, and so any additional permission it would want would have to be consented by the user and should be visible to the user. If not, then GOS wording would be quite a bit unfortunate at least. EDIT: "GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims." [1] This seems to indicate that the permissions requested by Play Services are being honored with the shims from the helper app. That would alleviate the permission problem. 1. https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases https://github.com/GrapheneOS/platform_packages_apps_GmsComp...
        grapheneos 23d ago
        Google Mobile Services apps installed on GrapheneOS including Play services run as regular sandboxed apps. They receive absolutely no special access compared to other apps by installing and running them. There are the standard permission toggles for granting those but none of those are required for typical usage to provide compatibility with many apps from the Play Store depending on their services. There are additional special permission toggles for RCS and Android Auto. The issue with RCS is mainly that they split the implementation across Google Messages and Play services. Android's standard permission model gives special access to the app selected by the user as the messaging app but Google Messages expects Play services to have special access too. The shims defined with GmsCompatConfig are a small subset of the overall compatibility layer. It has many shims which need to actually implement the functionality such as remapping the Play Store using privileged installation APIs to the regular ones available to user installed app stores. It has to remap the APIs used by dynamite modules to ones not requiring privileged SELinux policies too. It has a mix of shims which simply stub out the functionality and many which need to handle it as a regular sandboxed app would need to do it.
grapheneos 23d ago
The only way to install Google Mobile Services apps including the Play Store on GrapheneOS is as regular sandboxed apps. They aren't granted any of the large number of usual privileged permissions, don't run with the usual far more privileged SELinux policies, aren't used by the OS as a backend for anything and aren't otherwise allowed to do special things by the OS in the usual many ways that is granted. They're regular sandboxed apps on GrapheneOS.

by asnelt 25d ago

nickspacek 25d ago

https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play > Google Play receives absolutely no special access or privileges on GrapheneOS as opposed to bypassing the app sandbox and receiving a massive amount of highly privileged access. It doesn't mention IMEI here, but hopefully READ_PRIVILEGED_PHONE_STATE is included in "privileged access."

exceptione 25d ago
There is an AppStore app, I am not sure if this is the one we are talking about? <https://github.com/GrapheneOS/AppStore/blob/main/app/src/main/AndroidManifest.xml https://github.com/GrapheneOS/AppStore/blob/main/app/src/mai...> That one lists: ACCESS_NETWORK_STATE ENFORCE_UPDATE_OWNERSHIP FOREGROUND_SERVICE FOREGROUND_SERVICE_SPECIAL_USE INSTALL_PACKAGES INTERNET POST_NOTIFICATIONS QUERY_ALL_PACKAGES RECEIVE_BOOT_COMPLETED REQUEST_DELETE_PACKAGES REQUEST_INSTALL_PACKAGES UPDATE_PACKAGES_WITHOUT_USER_ACTION
- gruez 25d ago
  That's grapheneos's own app, separate from the play store or play services.
  - exceptione 25d ago
    True. I think this one is closer to the truth: <https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/blob/17/AndroidManifest.xml https://github.com/GrapheneOS/platform_packages_apps_GmsComp...> There is no READ_PRIVILEGED_PHONE_STATE mentioned there.
    - gruez 25d ago
      That's also incorrect, because the gmscompat app is just a helper app. Play services can and does request additional permissions. Those permissions are handled by the OS under the play services app, not gmscompat. If you want RCS for instance, you must grant play services and google messages phone and ICC auth access, which isn't seen in gmscompat at all.
      - exceptione 25d ago
        > That's also incorrect, because the gmscompat app is just a helper app. Hmm, ok. I was reasoning the helper app was needed to get around the default assumptions from Google Play Services. > Those permissions are handled by the OS under the play services app Yes, but I assume you don't mean that as that GOS makes special hard-coded provisions for the play services. GOS claims to run Play Services like any other unprivileged app, and so any additional permission it would want would have to be consented by the user and should be visible to the user. If not, then GOS wording would be quite a bit unfortunate at least. EDIT: "GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims." [1] This seems to indicate that the permissions requested by Play Services are being honored with the shims from the helper app. That would alleviate the permission problem. 1. https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases https://github.com/GrapheneOS/platform_packages_apps_GmsComp...
        grapheneos 23d ago
        Google Mobile Services apps installed on GrapheneOS including Play services run as regular sandboxed apps. They receive absolutely no special access compared to other apps by installing and running them. There are the standard permission toggles for granting those but none of those are required for typical usage to provide compatibility with many apps from the Play Store depending on their services. There are additional special permission toggles for RCS and Android Auto. The issue with RCS is mainly that they split the implementation across Google Messages and Play services. Android's standard permission model gives special access to the app selected by the user as the messaging app but Google Messages expects Play services to have special access too. The shims defined with GmsCompatConfig are a small subset of the overall compatibility layer. It has many shims which need to actually implement the functionality such as remapping the Play Store using privileged installation APIs to the regular ones available to user installed app stores. It has to remap the APIs used by dynamite modules to ones not requiring privileged SELinux policies too. It has a mix of shims which simply stub out the functionality and many which need to handle it as a regular sandboxed app would need to do it.

grapheneos 23d ago

The only way to install Google Mobile Services apps including the Play Store on GrapheneOS is as regular sandboxed apps. They aren't granted any of the large number of usual privileged permissions, don't run with the usual far more privileged SELinux policies, aren't used by the OS as a backend for anything and aren't otherwise allowed to do special things by the OS in the usual many ways that is granted. They're regular sandboxed apps on GrapheneOS.