| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Bug: 182423603
Test: none
Change-Id: I3c92a3150d3f22b4ed072a66d6b080e00a7ddabe
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bug:158792096
bug:180647319
bug:184051153
bug:184027531
Test:atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
atest CtsAlarmManagerTestCases
Change-Id: Id324ed0e2a653dface6ba273bba27e92bea14f99
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this parameters object is likely going to grow over time, we
should offer a way for callers to easily "inherit" all sub-parameters
by default, instead of making them copy the values manually.
This also gives a path for legacy apps to automatically preserve any
new sub-parameters that have been added in more modern API levels.
This change also relaxes the nullability annotations to match the
existing createAttributionContext() behavior, while also supporting
clearing of specific inherited values.
Bug: 181812281
Test: atest CtsContentTestCases:android.content.cts.ContextTest
Change-Id: Ic797e1aef578926b04ea0000ca3a1bf8684183b9
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The nullability annotations on these methods are aspirational,
and a recent CL started routing many existing call-sites through
them, so we'll need to start allowing nulls. I'm not at a full
workstation right now, so this CL simply relaxes the enforcement,
and a future CL will adjust the API annotations.
Bug: 182091763
Change-Id: I43d49747deb8c7881d942eba48237eb0fccc7acd
Merged-In: I43d49747deb8c7881d942eba48237eb0fccc7acd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Different logical components within an app may have no intention of
interacting with data or services that are protected by specific
permissions.
The new overload added in this change provides the initial mechanism
for a logical component to indicate a set of permissions that should
be treated as "renounced". Interactions performed through the
returned Context will ideally be treated as if the renounced
permissions have not actually been granted to the application,
regardless of their actual grant status.
This is a low-risk change from a security standpoint, since it can
only reduce the set of permissions that might have been granted to
an app; it can never be used to expand the set of permissions.
Note that this change only provides an initial implementation which
only applies to local permission checks within the app; future
changes will begin wiring this up across process boundaries.
Bug: 181812281
Test: atest CtsContentTestCases:android.content.cts.ContextTest
Change-Id: I96439e5344c85300fb6a0f03e572746c3c96ee95
|
|
|
Test: Follow up CL (tracked in the bug below)
bug:158792096
Change-Id: Iecc9e5e52ce130df0fedee18050e2779c4e5eef3
|
