Hello, making this post to get some honest, and technical opinions about GrapheneOS. Please do not be bother by this question. No drama here pls 🙏. I’ve heard that there is some of the google code into the “sandbox” feature. Say your opinion below! 👇👇

  • Andromxda 🇺🇦🇵🇸🇹🇼@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    6 months ago

    All your points are true, yet still depend on Google in sandboxed form. That negates everything else for me, who wants a reasonably secure device that works out of the box and also respects my privacy.

    Graphene doesn’t “depend” on Sandboxed Play services. In fact, it’s not installed by default, and it is totally optional. Also, Sandboxed Play services doesn’t make your device less secure in any way, it can be installed as a normal user app, you can fully control access to sensitive parts of your device like the microphone, camera, location, etc. through the Android permission manager, and Play services don’t have any special permissions, since it’s not installed as a system app. As far as I’m aware (correct me if I’m wrong) you can’t remove microG on Calyx, since it’s installed as a system app and even granted root privileges. microG is a cheap, hacked together workaround, which requires root to function correctly. This greatly expanded attack surface makes it inherently insecure. microG also requires proprietary Google code to be run, in order to work (most of microG is open source, but it still uses some Google blobs). As far as I’m aware, this Google code is not sandboxed, and simply executed as a child process of microG (which runs as root), meaning that this Google blob is also run as root. This makes microG much more insecure than Sandboxed Google Play services, and it potentially gives Google much greater access to your device compared to the sandboxed approach.

    If a nation-state wants into my phone, it’s delusional to believe even graphene can hold them off

    The GrapheneOS team never claims that their OS is “NSA-proof”, but they actually look at which parts of the OS are commonly exploited by (nation-state) hackers, and massively improve them. As you can see in this spreadsheet, created by Google’s Project Zero, most vulnerabilities in Android come from memory corruption. That’s why GrapheneOS’s biggest and most important feature is their custom hardened memory allocator. It protects against most memory-related exploits, and is even stronger when used on a device with hardware memory tagging, which is the reason why GrapheneOS currently only supports Google Pixel devices.
    Another significant security feature is secure app spawning. Creating new processes via exec (instead of using the traditional Zygote model on Android) randomizes the initial memory layout, which also helps to defend against memory-related vulnerabilities. The aspects I just mentioned are important protections about malware/remote code execution.

    GrapheneOS also protects your device against physical attacks, e.g. by implementing a driver-based control mechanism for the USB-C port, making it impossible to connect to the device while it’s locked. This protects against forensic data extraction, e.g. using Cellebrite or XRY hardware.

    Graphene even has a feature that protects you, when you are forced to give up your password. The Duress feature let’s you set a second PIN/password, which will cause the device to entirely wipe all the encryption keys, which are used for unlocking the device, from the secure element. This process is irreversible, can’t be interrupted and happens instantaneously, making the data impossible to recover.

    No one claims that GrapheneOS is 100% secure and will absolutely protect you against NSA hackers, but it is by far the best and most secure mobile OS that’s currently out there. It is easy to use for everyone, and secure enough to be used by high-profile targets like Edward Snowden.

    you need real opsec for that

    Good OPSEC includes a secure operating system. Calyx is not security focused whatsoever, it rolls back standard AOSP security features, significantly increases attack surface, and doesn’t release security patches regularly.

    Happy cake day btw!

    • RubberElectrons@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Sorry, “google blobs”? A lot of work went into MicroG, and I think it’s a shame that you’d minimize so much good work to reimplement the lynchpin of Google’s control on your devices.

      At this point I’ll presume you’re just misinformed, as no proprietary google code operates within microG unless you decide to run with device attestation, and there it’s running as a sandboxed service. At any other time, you are able to run open source code which spoofs your device details to Google, and spoofs google to all these other closed source apps in a reliable and readable, much smaller codebase.

      Honestly, the irony of running blobs, when one is completely closed source vs the other which is fully open. Hahaha.