Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc.
Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.
Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].
It's app accessible root with a massive portion of the OS trusted with giving out access to it that's a huge problem and massively rolls back OS security against compromise. It also means an accessibility service can trivially escalate to root with no way to revoke it beyond reinstalling the OS or doing a wipe from recovery. You also lose the main security properties of verified boot, which is based around avoiding trust in persistent state. Raising the bar for physical attacks is a secondary purpose of verified boot, not the main one.
GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this. It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps. This is why we have our Network toggle in the first place, which does a lot more than blocking direct socket access both to block indirect access and preserve compatibility by pretending the network is down for the most important APIs.
These DNS leak issues which were reported to us earlier may be an app bug which can be worked around by the app. The OS could be changed to prevent this happening but that doesn't imply that it's an OS bug. More investigation is required to determine the cause and solution. We're also aware of a local network multicast leak that's not covered in Mullvad's post, which is very likely to be an Android OS bug but we aren't certain about that yet either. It's worth noting that neither the DNS leak issues or local network multicast leak issue impact the built-in VPN support. They're only happening with VPN apps. It's likely that some of this is caused by bugs in the Android VPN service app support (particularly the multicast packet leaks) but the DNS leaks are quite possibly an app flaw. Mullvad's post acknowledges they found a way to address one of the forms of leaks with changes to their app, which may be possible for the rest since there aren't leaks when the VPN is down but rather when it's in the process of reconnecting. It looks a lot like a race condition where the VPN is being activated before everything is in place, which could be a bug in the OS but could also be a bug in the app where it's doing something in a different order than what's intended.
> GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this.
Interesting, didn't know that. Maybe I should file an issue with the official WireGuard app asking them to support this. It would be nice if "multiple VPNs" was provided as an OS feature.
> It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps.
This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.
> Interesting, didn't know that. Maybe I should file an issue with the official WireGuard app asking them to support this. It would be nice if "multiple VPNs" was provided as an OS feature.
Apps have to implement it unless you mean supporting multi-hop WireGuard VPNs within the OS. Apps can support multi-hop and apps can also support doing filtering, etc. in addition to supporting an actual VPN. It's not exclusive unless the apps make it exclusive. Apps can also decide they want to support forwarding traffic through another app but they should really do that in a way that's secure instead of how some apps are currently offering this...
> This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.
Sure, but output filtering doesn't really work well in general. For example, if you allow resolving any DNS names then you allow 2 way communication with anyone through your DNS resolver. The requests only go to your DNS resolver, but they can be for <data>.<random>.example.com where the name servers for example.com are set up to receive that data and the random value avoids it being served from the resolver's cache. The value of the DNS result can return data in the other direction. It's easier with a TXT record but can simply be an A/AAAA record too. DNS is commonly used to mask traffic by malware. It's not an obscure approach but rather very normal. Similarly, many services can be used as some form of proxy at least to communicate with arbitrary people.
The main purpose of a firewall is when you're actually hosting services and need to filter inbound connections for DDoS mitigation, etc. by limiting the number of connections per IP or IP block, rate limiting, etc. It also acts as a way to prevent listening on ports you didn't intend to be listening on due to default-enabled services or services which listen on all interfaces by default, etc. On platforms where loopback is commonly used for communication, it's also a way to do access control based on uid, gid, SELinux context, etc. None of those 3 things applies much to Android. It's very rare for apps to use loopback for communication, although some do it. Hopefully they already do their own authentication... GrapheneOS does plan to use network namespaces to provide the option of per-profile or per-app loopback interfaces, although we could also just start with a toggle for access to it.
Worth noting Android uses eBPF for controlling per-app access to the network for our Network toggle, not netfilter (iptables/nftables). They've gradually moved more and more to eBPF and away from netfilter since they have the resources to develop things that way.
Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.
Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].
Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996
[1] https://discuss.grapheneos.org/d/4113/6
[2] https://grapheneos.org/articles/attestation-compatibility-gu...