We've seen evidence of IBluetoothProfileServiceConnection and
IBluetoothStateChangeCallback references being leaked, so attempt to
unregister them when an object is finalized without closing.
Bug: 189091551
Test: manual
Change-Id: I23792d48d94578acd7fc7a5164a95171801ee721
Since developers can use a BluetoothDevice object can make remote
calls, it needs to have an accurate AttributionSource. Previous CLs
had updated many places where these BluetoothDevice instances were
passed across Binder interfaces, but this change updates several
remaining locations which had been missed.
Introduces new "Attributable" marker interface to offer consistent
tooling when applying AttributionSource updates.
Bug: 187097694
Test: atest BluetoothInstrumentationTests
Change-Id: Icad3b9726591f0fbad58a493cefa5a0af7648280
This broadcast doesn't contain any sensitive BluetoothDevice extras;
it only contains a single boolean indicating tethering state, so
relax it to no longer require the BLUETOOTH_CONNECT permission.
Bug: 188706031
Test: atest BluetoothInstrumentationTests
Change-Id: I2ff5c501844186a5813b2347246bbc83c190222d
accepts null input and returns an int (with error codes).
Update CompanionDeviceManager#canPairWithoutPrompt to take a
UserHandle instead of an int. Adds BluetoothStatusCodes class for all
new Bluetooth error / success codes. Moved OOB and hci disconnect
constants to the new BluetoothStatusCodes class.
Tag: #feature
Bug: 184714087
Test: atest BluetoothDeviceTest#test_setAlias_getAlias
Change-Id: Ife03506f2cf68800f5824cb5fa94fec8aa34a39c
There are some Parcelables which offer to perform Binder calls, and
when these are delivered via Intent extras they fallback to
ActivityThread.currentAttributionSource(), instead of being tagged
based on the relevant app component.
This change begins using Intent.prepareToEnterProcess() as a hook to
fix-up AttributionSource when those extras finally land in the
destination process. It uses the relevant AttributionSource based
on the Activity or Service the Intent is delivered to, which
developers have control over via AppComponentFactory.
In the case of <receiver> manifest elements, this change applies the
first android:attributionTags value to the Context used for that
BroadcastReceiver.
Bug: 187097694
Test: atest AttributionTest
Change-Id: I8f5197db7e8d7277d34f0ef2bb90bfdf1871186a
device is bonding, we either broadcast cached UUIDs or wait for SDP to
be performed after the device is bonded.
Tag: #feature
Bug: 187157597
Test: Manual
Change-Id: I1bd694195c4e974b7cd72f81848a6343b45c98fd
When users revoke a runtime permission, they expect all interactions
to be blocked, including those protected by the BLUETOOTH_PRIVILEGED
permission.
This change finishes applying that policy to any remaining Bluetooth
APIs which didn't already implement it. To keep the implementation
straightforward, this change does "data delivery" checks when
registering for callbacks; the ideal behavior would be to wait
until data is actually delivered through the callbacks, but
RemoteCallbackList doesn't have support for AttributionSource yet.
Bug: 186405452
Test: atest BluetoothInstrumentationTests
Change-Id: Idd7be143eb8baff020a0718065293baae708041b
As part of the new "Nearby devices" permission work, the
registerStateChangeCallback() API has been relaxed to no longer
require permissions. However, we've discovered that some apps were
depending on that SecurityException being thrown, so this change
restores throwing behavior for those legacy apps.
Bug: 186176507
Test: atest BluetoothInstrumentationTests
Change-Id: Ife536dee246b300ffb3dd78aef0b059a230f3835
Wires up AttributionSource across the remaining long-tail of
Bluetooth AIDL interfaces, ensuring that developers can accurately
make calls chained back to a specific Context.
Moves "for data delivery" permission checks to happen in a single
location on each interface to ensure they're performed consistently
with the new AttributionSource arguments. Note that "for data
delivery" isn't the best name; it's designed to represent that the
requested action was performed and should result in the relevant
appop being noted for the caller.
This change has the positive side effect of ensuring that all
interfaces are consistently enforcing the BLUETOOTH_CONNECT
permission, even in the case where BLUETOOTH_PRIVILEGED is also
required; this is what ensures that revoking the "Nearby devices"
permission takes effect for all callers.
Additionally, standardizing on enforcing permissions closer to the
AIDL entry point reduces the need for @RequiresPermission annotations
to be carried around inside the Bluetooth stack.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I8023dda654e325b8bfa2f0cdb994ad63a2b429d4
To prepare for future work which will plumb AttributionSource values
through all remaining AIDLs, we need profiles to interact directly
with the specific BluetoothAdapter they were created from. This is
how we'll ensure that the relevant AttributionSource can be chained
down from the original Context they're obtained from.
This change also marks getDefaultAdapter() as deprecated to clearly
communicate that BluetoothManager.getAdapter() is the best-practice
path to obtaining a correctly scoped BluetoothAdapter instance.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I1e15170d7679019bbb6e396279d6e633e3dad4d6
This adds attribution source to BT method calls. This is now
required to allow the app ops for the new BT permissions
(BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE, and BLUETOOTH_SCAN)
to be noted.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I81598553b762e491d6364064a2e1ef41dec89bf9
Previous CLs had started passing AttributionSource values across
Binder calls inside BluetoothDevice instances, but this can cause
confuse the permission check logic in the future; we should instead
always aim to use the AttributionSource closest to the app making
the call, instead of parceling it.
This change also improves logging to highlight when we're quietly
treating a permission as denied, and when a UID is mismatched.
Bug: 186106084
Test: atest BluetoothInstrumentationTests
Change-Id: I5d3fdb3c573cb9e77474952d8680caa4c4c464eb
Recent work has been using Error Prone rules and annotations to
reflect the current state of permission enforcement across the
Bluetooth stack, and we're now in a position were we can add new
permission enforcement that had been missing.
We've currently standardized on saying that APIs that return device
or Bluetooth state information (without sharing details about any
particular remote Bluetooth device) do not need to be permission
protected.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I53ac7a4fe1dea57316048c3cac4fa237b6ba3d38
This adds attribution source to AdapterService bluetooth method
calls. This is now required to allow the app ops for the new
bluetooth permissions (BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE,
and BLUETOOTH_SCAN) to be noted.
Bug: 183626112
Test: atest AdapterServiceTest
Test: atest CtsPermissionTestCases:android.permission.cts.NearbyDevicesPermissionTest
Change-Id: I8d1fe41ca9945a3baab584f248a17b3a1eb255f7
Recent work has been using Error Prone rules and annotations to
reflect the current state of permission enforcement across the
Bluetooth stack, and we're now in a position were we can add new
permission enforcement that had been missing.
We've currently standardized on saying that APIs that return device
or Bluetooth state information (without sharing details about any
particular remote Bluetooth device) do not need to be permission
protected.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I37a9e03ecdca6f7a6eb9d7f094e2f95a97036612
This change adds a "BluetoothPermissionChecker" that ensures that
all Bluetooth permission annotations are consistent. In addition, it
verifies that all Bluetooth public APIs have been audited to be
permission protected where relevant.
We've currently standardized on saying that APIs that return device
or Bluetooth state information (without sharing details about any
particular remote Bluetooth device) do not need to be permission
protected.
This change is only annotations and has no behavior changes.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: Ie80b15b058359bf1e9a6ee881b89cb3e5b584ca1
Technically these APIs required both ADVERTISE and CONNECT, since
internally it would attempt getting the device name as part of
calculating packet lengths. These methods shouldn't require the
CONNECT permission, so we add a getNameLengthForAdvertise() method
internally to remove this dependency.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I245417bfc26d6d3a4f8be14077c7f1d271b5959e
Recent work has introduced a new "Nearby devices" runtime permission
which protects all existing Bluetooth APIs; we've done this by
defining a <split-permission> to convert the old BLUETOOTH and
BLUETOOTH_ADMIN permissions into one of three new permissions:
* BLUETOOTH_ADVERTISE: Required to be able to advertise to nearby
Bluetooth devices.
* BLUETOOTH_CONNECT: Allows applications to connect to paired
bluetooth devices.
* BLUETOOTH_SCAN: Required to be able to discover and pair
nearby Bluetooth devices.
At its core, this change begins updating the Bluetooth APIs to have
correct @RequiresPermission indicating which permission is actually
enforced internally. To ensure alignment across Binder, the newly
added "RequiresPermissionChecker" Error Prone checker was used to
discover any inconsistencies, ensuring correctness from server-side
enforcement up through to the public APIs.
In addition, since developers will continue building apps for both
modern and legacy platforms, this change introduces new auto-doc
annotations which will emit helpful consistent documentation
describing the behavior of older devices that are still using the
old permission model.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I02aa127e8e07f239561f4f2a3bbdfc6fccb82f7f
This passes the AttributionSource to AdapterService and GattService
methods that perform scanning or discovery.
Bug: 183203469
Test: atest GattServiceTest
Test: atest AdapterServiceTest
Test: atest CtsPermissionTestCases:android.permission.cts.NearbyDevicesPermissionTest
Change-Id: Id68558624fbae69eac3a8613b9536eb6e0df75bf
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
