Any system where you don't have root access in insecure by it's very definition. Android and ios are hilarious.
...unless you care to elaborate on why you disagree with this statement in substance and/or on point?
In the sentence "See, I can do silly categorical statements too," the adjectives "silly" and "categorical" both modify the noun "statements" and are not themselves related to one another. That's why OP used both of them. If the two words were synonymous, only one would be required.
It's fun nitpicking nitpicks.
sure is.
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...
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.
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.
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.
https://github.com/chenxiaolong/avbroot
Works great with CalyxOS and GrapheneOS.
There will always be a subset of users who prioritize functionality over security. This includes anyone who would root an Android device (and anyone who would use a desktop computer running most distributions of Linux, macOS, or Windows).
I'll be glad to reconsider using root on Android if all of the functions of App Manager's "block trackers" feature[1] and Basic Call Recorder[2] were available on Android without root.
[1] App Manager: https://github.com/MuntashirAkon/AppManager
[2] BCR (Basic Call Recorder): https://github.com/chenxiaolong/BCR
If you want root access, build and sign userdebug builds with ro.adb.secure=1, which is officially supported by GrapheneOS and only exposes root access via ADB which you should only use from the computer where you're building the OS.
It would be possible to add some kind of key combination at boot to disable loading user installed applications, etc. and instead making a terminal with root access available. Not clear how that's really useful though. Instead, what these projects are doing is giving out root access to a massive portion of the OS in order to be able to give out full root access to apps. This is used as a shortcut to implement features in a way that massively reduces security even if you never use it. Implementing those features properly integrated into the OS following the principle of least privilege is the proper approach. Most of the features people believe they need this hack to achieve are doable without it, such as filtering traffic with your own firewall rules while also using a VPN which is a standard Android feature available to apps.
https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#u...
Your definition is meaningless and not useful for reasoning or communication.
The simple problem has always been that when you're selling someone a $1000 piece of hardware that's supposed to "just work" how much do you let their ignorance fuck it all up.
Now granted that's not an argument for locking away access from those who choose to accept the responsibility, as has always been the case, but the idea that there was any other outcome was absurd.
Yes it'd be nice if everyone had some tech savvy common sense, but even now when we have generations growing up with it, actual understanding is far and few between when looking at the general population. People don't care, and don't want to, and it can make things risky.
The thing is, it's not that I particularly care about people, but it's made Android/iOS incredibly irritating to use, I avoid it as much as I can. It's not just that it wants to protect me from myself, as much as it doesn't let me do what I want to do, it feels like computing with a straightjacket on. Build a fort knox of sandboxes and SELinux, that's fantastic, as long as you give me the keys and blueprints, and for christ sake, stop pretending that my phone isn't a computer.