I'm lucky my banking app works (GrapheneOS), as it's now requiring 2FA with the app anytime I login on the browser. Can't use an actually secure form like TOTP. At least they now allow passwords over 8 characters (yes, serious).

(Meme in comments)

you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 2 years ago (32 children)

Beat the main purpose of GrapheneOS. Open the phone to a broad lot of security issues.

  • source
  • parent
  • hideshow 32 child comments
  • [–] 27 points 2 years ago (12 children)

    Graphene only works for Pixel phones, and I don't want a Google device.

  • source
  • parent
  • hideshow 12 child comments
  • [–] [S] 5 points 2 years ago (8 children)

    thats fair. device support is a major downside of GOS. but, remember: its not really the fault of the OS, as it requires a lockable/unlockable bootloader, which only pixel phones provide (at least in terms of mainstream phones). blame the OEMs like samsung

  • source
  • parent
  • hideshow 8 child comments
  • [–] 4 points 2 years ago (3 children)

    There are a ton of unlockable bootloaders. On my OnePlus that's a matter of flipping a switch in the settings.

  • source
  • parent
  • hideshow 3 child comments
  • [–] [S] 4 points 2 years ago (2 children)

    can it be re-locked? i may be wrong, btw. this is just what ive heard.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 2 years ago* (3 children)

    which only pixel phones provide (at least in terms of mainstream phones)

    Mainstream phones? Pixel is a smaller market share than Motorola, and Motorola has unlockable bootloaders, and lineage supports a fair number of them.

  • source
  • parent
  • hideshow 3 child comments
  • [+] -17 points 2 years ago (2 children)
  • [–] 1 point 2 years ago

    Only big manufacturers can really pay to control entirely the hardware inside it, and allow you to modify it. Checkout Fairphone for example. They've been forced to stop hardware security updates due to their chip manufacturer, who refused to continue supporting it, despite them trying to support their devices for plenty more years. This explains the choice with Google.

  • source
  • parent
  • [–] 15 points 2 years ago (7 children)

    What are the security issues? Rooted just means the potential to give trusted apps root access. Of course, if you give an app root access that you trust but is then abusing that trust and being malicious, yes it's a security issue. But if you don't do that, the simple fact of having a rooted phone should have no security change in any way. (Ok, except for potential bugs in Magisk/su or whatever)

  • source
  • parent
  • hideshow 7 child comments
  • [–] 17 points 2 years ago* (last edited 2 years ago) (1 child)

    The whole issue revolves around the fact Google is presuming a device is compromised or being used for illicit shit simply because root access is possible. If they put in effort to detect/prevent the actual problems they're concerned about, this wouldn't be as big a deal. This broad punishment for simply having root access is lazy and ridiculous.

    It's like if Windows apps just stopped working if they detected a local admin account. It's patently absurd to assume the ability to access anything means the device is inherently "unsafe".

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 years ago* (last edited 2 years ago) (4 children)

    https://www.reddit.com/r/GrapheneOS/comments/13264di/comment/ji54e19/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

    If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.

    In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.

    A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 years ago (3 children)

    I'm pretty sure whoever wrote that was talking out their ass. The fuck is "UI layer" on Android, or rather, what does it have to do with it xD

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 2 years ago* (2 children)

    The actual Magisk prompt that ask you if you want to give root to such app. This UI layer.

    Although, i suppose it could be countered by explicitly refusing all requests or enabling a biometric confirmation

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 years ago (1 child)

    But granting root is not done by "the UI layer", "the UI layer" is not running with root. There is no such thing as "the UI layer" as a separate entity, an app can have a UI layer as part of its architecture, but the UI is not running on its own. Just because Magisk shows you a UI for you to grant/deny a root request, that doesn't make it insecure. Nothing is able to interact with this prompt except the Android kernel/libraries itself and Magisk.

    Only if you added an application as accessibility tool (or give it root) can it interact with anything within the UI. An app with a UI is generally not much different than an app on the command line.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 years ago

    It still create an attack vector, as it allows a potential extra method to get access to it, in addition of potential hardware exploits that i shared to gain root. Yes, you can minimize the risks correctly, but the user is the only real barrier against it, not the software anymore. The less potential way to exploit your phone, the better it is. You shouldn't rely on thinking that such feature is fully attack-proof.

  • source
  • parent
  • [+] -22 points 2 years ago (9 children)

    GrapheneOS is made by diva developers who frankly should not be trusted. "We only allow Google phones to run our OS!" as if they don't have a backroom deal with Google.

  • source
  • parent
  • hideshow 9 child comments
  • [–] [S] 3 points 2 years ago (2 children)

    genuinely curious; can u elaborate on the deal with google?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 2 years ago (1 child)

    Pure wild speculation if I'm honest, however I'd be more surprised if I was completely wrong. It's always seemed sketchy the way Google have basically said "Use our phone, it's more secure!" with their Nexus and Pixel phones - this was long after the time Google stopped not being evil. At best, the security problems have simply changed manufacturer. Also, Google have a history of undermining development of circumvention, eg hiring the developer of MicroG and forcing him to stop development as a term in his contract.

    The diva part is widely known, GrapheneOS developers don't play nice with the rest of the custom development community. So, while I can't substantiate any actual deal between them and Google, it's the perfect recipe.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 years ago (3 children)

    Proove us that you can get better security while remaining able to be fully modified with other phones and brands. https://www.privacyguides.org/en/android/#divestos

  • source
  • parent
  • hideshow 3 child comments
  • [+] -8 points 2 years ago (1 child)