This is desirable to end users, but my understanding is that making your os rootable will make applications like bank apps blacklist your os, and make it more or less unusable for a normal user.

iOS and Android are a security nightmare. Downloading a random-ass executable to pay for parking is asking for trouble. Relying on millions of lines of proprietary Google code that you-don't-know-what-it-does is asking for trouble.

This code could have, and almost certainly does have, spyware, keyloggers, and various other forms of malware. You're simply trusting that it doesn't, because it's unverifiable.

And this doesn't even TOUCH on all the vulnerabilities associated with cellular networks, the baseband, SS7, etc. Good luck auditing that code.

At least on a server I can have some baseline guarantees about what software I'm running and what it's doing. Whereas on a phone, your location could constantly be triangulated, your phone identity spoofed, your cellular traffic sniffed, and on and on and you'd never know.

I mean, just this week we saw a post on here about ICE using fake cell towers to identify protestors. That shit is truly trivial to do, and people have been doing it for almost two decades. You wanna talk CVE? Start with that.

https://grapheneos.org/build#setting-up-the-os-build-environ...

One of the things I like the most about GOS is the web installer, and how easy it is to use. If I need a custom build, to run my own server, and sacrifice performance for it, it doesn't seem worth it. It would also be good to know what a debug build entails, how exactly it is "less secure", and so on. Since this is unlikely to be documented by the GOS team, a 3rd party guide would still be helpful.

Using software engineering terms, think of the official GOS as production release, and the debug version as test release. You deploy it by actiually building it, like building a linux kernel. This takes lots of reaources (RAM + storage). But also is quite flexible because you can compile and build it whenver there is a new update. And you can sign the build yourself. The reason why they say it's insecure is the same why your server sysadmin does not give you the root password. You can do some serious damage if you have no idea what you're doing. On Android, root allow you to peek on other processes and apps, so if you grant root to a malicious app, high risk of data leakage. That's it though. Been rooting and building roms since early android days, no issues for me as I tend to use open source tools most of the time.

As for the possible way, you answered yourself already (custom keys and images) :)

How so?

On Linux, I can add an account to the sudoers list, and have the flexibility to configure the level of security appropriate for my use case. I have yet to experience any security issues (that I'm aware of). Why isn't this possible on my mobile device as well?

This absolute stance is not right. Security is not binary, but a spectrum. I should be allowed to have full control over my device without this being a security risk.

I don't think having authorized temporary root is inherently insecure, but on the other hand making sure it is secure could be a huge time sink.

Now, the original request here, modifying user app (I'd assume it's not system app) data, is reasonable. Designing a properly authenticated way to allow doing so would be an interesting challenge.

Especially since Seedvault is.... ekhm, lacking.

Qubes OS solved this problem. I don't see any flaws in their security model relying on vurtualization.

Root can access absolutely everything.

Malware capable of getting root can access / exfiltrate anything, use your network, flash your firmware, can persist permanently, can use you as a vector.

Shellshock, log4j, Heartbleed. Hundreds of the big profile vulnerabilities that can be exploited on the system in an attempt to obtain root. And then you're cooked.

You really think a malware with the root access can't do much?

Why do you think selinux (and similar) even exist?

This isn't absolute stance. This is just stating that having a root access on the proruction/daily system is the opposite of security.

Also, the user having root access doesn't mean that every process they run has root rights. For rooted phones there's apps to control what it's used for. Anything else just runs with the limited rights as before.

Of course those 'sudo' apps would be an attack vector but a pretty niche one.

The idea of locking the system down completely and preventing anyone from accessing it is technically more secure, but it creates many practical issues for tech-savvy people who want full control over their devices, which is the vast majority of the GrapheneOS user base.

If SELinux can mitigate the risks, then sure, let's use that. I don't really care what the technical solution is to this problem.

I'm just saying that:

a) As a user of an OS I want to be allowed full control over my device and not have babyproofed functionality because "it's for my own good". That is the realm of walled garden OSs from most major corporations which I deliberately avoid by using GOS in the first place.

b) My personal threat model doesn't involve using a bunch of untrusted applications, and I'm fine with trading some security for convenience. If the risks from choosing convenience can't be mitigated, then my OS should be flexible enough to allow me to make that choice. Other OSs can do this, so why can't GOS? I'm inclined to believe that there's no technical reason for it, but it's something that maintainers simply don't want to support. Which is fine, it's their project and their prerogative, but then let's not pretend that this is a discussion about security.

That is usually how it's done, yes.