5 ms·

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 agains

by strcat 2y ago

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.

NotPractical 2y ago
> 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.
- strcat 2y ago
  > 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.

by strcat 2y ago

NotPractical 2y ago

> 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.

strcat 2y ago
> 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.