For cases where the attribution soruce doesn't need to be
registered as trusted we are now using a shares static
token since the only purpose of the token in these cases
is for watching the source process dying as opposed to that
and security for registered cases.
bug: 192415943
Test: CtsPermissionTestCases
CtsPermission2TestCases
CtsPermission3TestCases
CtsPermission4TestCases
CtsPermission5TestCases
Change-Id: I93fde9ca1cacada7929761533dcae11b2736ce1e
Add and populate a "trusted" attribution flag, that verifies the
attribution sources used to create it were trusted.
Fixes: 192270935
Test: atest RuntimePermissionsAppOpTrackingTest
Change-Id: Ifd8f825151bec55aa795da7bee0a3069509f5abe
Add a historical flag to signify that attribution chains should be
assembled. Assemble the chains, filter out middle nodes, and attach the
last visible node to the start as a proxy info
Bug: 158792096
Test: manual
Change-Id: I8fbd8f438c62b28fd90039440e86224c624dea79
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: (added tests for speech reco)
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Since, we are opening PermissionControllerService to instant apps for
the permission group mapping API, I'm reviewing the permission checks
and this is the only missing one. However, this API is just a trigger
to update our state so calling it some more times shouldn't pose a
security risk, so this fix is just a nice-to-have.
Bug: 189836392
Test: presubmit
Change-Id: I6e9159ce090acaad2ecf522bd04c613169e03252
setRuntimePermissionGrantStateByDeviceAdminFromParams().
This is nice to have, but not necessarily a security fix because we are
already always enforcing ADJUST_RUNTIME_PERMISSIONS_POLICY.
Bug: 158735247
Test: presubmit
Change-Id: I629969e04e1d5e7e3ef47c8833780f19d83b9e0b
The API is moved from PermissionControllerManager (only a System API)
to PackageManager to expose it as public API.
Bug: 182094776
Test: atest GetPermissionGroupInfoTest
Change-Id: I175afb2e37bf2651b91765029645f7940f58f39c
Revert "Prepare AttributionSource to expose to native - native"
Revert submission 14225527-bug-158792096-04/16/21-1
Reason for revert: b/186467053
Reverted Changes:
I16740cc2d:Prepare AttributionSource to expose to native - na...
I4e050e78b:Prepare AttributionSource to expose to native
Change-Id: I83e4091231241c2211edf5745735f4ee993c6680
Separate the internal state of AttributionSource from the
class to make it a simple AIDL we can translate automatically
to native - keeping Java and native parts in sync. This
would allow writing a thin native lib for checking attribution
source permissions which would be used to teach camera and
audio about attributions.
Deinfe an AIDL interface for passing around an attribution
source and opr performing permission checker oprations allowing
native and Java permission checks on attribution chains to be
handled. The Java side permission checker functions are in a dedicated
permisison checker service on top of which sits the PermissionChecker.
We expose similar PermissionChecker native APIs sitting on top
of the same remote interface. The nice thing is that we have
native and Java permisison checkers in sync sharing remoting
code and being close in shape.
For now the PermissionChecker in Java is divorced from the
PermissionManager but in T we will consider how to unify them,
either by an extension object on the PermmissionManager or
APIs on the PermissionManager, or another approach, and then
migrate clients off the PermissionChecker APIs.
bug: 158792096
Test: atest CtsPermission5TestCases
Change-Id: I4e050e78b2361cbf524cc213802e0fef5b487f67
The TelephonyPermissions phone number access check can require several
interactions with the system_server to obtain the targetSdkVersion
and check the required permissions / appops for the requesting
package. This commit refactors all of these checks into the
LegacyPermissionManager (similar to what was previously done for the
device identifier access checks), requiring only a single request
to the system_server to check all non-subscriber access requirements.
Fixes: 159662444
Test: atest TelephonyPermissionsTest
Test: atest LegacyPermissionManagerServiceTest
Test: atest SmsManagerTest
Test: atest PhoneNumberTest
Test: atest SubscriptionControllerTest
Test: atest TelephonyManagerTest
Change-Id: I6c5cdbeecc2c4a2e200dcc33eedcb9213376f1ad
Create a GET_RUNTIME_PERMISSION_GROUP_MAPPING permission to gate the
permission group methods behind, and changes the methods to have
callbacks.
Test: atest GetPermissionGroupInfoTest
Fixes: 185177089
Change-Id: Ifd2ebc74f16e51b62068bdc6c8748f69bc63e923
If an app op becomes "paused" (microphone muted or disabled by toggle),
remove the indicator immediately as opposed to holding for 5s.
Also, pass the value that we are using for mic muted to
PermissionManager, so they are in sync.
Test: atest SystemUITests
Test: manual
Fixes: 184891081
Change-Id: I4d46fc6e1cefa45c0d718cc01f40c8f060dafee7
Converts both the AppOpsControllerImpl and the PermissionUsageHelper to
use the same static method when filtering which packages to show. The
only packages which are filtered are 6 device intelligence roles, and
the system package. These values are updated at most every 15 seconds
Fixes: 184141707
Test: manual
Change-Id: I9dc44197a2ff3df7783b37f450ada4ef2fb1ca6f
Address API review for changes related to admin-granted permissions:
* Change the provisioning extra to indicate it only affects
sensors-related permissions.
* Add an IntDef for the AdminPermissionControlParams grant state.
Bug: 184204476
Bug: 184204334
Test: atest ManagedProvisioningTests
Change-Id: I75c8b6de1e897e02916b17f0ae3a521f8384c242
Some proxy usages, in future, may not have matching attribution tags.
Match on package name and uid instead.
Bug: 183402046
Test: Manual
Change-Id: If122f13fb1d20bfe0bad415235f2143d41339650
Propagate renounced permissions from context params
to the context attribution source. Throw if one
tries to request at runtime a renounced permission.
Also make the AttributionSource take null for the
setters to ease usage, otherwise folks should always
check for null before calling a builder method.
Additionally, we allow apps that have UPDATE_APP_OPS_STATS
to register arbitrary trusted AttributionSource for
testing. Note that this permission allows abritrary app
op operations, thus we are not relaxing the security
model.
bug: 158792096
Test: atest CtsPermission5TestCases
Change-Id: I4330684bb8695fb998cf31e9363b94ad981ba2cc
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
Also sets lastAccessTime = now for running ops
Test: atest PermissionIndicatorAppOpUsageTest
Bug: 172868375
Change-Id: I2a616f624640e0f219e33d6fa8ebf55559e24e1a
Ensure that usages with the system package are not filtered entirely.
Instead, they should not be shown on their own, and the "system" label
should not be included in proxy label chains
Bug: 172868375
Test: manual
Change-Id: If9812ce915de0ca1ac47d93d96f199a8bb768bce
Location indicator has its own flag, so it is being removed from the hub
teamfood. Also, showing all system usages (except the system app) for
the hub teamfood.
Bug: 172868375
Test: atest PrivacyDialogControllerTest, PrivacyItemControllerFlagsTest
Change-Id: Iad5b141f600a0bf830d5b2ef5169ed90533914cb
Restrict the admin of a fully-managed device or managed profile from
granting sensors-related permissions.
The admin of a managed profile cannot control permission grants for
sensors-related permissions at all.
The admin of a fully-managed device can opt-out of having said control
by providing a provisioning extra.
This change passes the boolean flag in ActiveAdmin indicating whether
the admin has control over sensor permission grants into the permission
controller.
Manual testing:
* Install TestDPC
* Create a work profile using TestDPC.
* Get the BasicLocation app by checking out
https://github.com/android/location-samples and building it from there.
* Install the app onto the device but do not start it.
* In TestDPC, Find "Manage app permissions", choose "Basic Location Sample"
from the drop-down menu.
* Toggle each of the "ACCESS_COARSE_LOCATION" and
"ACCESS_BACKGROUND_LOCATION" to "Allow".
* Observe that no notification appears.
* Start the BasicLocation app and observe the runtime permission prompt
shows up.
Bug: 158735247
Test: Manual (more to be added).
Test: cts (see topic)
Change-Id: I12d9f7e24ad4bc09651a5e5f60b864298506c2c4
Add the wifi call special case, where if a call is ongoing while a
carrier privileged app is using microphone, the phone call usage is
removed. Ensure the phone mic op is listened for, add code to find the
predictor app, and show it, if the user is in a teamfood. Filter the
system app out, since the system app can be a location provider
Fixes: 178701757
Test: Manual
Change-Id: Ic1bf7f28c99bc0f596492332f7b4656c3bd7d25e
