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
We recently added a new "Bundle extras" argument to insert(),
update(), delete(), and query(), so we should ensure that developers
working from the shell can populate these extras.
Uses binding logic that was already used for call() extras. Fixes
parsing logic to support keys or values that have escaped colons,
and fix bug to always parse as requested data type.
Bug: 150982673
Test: adb shell content query
--uri content://media/external/images/media/
--extra android\\\\:query-arg-match-trashed:i:3
Change-Id: I40a9a94e85e175e298b01688d3b075a89b2e3954
A few releases ago we added ContentResolver.QUERY_ARG_* constants
to query() as a new best-practice that will help wean us off raw
SQL arguments. (For example, a provider could add their own
custom arguments like QUERY_ARG_INCLUDE_PENDING to cause the query
to reveal pending items that would otherwise be hidden.) This
change expands update() and delete() to accept those arguments.
This change also expand insert() to accept extras too, as part of
preparing to support an upcoming MediaProvider feature that will let
apps place new media "adjacent" to an existing media item. (Sending
that adjacent item through extras is cleaner than trying to send it
through escaped query parameters.)
Bug: 131643582
Test: atest CtsContentTestCases
Change-Id: I436296155b9b5f371b4cbe661feaf42070285fcc
This takes the Context#getFeatureId from the calling context and pipes
it all way through to the noteOp calls done by the content provider.
Bug: 136595429
Test: atest CtsAppOpsTestCases (new test added to capture this case)
TelecomUnitTests:CallLogManagerTest
ContentProviderClientTest
TelecomUnitTests:MissedCallNotifierImplTest
TelecomUnitTests:BasicCallTests
MediaInserterTest
PreferencesHelperTest
RankingHelperTest
PinnedSliceStateTest
FrameworksCoreTests:ContentResolverTest
Change-Id: I53b1035626229c920b353509a5bece157b52fb51
See build/soong/README.md for more information.
Also converts the rest of frameworks/base/tools/streaming_proto.
Bug: 122332340
Test: m checkbuild
Change-Id: I87c500c5464fb1722b4b518d89065f5e1ee29a97
(cherry picked from commit 45c0d71e774c84ec81392393a0fafad398d2838d)
See build/soong/README.md for more information.
Also converts the rest of frameworks/base/tools/streaming_proto.
Bug: 122332340
Test: m checkbuild
Change-Id: I87c500c5464fb1722b4b518d89065f5e1ee29a97
Merged-In: Ieb54feb3902bddfd5a571369fbf50161ae646647
Existing APIs that accept a ContentResolver are too restrictive when
the caller has their own ContentProviderClient already bound and
configured, so we're in the market for a solution to open those
existing APIs to accept a wider range of inputs.
The solution we've come up with is to introduce a super-interface
which contains the common ContentProvider APIs, and then make
ContentProvider, ContentResolver, and ContentProviderClient all
implement that interface for consistency.
After this change lands, we can then safely relax existing APIs to
accept this new ContentInterface, offering a clean path to solving
the problem outlined above.
Bug: 117635768
Test: atest android.content.cts
Test: atest android.provider.cts
Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e
Exempted-From-Owner-Approval: keep tests working
When the caller doesn't hold the ACCESS_MEDIA_LOCATION permission,
any location Exif tags should be redacted for privacy reasons. We
still allow unredacted raw file access if the media is owned by the
calling app, since they should be able to see data they contributed.
Certain backup apps really want to see the original contents without
any redaction, so provide them a setRequireOriginal() API so they
get a strong exception whenever the original bits can't be provided.
Add the ability to open a redacted file for read/write access by
stopping redaction for any ranges that have been overwritten with
new data, along with tests to verify this behavior.
Extend "content" tool to bind null values.
Bug: 111892141
Test: atest android.os.RedactingFileDescriptorTest
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I47b220036a712d9d49547196b90e031b10760f84
Associations now keep track of the time they are
actively involved in impacting their target application.
This is based on the procstate propagating through the
association being the same as the procstate of its target
process... so it may count as active when there is
another reason for that process to be in the same state.
To do this, we now maintain a set of "tracking
associations" -- these are in-use associations that
we know we need to be tracking to determine whether
they are active. This list is built based on whether
we at all consider an association during an oom_adj
computation, and at the end of that walked to determine
which of those associations are currently active.
Also add tracking of associations through external
provider references, with a tag name now needing to be
passed through so we can mark up the reason for the
external reference.
Test: manual
Bug: 110957691
Change-Id: I426a499834e20a9d7f2b439faf9cb398d9792fa2
There are several places across the OS where Java code is simply
copying data between two points, which requires bringing that data
out into userspace before going back into the kernel. (That's pretty
lame.) The patches for the recent Meltdown/Spectre security issues
have made this overhead even worse, so it's finally time to move this
copying directly into the kernel.
This change adds a couple new FileUtils.copy() methods which inspect
the given streams/FDs, and attempt to do as much optimization as
possible before falling back to a slower userspace-based copy.
Benchmarks are showing typical improvements of 44% for 32KB files,
50% for 32MB files, and 35% for 32MB pipes.
Plenty of tests are included, and there's a simple kill-switch that
can be used to enable/disable the feature if it starts causing any
trouble. (A future CL will enable the optimizations.)
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I52518d529da5d961610998b9f61399064d8025cd
This gives developers an easy way to push temporary testing
configuration data into their apps. We also now have symmetry with
the existing "read" command.
Test: builds, boots, example commands work
Bug: 64672411
Change-Id: I7bf6360915e1e4eb0d6ceaaec674f09931e28c6c
Without this, exec()ing these fails.
Found with `grep -L bin/sh $(grep -Rl Script)`
Bug: None
Test: exec()ed each of these scripts; I no longer get "exec format
error" for any of them.
Change-Id: I47db5007e5cc14ab91eb846b7bffecb925d37874
Bundle returned from ContentProvider.call() may be null, and content
command shouldn't crash because of that.
Test: manual
Change-Id: I4c7e6c2b607b065699b58e6b9bca20e84cdb19ca
All but a few lines of this is for issue #16013164, which allowed
apps to do some operations as the media uid by having it call
back to them to open a file. The problem here is with the tempory
identity stuff in the activity manager, allowing us to make the open
call as the original caller... ideally we should figure out a way
to just get rid of all of that, but the solution here is actually
easier (even though it doesn't look it) -- we now hand a token over
to the openFile() call that it can use when doing permission checks
to say "yes I would like the check to be against whoever is responsible
for the open". This allows us to do the uid remapping for only this
one specific set of permission checks, and nothing else.
Also fix issue #17487348: Isolated services can access system services
they shouldn't be able to. Don't send any system service IBinder objects
down for the first initialization of an isolated process.
Change-Id: I3c70e16e0899d7eef0bae458e83958b41ed2b75e
$ content call
--uri content://com.example
--method methodname
[--arg optional_string_arg]
[--extra name:s:foo --extra value:i:0]
The URI is just used to resolve the provider. --extra has
the same syntax as --bind.
Change-Id: I98cb89f0174a00e7c29ca0d8c8d809d453de3623
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
Otherwise services like SystemUI will always open content://-style
Uris as USER_OWNER. Surfaces through createPackageContextAsUser()
which points all ContentResolver operations towards a given user.
Start using in RemoteViews, so that Notifications correctly resolve
image Uris to the sending user. Also add user support for "content"
shell tool.
Bug: 7202982
Change-Id: I8cb7fb8a812e825bb0b5833799dba87055ff8699
1. Added methods to the ActivityManagerService remote interface
that allow accessing content providers outside of an application.
These methods are guarded by an internal signature protected
permission which is given to the shell user. This enables a
shell program to access content providers.
2. Implemented a shell command that takes as input as standart
fagls with values and manipulates content via the content provider
mechanism.
Change-Id: I2943f8b59fbab33eb623458fa01ea61a077b9845
