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.