Using policies provided by NetworkPolicyManagerService (fw/b), allow
or disallow an app to access a network based on network transport
type, e.g. Wi-Fi or Cellular.
Needs corresponding fw/b and netd changes.
All networks are treated as being restricted, and only UIDs whose
policy allows them on a transport are able to route outgoing traffic
over a network of that type. In addition, to prevent incoming traffic
to UIDs that are not allowed on the active network, and to handle UIDs
that have a policy which prevents them from accessing VPNs, UIDs that
are not allowed to access their active network are added to a denylist
that prevents them from accessing networks in general. Networks which
are truly restricted, however, such as for IMS, are left unchanged.
Also includes squashed changes:
Author: Tommy Webb <tommy@calyxinstitute.org>
Date: Thu Apr 27 15:51:18 2023 -0400
fixup! Set allowed UIDs for networks based on policies
Revert to prior network permission behavior here, and make necessary
changes in netd instead. This improves clarity and allows UIDs to
take advantage of default network rules which would otherwise
require system-level permission, prior to this change.
Related: Icd64aa530e8d202abb97d8325160a5d4c0b4c490
Change-Id: If5493deb96f88fe3ff5fc8a6a0c6d6d9bc77eff4
Author: Tommy Webb <tommy@calyxinstitute.org>
Date: Wed Mar 22 09:05:18 2023 -0400
Expose new isUidCurrentlyDisallowedByPolicy
Allows determining if a UID is blocked based on its transports.
Change-Id: I2729b61c349ec2812a74d7d1c04b90a58b0f5b88
Author: Tommy Webb <tommy@calyxinstitute.org>
Date: Wed Sep 20 15:19:45 2023 -0400
Use framework listener for allowed transports
When allowed transports change, instead of exposing an API from
Connectivity that the framework calls, add a new method to the
framework's NetworkPolicyCallback that we override.
This change benefits the prebuilt mainline module, preventing
the need to fight with the platform to add new module APIs.
Requires fw/b change of the same Change-Id.
Change-Id: Ie476f23684b00397197184e965201d6823b28de2
Author: Tommy Webb <tommy@calyxinstitute.org>
Date: Wed Sep 20 16:10:36 2023 -0400
Notify the framework about denylist changes
When the denylist changes, instead of exposing an API from
Connectivity that the framework calls, add a new method to the
framework's NetworkPolicyManager that we call to inform it of
this directly.
This change benefits the prebuilt mainline module, preventing
the need to fight with the platform to add new module APIs.
Requires fw/b change of the same Change-Id.
Change-Id: I3c3593f110753a3ce02af3739f600190f22e9663
Author: Tommy Webb <tommy@calyxinstitute.org>
Date: Fri Dec 6 08:10:27 2024 -0500
fixup! Firewall: Transport-based toggle support (3/3)
Use a dedicated callback for allowed transports, in preparation for the
removal of NetworkPolicyCallback.
Change-Id: I9e00948bdc06e3a1beb14b5b9b9ab3eb15b9a528
Change-Id: I79342edbec92090cca20853ba50ea7fd48ec81c2
Tommy Webbauthored and Thomas Turnercommited 2025-08-25 10:44:30 +01:00
Previously, non VPNs would not be created when updateVpnUids()
is called inside handleRegisterNetworkAgent. Because the network
is not created, netd would refuse to set the UIDs with an error.
Now that networks are created immediately with the
QUEUE_NETWORK_AGENT_EVENTS_IN_SYSTEM_SERVER flag,
the network is created and netd does set the UID for any
network as if they were a VPN. This results in the UID having
the wrong default network, which in turns prevents it from
accessing Internet.
Test: new test in this patch
Bug: 408717088
Flag: EXEMPT bugfix
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:97e690169779f9790aa8d6026fca6bdc3d61e1b3)
Merged-In: If68ea7d60919c0c7e177480f6167196381e00f35
Change-Id: If68ea7d60919c0c7e177480f6167196381e00f35
Chalard Jeanauthored and Android Build Coastguard Workercommited 2025-04-15 16:36:05 -07:00
Currently, apps targeting V can see thread local network.
This change introduces a mechanism to make existing
apps unable to see non-thread local networks to ensure minimal
impact on existing devices and applications while adopting this
behavior. Apps targeting B+ Sdk and run on V+ devices can see
non-thread local networks.
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalAgentTests \
--update-device
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server --update-device
(on next/trunk_staging release config)
Bug: 349487600
Change-Id: I6aa43cebc20a9017c2d8a8a90ebb1d53040a27bb
...and if the feature is not killed.
For devices on V and below, this feature should be subject
to a rollout. That rollout should be done in mainline beta
if possible at all, meaning the flags can be defined later.
If beta isn't possible after all, a legacy rollout can happen
starting in M2025-06 too.
Test: manual
Change-Id: I941762bf759ce25b4bd1f908e971ceaf4f49f671
Now that the faulty test is fixed,
This reverts commit 0141d82c2d.
Test: ConnectivityCoverageTests CtsNetTestCases FrameworksTelephonyTests
Change-Id: Ic9fee5bb7efb8ca4c05d7c9e600236186d094080
Now that the faulty test is fixed,
This reverts commit 19dcc447c4.
Test: ConnectivityCoverageTests CtsNetTestCases FrameworksTelephonyTests
Change-Id: I30fa35cef1729e6ecd4140c52fabfa2da1a9bb4b
Now that the faulty test is fixed,
This reverts commit 09bc78fda7.
Test: ConnectivityCoverageTests CtsNetTestCases FrameworksTelephonyTests
Change-Id: If52cc211b7859c0add07c16f171a6ce342ccca97
(a) this function returns a constant
(b) this function is utterly misnamed/documented:
an ipv4 mapped address is (like any ipv6 address) 128 bits long
(c) there's not even a guarantee the address is v4 mapped
when it is called
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I35bd84d28feca080152fd0c3d8e7b22835698b38
Maciej Żenczykowskicommited 2025-03-19 22:03:50 -07:00
Revert submission 3548747
Reason for revert: Droidmonitor created revert due to b/404956859. Will be verified through ABTD for standard investigation.
Reverted changes: /q/submissionid:3548747
Change-Id: I0c0b2724666cf6dfddbe3633fd50454f003ed133
Revert submission 3548747
Reason for revert: Droidmonitor created revert due to b/404956859. Will be verified through ABTD for standard investigation.
Reverted changes: /q/submissionid:3548747
Change-Id: I44affb742ca066406e93fc75056b4d3d1298eadb
Revert submission 3548747
Reason for revert: Droidmonitor created revert due to b/404956859. Will be verified through ABTD for standard investigation.
Reverted changes: /q/submissionid:3548747
Change-Id: Ic4226f2f1a20965f80b554967568a4450e460da2
Satish Yallaauthored and Gerrit Code Reviewcommited 2025-03-19 20:18:37 -07:00
This relands aosp/2623893 now that the underlying timing
issues have been fixed. It also addresses the two outstanding
comments that had not been fixed. It conditions it on the
"queue in system server" feature.
Currently, various codepaths in ConnectivityService disconnect
networks using NetworkAgentInfo#disconnect. This posts a message
to the NetworkAgent to disconnect and also posts a message to
ConnectivityService to call disconnectAndDestroyNetwork, which
performs all cleanup in ConnectivityService. These two messages
race and the order is non-deterministic.
Instead, always disconnect using disconnectAndDestroyNetwork,
and have disconnectAndDestroyNetwork post the message to the
agent to disconnect.
This fixes a bug where if wifi uses unregisterAfterReplacement
twice in quick succession, when the third agent connects it
doesn't work because the interface is still being used by the
second network.
Bug: 286649301
Test: covered by existing tests
Change-Id: Ib1d77da39232c02060a7a7c016ffd3a969e2356d
Lorenzo Colittiauthored and Chalard Jeancommited 2025-03-19 21:03:23 +09:00
This CL provides convenience methods to iterate over all
networks.
- forEachNetworkAgentInfo takes a consumer and runs it on all
networks in mNetworkAgentInfos. The consumer is allowed to
remove any number of networks. This is needed because some
loops over mNetworkAgentInfos result in disconnecting networks,
which removes them from the set.
- anyNetworkAgentInfo takes a predicate and returns true iff it
returns true on any element in mNetworkAgentInfos. The
predicate is not allowed to modify the set in any way.
Bug: 288149251
Test: simple refactor, covered by existing unit tests
Change-Id: I5d8b38503895d33abc2d96daaa1c96372befce64
As ConnectivityService is ready to accept messages about a network
agent, it should process messages immediately and before messages
from other agents are processed.
This is because of minute ordering issues between the agent process,
ConnectivityService and the network stack. In particular, as the agent
is created, ConnectivityService requests the NetworkMonitor from the
network stack ; while this is happening, the process creating the
agent may have sent a bunch of other messages... including, but not
limited to, disconnects or creation of other agents.
The operative case is the case where a disconnect is in the queue.
agent1.register
→ CS creates the monitor for agent 1
agent1.unregisterAfterReplacement
→ CS enqueues in agent1 pending creation of the monitor
agent2.register
→ CS creates the monitor for agent 2
monitor for agent 1 is created
→ CS posts a message to complete agent 1 creation
monitor for agent 2 is created
→ CS posts a message to complete agent 2 creation
agent 1 creation completes
→ CS re-posts the unregisterAfterReplacement message
agent 2 creation completes
...and this is where things fail, because unregistering agent 1
isn't processed yet. If they use the same interface (which is
a common use case for unregisterAfterReplacement) then this
creation will fail.
To address this, this patch will process all agent1 messages
synchronously as the creation completes. It will solve the case
above, and it passes all tests for early network creation.
However, it is worth noting that this is not actually correct,
because it does not guarantee that all messages are processed
in order. Namely, two agents have separate queues and
therefore if they send interleaved messages while CS is
waiting for the NetworkMonitor to be created, the order of
these messages will be lost. e.g.
agent1.register
agent2.register
agent1.unregisterAfterReplacement
The case above SHOULD fail if the agents have the same
interface, but with this patch it will likely succeed because
the call to agent1.unregisterAfterReplacement will be received
while the two NetworkMonitor are being created, and then
be processed as agent1 finishes registration.
The correct change, therefore, would really enqueue all
messages when *any* agent (of the same process at least)
is being created. However, it is arguable whether it's worth
building that change over this one, and it is even arguable
whether the behavior of this here change might not be
better, insofar as two agent messages are generally
unrelated to each other except for unregistering.
Test: CtsNetTestCases ConnectivityCoverageTests
Change-Id: Idf75e4e96c67a456cf0979a79321603b46e8c99c
Now that the system server has a queue doing this job,
the queue on the network agent side can be removed.
Test: ConnectivityCoverageTests, CtsNetTestCases
Change-Id: Idf0435f447cfdd28d829a867d1085771837c6f9b
* changes:
Reapply "Add a queue system server-side for NetworkAgent"
Reapply "Unify registration and NM assignment in NAI"
Reapply "Return the registry in registerNetworkAgent."
Jean Chalardauthored and Gerrit Code Reviewcommited 2025-03-18 03:19:07 -07:00
Now that faulty Telephony tests have been disabled temporarily
to allow for this bugfix, this can be reverted.
This reverts commit a5ec9b4112.
Test: FrameworksTelephonyTests CtsNetTestCases
Change-Id: I71abf9d02bdd34a4de80157a3f42bdfee6f6617e
Now that faulty Telephony tests have been disabled temporarily
to allow for this bugfix, this can be reverted.
This reverts commit 30fcf820f9.
Test: FrameworksTelephonyTests CtsNetTestCases
Change-Id: I57f25f5e6481106255df0ab69558e351eb938f68
Now that faulty Telephony tests have been disabled temporarily
to allow for this bugfix, this can be reverted.
This reverts commit 653d5f1ef4.
Test: FrameworksTelephonyTests CtsNetTestCases
Change-Id: If6b1541981803dc84de57b48adb13d40c9997fa0
* changes:
Revert "Return the registry in registerNetworkAgent."
Revert "Unify registration and NM assignment in NAI"
Revert "Add a queue system server-side for NetworkAgent"
Pechetty Sravani (xWF)authored and Gerrit Code Reviewcommited 2025-03-17 02:23:26 -07:00
Revert submission 3535182
Reason for revert: <Droidmonitor created revert due to b/404070202.Will be verified through ABTD for standard investigation.>
Reverted changes: /q/submissionid:3535182
Change-Id: I2febd2ee7227d487d9cd69dcabd9c04f888fd2de
Revert submission 3535182
Reason for revert: <Droidmonitor created revert due to b/404070202.Will be verified through ABTD for standard investigation.>
Reverted changes: /q/submissionid:3535182
Change-Id: I65fdaaacb56c8ef227eaf1a0193efe8d332d6473
Revert submission 3535182
Reason for revert: <Droidmonitor created revert due to b/404070202.Will be verified through ABTD for standard investigation.>
Reverted changes: /q/submissionid:3535182
Change-Id: Id48ef1cf44911cb291bcd8db349934751297718b
Pechetty Sravani (xWF)authored and Gerrit Code Reviewcommited 2025-03-17 00:48:05 -07:00
The intent is to remove the queue on the NetworkAgent side.
This queue is triggered with the same conditions as the
existing one.
Test: ConnectivityCoverageTests, CtsNetTests
Change-Id: I4bc29b10e48e13cdf3c3a8a15a7c8d15954d2457
Registration is marked by the creation of the network monitor
for a given network agent. This patch makes this fact much
more ovbious.
Test: CtsNetTests ConnectivityCoverageTests
Change-Id: I94a56b2bce6f453322b1eb91d6a6f14b31e7a95f
This is a resubmit of
I0fd90716b9f5501bdcdc7ee5165321737a0076ae
which did not account for testing of this private method
in Telephony tests.
Also make the network agent registry two way to eliminate
reordering possibilities.
Test: ConnectivityCoverageTest, CtsNetTests
Change-Id: I9ca025b1369dcb1202f906d5cff79e3d935b40da
Adding mechanism to track interaface name to interface index, this map
would be used by BpfNetMaps for storing interface index.
Bug: 400681214
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.connectivity.InterfaceTrackerTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Change-Id: I2a65cac908d9c4d10714e3fe26be20322d4a1db3
This reverts commit 70ede3260c.
Reason for revert: Likely culprit for b/402365566 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: If72cc264c5e505348309c6c11dbbfd11adeaf31b
Chaitanya Cheemala (xWF)authored and Gerrit Code Reviewcommited 2025-03-11 06:05:49 -07:00
Also make the network agent registry two way to eliminate
reordering possibilities.
Test: ConnectivityCoverageTest, CtsNetTests
Change-Id: I0fd90716b9f5501bdcdc7ee5165321737a0076ae
This is needed by tethering local network feature, given that
the IpServer needs to setup forwarding after native network
creation and before signaling network availability.
Test: atest CtsNetTestCases:android.net.cts.NetworkAgentTest \
ConnectivityCoverageTests:android.net.EthernetTetheringTest \
ConnectivityCoverageTests:android.net.connectivity.com.android.server.ConnectivityServiceTest \
--update-device
Bug: 349487600
Change-Id: I2bc2ec355e01be661b587406bd127dff11665047
PendingIntent.send will throw CanceledException when the intent
can't be sent, because it was canceled or some other reason. In
some, but not all of these cases, it will still call onSendFinished
after the send is done. This means there is no way to be sure
to do something exactly once after the intent is sent.
Unfortunately, ConnectivityService must keep a wakelock until
sent is finished, and wakelocks must be released exactly once.
Too bad.
The simplest solution is to create a specialized listener object
that can manage the lifecycle of the wakelock. This allows
very localized code, easy review and checking, cheap thread
safety, and not creating multiple locks. It also avoids the
ConnectivityService class implementing OnFinished itself,
which is arguably not very readable considering how big
the class is.
Test: new test that crashes the system without the patch
Fixes: 390043283
Change-Id: Ice528eddaedb4d663098eb2bb0ae7183dafbc073
These optimizations are already launched to all public Pixel
devices and were in in 25Q2 beta releases as well. Enable them
by default on all supported releases. The appcompat risk is very
low (these changes are difficult even for an app to detect if
it's looking for them), the user benefits are substantial, and
there is a kill switch if any unforeseen issues do occur.
Bug: 327038794
Test: both codepaths are covered by existing tests
Change-Id: I42c7ceb71ef02d078bf4563744cb11afd412f267
Lorenzo Colitticommited 2025-02-26 04:24:58 +09:00
Addressing feedback from previous change "Adding stacked link addresses
to local_net_access map" and adding more test cases for impact of
stacked link properties on local network prefixes.
Bug: 369815823
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalNetworkProtectionTest
Change-Id: I4d32d86d3e083a1a14b845583fd80a7a4b18ae5f
Starts L2capNetworkProvider in ConnectivityService. Alternatively, this
could be moved to ConnectivityServiceInitializer instead in a follow up.
When L2capNetworkProvider is created, it starts a handler thread, so
makeL2capNetworkProvider must return null in tests as otherwise the
thread leaks.
Test: atest NetworkReservationTest
Change-Id: I35c14815b1a71f0739c1bf63ad466763d611434c
Iterating over stacked link address to ensure correct mapping for
interface to local network ip prefixes.
Bug: 369815823
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalNetworkProtectionTest
Change-Id: I3b2ed906caf43584ffb0e8041f9302c760099f7b
Whenever ip interface is updated, we are updating local network
addresses. These may include dns servers that are needed to be excluded from
restrictions.
Bug : 393354879
Test: Manually and atest
ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSBpfNetMapsTest
Change-Id: Id4ebb33ab7de84ac1c81d485e599779c460bacdc
Tommy Webb
authored and
Thomas Turner
commited 
Chalard Jean
authored and
Android Build Coastguard Worker
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Junyu Lai
commited 
ESWAR MAGATAPALLI (xWF)
authored and
Maciej Żenczykowski
commited 
Satish Yalla
commited 
Lorenzo Colitti
authored and
Pechetty Sravani (xWF)
authored and
Sarup Dalwani
commited 
Chaitanya Cheemala (xWF)
authored and
Motomu Utsumi
authored and
Jacque Li
authored and
Neha Raj
commited 
Patrick Rohr
commited