| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Bug: 258672042
Test: atest CtsPermission4TestCases
Change-Id: I1d484ed7c72d4ae73f4cbec47522a18ae9088f6e
(cherry picked from commit 297388e374f0a1e5b7f52961a81246c2fecb81e6)
Merged-In: I1d484ed7c72d4ae73f4cbec47522a18ae9088f6e
|
| |
|
|
|
|
| |
Test: Create sdk 22 and 30 test apps and use the MEDIASTORE intents
Bug: 192635623
Change-Id: I250a5e398e72919ec8217e87b76273082e781f63
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of managing across all users we can restrict globally and fast
fail if the restriction is set
Test: atest CtsSensorPrivacyTestCases
Bug: 191016260
Change-Id: Ida1a2d1734b7e3d40818485062bec0f96270bc4b
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently specially handle the HotwordDetectionService uid in
AppOpsPolicy. But CheckOpsDelegate doesn't currently include finishOp,
so that doesn't work for the hotword service. This change adds finishOp
to the interface and implements it in AppOpsPolicy to be consistent with
the other ops.
Bug: 190011174
Test: manual - no error in logs for finishOp
Test: manual - privacy indicator works as expected (with another wip
change)
Change-Id: I77907092a917362aacd0d5562e54abd6f3c3d47b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
Allow user restrictions to provide an excluded map of packages and tags
rather than just packages.
Bug: 187421886
Test: manual
Change-Id: I8f90ba6cdd288068664b352fdb540d0f11fe3dfc
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
bug: 185504196
Test: atest CtsAppOpsTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
Change-Id: I5869a3e9719830f59624519f2d54f0765119cf5f
|
| |
|
|
|
|
|
|
|
| |
Use the SyncNotedAppOp when collecting self/sync ops in AppOpsManager.
Also adds "mode" to SyncNotedAppOp
Fixes: 184111263
Test: Atest AppOpsServiceTest
Change-Id: Ia20c7054d06e241cbe017a641d728e11c7eccd06
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
- in situation when developer provides message when op is noted, do not
report it through stack trace collection infrastructure
- collect only statcktraces for OP_FLAG_SELF and OP_FLAG_TRUSTED_PROXIED to
match collection of appops counts
Test: atest android.app.appops.cts.RuntimeMessageCollectionTest
Fixes: 159433071
Change-Id: I1ab56a530832873a1f1f68aba5ab6eabc9e8a17a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the REVOKED_COMPAT flag may be updated when
PermissionPolicyService is setting app op mode, however it should not
do so because the app op mode is coming right from the permission
state it was seeing. Mutating permission state would lead to incorrect
permission state when PermissionPolicyService and PermissionController
are running concurrently, and by no longer mutating permission state
in PermissionPolicyService, the app op state will eventually arrive at
the correct state even when there's some concurrency.
Bug: 149267332
Bug: 136503238
Test: manual
Change-Id: I9b02bc3f42a20ba441d5af9fd1b8a9729d8d0480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an app op change is made while syncing app ops from permissions, we
know it's being set to our desired state and don't need to be notified
again. This cuts the performance cost to at least half of what it was,
and prevents potential looping.
Bug: 136503238
Bug: 147673896
Bug: 146039935
Bug: 148706747
Test: manual
Change-Id: I643472800c0dfbf96c202093a697f0a72eee0780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Background started foreground service shall not have
while-in-use permissions including location, camera and
microphone. Many exemptions have been applied including:
--FGS started by widget.
--FGS started by notification.
--FGS started by IME or other visible app.
--FGS started by ROOT_UID, SYSTEM_UID, NFC_UID.
2. Add a phenotype key KEY_DEFAULT_BACKGROUND_FGS_STARTS_RESTRICTION_ENABLED
to turn on/off this feature (default is on).
3. In dogfood, if a background started FGS with while-in-use permission
(any of location/camera/microphone) run into this restriction, the FGS
will not been granted these permission. we show a toast message to
alert user and ask them to write a bugreport using instruction at
go/r-bg-fgs-restriction. So we can have a statistic how many apps will
be impacted by this feature.
These is a flag Settings.Global.FOREGROUND_SERVICE_STARTS_LOGGING_ENABLED
to turn on/off the toast message (default is on, in dogfood)
Bug: 136219221
Test: atest android.app.cts.ActivityManagerProcessStateTest
atest android.app.cts.ActivityManagerApi29Test.java
atest android.app.cts.ActivityManagerFgsBgStartTest
Change-Id: Ibc8aaa6839a69136f9311bfacdbab9705b31b6a7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces the overhead of collecting noted app-ops to the same amount
of binder calls as if we would not have the feature
Before (conceptionally):
---------------------------------
mode = service.noteOp()
if (mode == allowed && shouldCollectAsyncOp) {
fixup(message)
service.noteAsyncOp()
}
----------------------------------
After (conceptionally):
----------------------------------
if (shouldCollectAsyncOp) {
fixup(message)
}
mode = service.noteOp(shouldCollectAsyncOp, message)
----------------------------------
Bug: 136505050
Test: atest CtsAppOpsTestCases
Change-Id: If1b535a7c4b0f431f251c5d06cdf496c34920e23
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently only used by app-ops, but can be used by other modules too.
AppOps will collect app-ops based on feature. Only the most basic
parts of app-ops are supporting features yet. The rest will be added
later.
Test: atest CtsAppOpsTestCases
atest RunSettingsLibRoboTests
atest com.android.server.wm.ActivityStarterTests
m -j doc-comment-check-docs
Bug: 136595429
Change-Id: Ia664f4ff1c1c2ceea721d76dc491ec50c237e9ce
|
| |
|
|
|
| |
Test: Built
Change-Id: I5391ac4989d7d5712982f5608f9fc28cf7935b00
|
| |
|
|
|
|
| |
Bug: 124731615
Test: Built
Change-Id: Ia4d92791145a92fa0c89cf26fc9f627cf7dda559
|
| |
|
|
|
|
|
|
|
|
|
| |
The PermissionManagerService calls AppOpsService before the package
manager is up. Hence AppOpsService cannot verify package properties.
This is not needed in the calls from PermissionManagerService as this
component can be trusted to provide correct data.
Fixes: 127470436
Test: Upgraded from P->Q with a pre-M installed
Change-Id: Ide529f13ab2cc3b7551e99c94935c0cb537a817b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... on every boot.
These should never have been set, but we allow settings them via the
shell.
- Also previously a bug set per-pkg app-ops.
- Also set the app-op correctly when a fg/bg permission looses it's bg
permission.
Test: Set per-pkg app-opp. Rebooted and saw log message.
atest --test-mapping frameworks/base/services/core/java/com/android/server/pm/permission/:presubmit
Change-Id: If3b56fc08783ea99b4dba70c5fa275b94411ce94
Fixes: 123177944
|
| |
|
|
|
|
|
|
|
|
| |
In PermissionManagerService and DefaultPermissionGrantPolicy.
This mirrors what the permission controller is doing. Better make sure
all modules changing app-ops for runtime permissions do it the same way.
Test: Looked at pre-grants after boot, changed permissions after boot
Change-Id: I88386ec6842324b28ab408ea5cd113c9cc7de9fe
|
| |
|
|
|
|
|
|
| |
Test: manual
bug:119323172
Change-Id: Ic21d03af3a08bdca76821f2bc644482e7e5a1300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old hack to grant permissions on upgrade was removed. The new code
applies to
- platfrom upgrade
- initial package installation
- package update
Inheriting the grant state is the default behavior for split permissions.
Special cases will be added later.
Also make sure to revoke the permission once the app declares that it is
aware of the permission.
Test: atest CtsPermissionTestCases:SplitPermissionTest
Change-Id: Ie51971530607f0b585cf7a3e11b01b11a28e1de9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
|
|
|
This allows them to continue to have this capability the
same as before we locked down access to it.
Bug: 78480444
Test: manual
Change-Id: If2b0722945235eb67676ace3f54efaa71a64bcde
|