> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.

> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.

It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.

> I dint understand why you insist on this massive risk to be laid on on everyone.

Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.

▲

subscribed 3 days ago | parent [-]

No, it is very easy.

You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.

Use your own keys to sign and you're golden.

The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't.

I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both.

It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.

And lastly, it's okay if you don't consider it a massive risk. I do.

Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...

For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.

You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.

▲

yjftsjthsd-h 2 days ago | parent [-]

> You either build a debug image, so you just have it,

It is my understanding that that only gives root to adb, not apps, so no.

> or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.

If we're at the point of patching source trees, then no, we've left the realm of "very easy" behind. Installing Magisk is easy. Building Android from source, let alone patching it, is not.

> It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.

I really disagree. Knowing when to click the allow button or not is a separate skill from building/patching a ROM from source.

> Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...

I'd love to, but you'll have to mention what they might be. Both of those links treat root as nearly synonymous with compromise but never bother to explain how that compromise would occur, just 1. root 2. ??? 3. malware. That's fear-mongering, not a threat model.

> I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.

Or, we could avoid Appeal to Authority and talk threat models. The only one I've seen yet in this thread is people claiming that malware can fake out permission dialogs and that this is a problem for root permissions but somehow leaves the rest of Android's permission model in a usable state, which is... an interesting claim.

> Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.

Many people making vague claims might technically be a "consensus" but it's not actually meaningful. If you've got an actual threat model, let's hear it, otherwise there's not much point to this.

▲

gradeless 20 hours ago | parent | next [-]

Theres been a consistent pattern of both low quality and advanced malware looking for and targeting the weakness introduced by rooting a device.

Here is a recent report of widespread advanced malware looking to see if a device is rooted - https://www.lookout.com/threat-intelligence/article/badbazaa...

Here is a report of malware using root - https://zimperium.com/blog/new-advanced-android-malware-posi...

Root does not only provide privilege escalation, it also provides attractive options for exploit persistence on a device, something which is difficult to achieve on modern Android and iOS.

	▲	yjftsjthsd-h 14 hours ago \| parent [-]
		> Here is a recent report of widespread advanced malware looking to see if a device is rooted Okay? I do actually think that should be blocked (good root is invisible), but I'm not seeing a problem. > Here is a report of malware using root To quote the article: > In addition to collecting the messages using the Accessibility Services, if root access is available, the spyware steals the WhatsApp database files by copying them from WhatsApp’s private storage. Note that it already uses a11y features to do the same thing regardless, but also this is another case of conveniently skipping all the important details. Seriously - "if root access is available, the spyware steals" - how did it get root access? If the "vulnerability" is that the malware asks the user for root access and the user gives it, that is not a vulnerability. A system where malware needs permission to do bad things is perfectly fine.

▲

Scrubbed4426 a day ago | parent | prev [-]

Root does not leave the Android permission model in a usable state at all, it completely undermines it.

You are moving from a small handful of processes that get root access and are heavily constrained by selinux policies and are nowhere near userspace to putting root access behind a weak UI prompt. That is the ability to modify the system at runtime. If the system can be modified and the bar to that modification is trivially bypass-able, privilege escalation becomes monumentally easier for an attacker. Because the system can be modified *it cannot be trusted*.