Andromxda 🇺🇦🇵🇸🇹🇼

Mastodon: @Andromxda@hachyderm.io

wiki-user: Andromxda

  • 19 Posts
  • 1.21K Comments
Joined 7 months ago
cake
Cake day: March 22nd, 2024

help-circle



  • Can you elaborate on MicroG needing root? To my understanding that is only required on ROMs that don’t require Sig. Spoofing, and Calyx does support it, specifically and only for MicroG.

    I’m not entirely sure if all of microG needs to run as root, but I’m pretty sure that some parts do. Nonetheless, microG runs in the priv_app SELinux domain instead of untrusted_app, reducing the isolation and granting it more access to sensitive APIs. Sandboxed Google Play on GrapheneOS on the other hand is a normal application that can be installed and uninstalled by the user, running in the untrusted_app domain. It is tightly controlled by the Android permission mechanism, and doesn’t have any permissions by default.


  • If you only care about security, you should keep Play Services isolated in a separate profile. That way, even if there happens to be a memory corruption vulnerability in Play services, which isn’t caught by hardened_malloc or the hardware MTE in newer devices with ARMv9 chips, the rest of your system would still be safe, since Play services aren’t running as root, and in order to compromise the entire system, there would need to be a privilege escalation vulnerability in all of Android, not just Play services.

    And you know what helps reduce risk of exploit? Smaller codebases.

    Why does CalyxOS include the F-Droid privileged extension then? It’s yet another component running with elevated permissions and unnecessarily increasing attack surface. Why does it include Google’s eUICC component with elevated privileges and no proper sandboxing?





  • Just about all of your identifying data is stripped out by the framework before interacting with Google at all

    For all of them, we strip device identifier (MAC addresses, IMEI, etc)

    This is literally nothing special, as all user-installed apps are denied access to identifiers like the IMEI and MAC address since Android 10. Since GrapheneOS isolates Play services in the Android application sandbox, they don’t have access to any of these identifiers either.

    I’m not too worried about memory exploits as I don’t really install apps

    That’s not how memory corruption exploits work. These can occur anywhere in the system, and just need to be triggered by an attacker. This doesn’t require you to install an app, receiving a rogue message might for example be enough to exploit a memory vulnerability in the SMS app. Visiting a rogue website, which loads malicious JavaScript can be enough to trigger a memory corruption vulnerability in the Chromium WebView. That’s why GrapheneOS doesn’t just use hardened_malloc, but it also disables the JavaScript JIT compiler in Vanadium by default, and offers a toggle in the settings to disallow JavaScript JIT compilation in all apps making use of the system WebView component.


  • but why run it at all?

    Because it is unfortunately required by some apps. microG is not a viable alternative, as it requires root access on the device, which drastically reduces the security. It also has worse compatibility than Sandboxed Play services, and doesn’t offer much of a benefit. It still downloads and executes proprietary Google blobs in the background in order to function. Apps that require Google services also include a proprietary Google library, making microG essentially useless. It’s an open source layer that sits between a proprietary library and a proprietary network service, using proprietary binaries and requiring root access. You gain absolutely nothing from using it, and significantly increases the attack surface of your device.

    fully open source emulator

    This is simply false, as I explained, only a tiny bit of what microG requires to function is open source

    You’re far better off using Sandboxed Play services on GrapheneOS





  • I don’t mean to discredit your opinion, but it is pure speculation and falls in the category of conspiracy theories. There are plenty of compelling arguments, why this is likely completely wrong:

    • Google Pixels have less than 1% of the global smartphone market share, in fact, they are currently only sold in 12 (the Pixel 9 is sold in 32 countries, my bad, I had an outdated number in mind) countries around the world. Do you really think that Google would spend all the money in research, custom manufacturing, software development and maintenance to extract this tiny bit of data from a relatively small number of users? I’d say more than 90% of Pixel owners use the Stock OS anyways, so it really doesn’t matter. And Google has access to all the user data on around 70% of all the smartphones in the world through their rootkits (Google Play services and framework, which are installed as system apps and granted special privileges), which lets them collect far more data than they ever could from Pixel users.
    • Keeping this a secret would also immensely difficult and require even more resources, making this even less profitable. Employees leave the company all the time, after which they might just leak the story to the press, or the company could get hacked and internal records published on the internet. Since this would also require hardware modifications, it’s also likely that it would get discovered when taking apart and analyzing the device. PCB schematics also get leaked all the time, including popular devices like several generations of iPhones and MacBooks.
    • Lastly, the image damage would be insane, if this ever got leaked to the public. No one would ever buy any Google devices, if it was proven that they actually contain hardware backdoors that are used to exfiltrate data.