[Feature Request] Per-App Network Isolation & Routing Control

Layamir

GrapheneOS already lets us revoke the INTERNET permission per app, which is great. But there’s room to go further with granular, per-app network rules, especially when using VPNs, Tor, or local services.
I would like to:

Force an app to only use VPN, no fallback if the VPN disconnects (kill switch)

Allow apps to access only specific IPs or domains

Block access to local network (LAN) while on Wi-Fi

Route specific apps through different VPNs or socks proxies.

It gives users verifiable control over what each app can talk to reducing attack surface and stopping leaks even from compromised apps.
Advanced users already try to cobble this together with external tools, root, or VPN profiles but it should be native, clean, and secure.

ryrona

Layamir It gives users verifiable control over what each app can talk to reducing attack surface and stopping leaks even from compromised apps.

Unfortunately, apps within the same profile can communicate with each over using IPC, and often do, so adding per app network routing settings like this would not give any meaningful protection at all even for non-compromised apps. We would need App Communication Scopes feature first. Until then, putting apps in separate user profiles is the only meaningfully secure way.

ignoramous

rdns dev here

ryrona each over using IPC

Different things. IPC over Binder or other forms (like over Unix Domain Sockets, pipes, files etc) need protection too, but they are distinct from IPC (RPC) over "network" (sockets). And so, will need different kinds of implementation. For network specifically, what OP seems to be asking for is a "Windows Defender" like suite of tools, to be bundled in Graphene.

Layamir VPN profiles but it should be native, clean, and secure.

What is meant by "native" & "secure"? The current way to achieve network isolation (via "VPN profiles") is already native in the sense the routing tables are all setup so installed apps couldn't bypass the VPN ("Block connections without VPN" aka "VPN Lockdown" is enabled by default on Graphene) and if the installed app did bypass, the traffic would simply be blackholed by the OS natively.

Though, with eBPF and raw access to nftables, the OS developers can make any such such firewall more performant and potentially also prevent "privileged apps" (like System apps) from bypassing "Lockdown VPNs" (but they can also extend those protections to "VPN profiles").

That said, from what I can tell, AOSP (and Graphene?) want to move (confidential compute / data, especially) as much as they can outside the Linux Kernel (ex: pKVM, TEE, SE etc) and grant as little permission & privilege possible to admin services/apps (ex: Binderized HAL, strong compartmentalization of services started during init, rootless su, etc), as Linux's monolith structure has been a source of many a critical security issue for AOSP (the nicely sandboxed userspace is totally reliant on the security of the Kernel & its subsystems).

Layamir

You're totally right that apps in the same profile can talk to each other via IPC, and without something like App Communication Scopes, we can't achieve full isolation between them. So yeah... separate user profiles are the only robust way to enforce strong boundaries right now.

That said, I still think granular per-app network controls have real value, even within a single profile. For example:

A per-app VPN kill switch can stop data leaks if the VPN disconnects, without affecting the whole profile.

Blocking access to specific IPs/domains or the local network can limit telemetry, fingerprinting, and attack surface, especially for apps that shouldn't touch LAN devices.

Routing different apps through different VPNs/SOCKS proxies can compartmentalize risk or bypass regional blocks, helpful for advanced users.

Even a compromised app can't just exfiltrate data if it’s locked to a certain proxy or domain set.
I totally agree that these controls won't stop IPC-based leaks or intentional collusion. But in practice, they still raise the bar significantly, especially in a defensivs setup and would nicely complement profile isolation when full separation isn’t practical.

Would love to see both App Communication Scopes and per-app network policies make it into GrapheneOS eventually.

b1k3rdude

I have a handful of app's that I would like the ability to restrict them to Wifi, and also LocalSubnet. As in its can talk to other devices on my LAN but have no internet connectivity.