I’m frustrated. I’m a long time fan of Motorola. Their phones have been pretty simple and easy to remove junk apps. Recently I got an update that forced perplexity on my phone.
I’m frustrated. I’m a long time fan of Motorola. Their phones have been pretty simple and easy to remove junk apps. Recently I got an update that forced perplexity on my phone.
Root is always a security risk, you really should not. (GrapheneOS comment (on Reddit) about rooting.)
None, probably. Refer to Bootloader Unlock Wall of Shame instead to check which companies do not restrict bootloader unlocking. See here for a list of devices where the bootloader can be locked with custom AVB Keys.
All those rooted concerns are true for desktop Linux / MacOS, and they still ship with sudo. If I can’t rm -rf the root partition then its not really my device.
The bootloader wall of shame is nice.
Android does not have the same security model as desktop Linux. I made a comment about this above (which you probably can’t see due to .world being defederated with who I replied to), but if you don’t want to go to my comment history, it’s summed up as three or so main issues.
Rooting breaks OTA updates since it modifies your partition hash, meaning rooted users tend to leave security holes open way too long. Android does not have a package manager for you to be able to update these issues individually.
Android does not expect users to have root access, so they do not even consider it in the design. Android sandboxes apps, and apps can only generally have permissions that you grant, with no direct access to the kernel. However, rooting adds an entirely new attack surface for which there are no protections whatsoever. Desktop Linux, on the other hand, does expect users to need root level access from time to time. That’s what sudo is for, but you should not confuse this with switching your user entirely to root and doing everything as root. There’s a reason that’s not recommended on Linux: it’s dangerous. The same thing applies to Android. On top of that, Linux has other tools and protections designed to make running as sudoer safer, and Android has none.
Finally, it breaks your ability to use proper verified boot. If your system partions silently get malware installed, there’s generally no way for a user with a rooted phone to notice. Verified boot protects against this, but because rooting (along with whatever else you’re running as root) changes your partition hashes, it will either stop booting or revert your changes.
If mobile Linux ever takes off, it will likely be very similar to desktop Linux and be designed with root in mind.
Touching the system partition isn’t the only thing one would do with root. And if the ROM ships su in the ROM, there’s no problem of being out of sync with upstream or even not passing boot verification.
It does open up an attack surface against the app that provides the UI to gate root access. But that has to be considered against the “availability” arm of the security triad.
Regarding the system partion and verified boot, it’s the fact that it isn’t the only thing one would do with root that breaks verified boot. You totally could package su in the ROM and ship it, but if a user installs something else to the system with it, it is very likely that the verified boot hash would change, unless I’m missing something.
Good guess about the federating problem. Thats a good reminder for me to change instances (was on lemm.ee before it died, .world was my backup).
OTA, while a fair point, again sounds to me like a technical problem, not a fundamental design problem. E.g. disable the partion hash check so OTA can be installed in a timely way.
OTA, as of right now, needs to hash the device to prevent system corruption. I don’t think it’s a very simple problem to solve, or surely there would be a ROM out there that does fix it with root. A better fix would be a package manager, but that’s not going to happen with AOSP.
Regarding #1, it’s fundamental to AOSP, and not any particular ROM. Similar to the OTA issue above. It’s not just graphene (which, technically, you can root fyi, but I really would not do so, as again it defeats the purpose of running a verified boot secured phone).
#2 is debatable, because it’s also highly dependent on the distro and configuration. As an example, immutable distros (which are actually closer to Android than non-immutable distros) make it so sudo/root isn’t needed very often, if at all. Fedora CoreOS, for example, can run package updates on a schedule without user intervention, use rootless containers, and do verified boot. It can be deployed from a single file and validate itself after the fact, meaning a user would never be prompted for a password at any point. Obviously that’s not a 1:1 because it isn’t made for PC usage, but other distros based on Fedora Silverblue and the like can be more secure than standard Linux for similar reasons. Everything is generally sandboxed (flatpaks and containers) and root is rarely, if ever, required.
That being said, if you’re not concerned, there isn’t anything stopping you aside from your phone’s manufacturer, which I’m sure you’re aware of. I’m fine just knowing that I could do it, and much prefer the security benefits of verified boot and proper sandboxing above all else. I don’t trust Google to properly patch zero days related to rooted phones, let alone patch the ones that affected non rooted devices.
Immutable OS’s like nix and fedora silverblue still have sudo, they can still rm -rf /. If they can do it and maintain security, then Android can too.
I agree both the OTA and safe way of doing superuser requests could be heavy technical work. My bigger point is people who manage ROM’s shouldn’t demonize having full control of devices we own. Root can be done safely. Its not an inherent security risk, its just a technical problem waiting for a technical solution. “Just accept you dont need it” is not an acceptable response IMO.
What bothers me a bit more is, the OS could address a lot of what Graphene is talking about: there should be a builtin OS level “no overlays, no accessibility, allowed when superuser reqested, must use builtin OS controlled keyboard to input password”. The OS should design the accessibility permission in such a way that it can’t override a superuser request UI.
deleted by creator