Privacy

hideshow 10 child comments

parent

[–] AmbiguousProps@lemmy.today 13 points 1 year ago* (8 children)

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.

hideshow 8 child comments

parent

[–] planish@sh.itjust.works 5 points 1 year ago (1 child)

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.

parent

hideshow 1 child comment

[–] AmbiguousProps@lemmy.today 1 point 1 year ago

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.

parent

[–] jeff_hykin@lemmy.world 1 point 1 year ago* (last edited 1 year ago) (5 children)

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 is a technical problem. Desktop systems get timely OTA updates. Its perfectly possible for rooted Android to get security updates that are on-par with rooted (e.g. basically any) Linux systems. The hash can be done on the incoming update instead (integrity hash) instead of on the system.

Linux has other tools and protections.

If there are protections they're at the system level (not app space). Which means the ROM provider could/should add those same protections as Linux instead of saying "you dont need root, stop asking".
AFAIK there are, unfortunately, basically no protections on Linux. Sudo can be trivially shimmed (add malicious exe to PATH) without even having sudo permissions, then the next time user inputs sudo an attacker would have their password. Its bad that its so easy, but its a double standard to say Linux is fine but an (up to date) Android with root is vulnerable.

hideshow 5 child comments

parent

[–] AmbiguousProps@lemmy.today 2 points 1 year ago (1 child)

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.

parent

hideshow 1 child comment

[–] jeff_hykin@lemmy.world 2 points 1 year ago

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.

parent

[–] ScoffingLizard@lemmy.dbzer0.com 1 point 1 year ago (2 children)

Wait, what? Like there are no protections on PATH and you're saying that sudo can be hijacked and replaced with simething that does the same thing but with a keylogger.

hideshow 2 child comments

parent

[–] jeff_hykin@lemmy.world 1 point 1 year ago* (1 child)

Yeah try it. It is concerningly easy. Write a program that edits the users bashrc/zshrc. Have it append a line that adds something to the front of the path, and have it shim sudo. You can even have it forward the password to the real sudo.

Instead of waiting for the user to open another shell, you can also open a subshell. (E.g. your malicious program never returns/exits, it just appears to exit by opening a subshell with the modified path)

parent

hideshow 1 child comment

[–] ScoffingLizard@lemmy.dbzer0.com 1 point 1 year ago

Aaaaaand, now I want to check the source code of all git repos before doing a git clone. Damn. Yeah, Ill test it out. Thanks for the heads up. Now I know why it's so dumb to run yay as root.

parent

[–] jeff_hykin@lemmy.world 0 points 1 year ago* (last edited 1 year ago)

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". I'm not saying the graphene team needs to do more work; their contributions are incredible. But they shouldn't claim that having full control over a device you own is inherently a security flaw. Its a technical problem that can be resolved with ROM development.