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.

▲

cakealert 3 days ago | parent | next [-]

> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.

The same is true even of an operating system such as QubesOS. And it's a minimal risk.

Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.

	▲	bbarnett 3 days ago \| parent [-]
		It's useful for general use just fine. But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.

▲

yjftsjthsd-h 3 days ago | parent | prev | next [-]

EDIT: This is a reply to the 2nd(?) version of your comment before it was silently changed into something different.

Yes, I'm sure it is. But I don't consider that a tolerable tradeoff, and I believe we could have a system that has most of the best of both worlds.

▲

ysnp 3 days ago | parent | prev | next [-]

>This is not what people are referring to when they talk about rooting on Android

Would this have been easier or more possible if Android had a full capability-based security model?

▲

yjftsjthsd-h 3 days ago | parent [-]

Arguably Android has a capability-based security model, though it suffers from being ... well, it's not what you'd build if you were doing it from scratch today. Hindsight is 20/20. But I'd tentatively say not really, because the point of root is to get outside the existing capabilities. As an example: For a while, the most common root app I ran was one to limit charging to 80% or whatever to make the battery age more gracefully.[0] The whole reason that needed root is because there wasn't a capability/permission for that; the app couldn't ask the OS to let it control charging, because nobody even thought to expose that API surface.

[0] This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.

▲

ysnp 3 days ago | parent [-]

>This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.

For what it's worth, my understanding is that this has always been the position of GrapheneOS too. Given the resources and enough benefit/cost to allocate, the project would rather integrate or implement usability features at the OS level instead of encouraging people to expose attack surface. Specifically because GrapheneOS is a project meant to be primed to defend some of the most intimate and personal aspects of a person's life.

	▲	yjftsjthsd-h 3 days ago \| parent [-]
		Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.

▲

yjftsjthsd-h 3 days ago | parent | prev [-]

Quoting inline since parent has been rewritten multiple times now...

> 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.

Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think

> An accessibility service trivially has root access.

is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.

> 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.

I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.

> 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.

Agreed, that's not what I want.

▲

ranger_danger 3 days ago | parent [-]

> Android has an established way to handle permission dialogs that require the user to confirm their approval

With the advent of choicejacking I don't think I want to trust permission dialogs anymore.

> including use of fingerprint/PIN/password to authenticate

IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.

▲

yjftsjthsd-h 3 days ago | parent [-]

> With the advent of choicejacking I don't think I want to trust permission dialogs anymore.

So you're using a version of Android patched to remove all permissions? After all, in your threat model all apps can get permission to use the microphone and camera, make phone calls, access fine-grained location information, read and write files at will, etc. Frankly, I'm not sure what they'd get out of root at this point.

> IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.

Likewise, surely this applies to any permission system, and every other permission. The system UI controls every other permission in the system; if we assume it compromised, then everything else is already lost.

▲

codethief 3 days ago | parent [-]

> Frankly, I'm not sure what they'd get out of root at this point.

A permission that allows them to hide that they have access to everything, including other apps' data?

	▲	yjftsjthsd-h 3 days ago \| parent [-]
		Possibly. Yes, hiding from auditing would be a possible advantage, but I think an app with accessibility permissions could already draw over the settings app to hide the real list of permissions from your view without root. Off the top of my head I think there's a whole mess of permissions needed to allow that, but we're discussing a threat model where permission dialogs can be effectively bypassed so that's no obstacle.