If the intent's package equals to the app's package, this intent
will be allowed to startActivityForResult.
But this check is unsafe, because if the component of this intent
is set, the package field will just be ignored. So if we set the
component to any activity we like and set package to the app's
package, it will pass the assertSafeToStartCustomActivity check
and now we can launch anywhere.
Bug: 223578534
Test: robotest and manual verify
Change-Id: I40496105bae313fe5cff2a36dfe329c1e2b5bbe4
(cherry picked from commit 90e095dbe3)
If the intent's package equals to the app's package, this intent
will be allowed to startActivityForResult.
But this check is unsafe, because if the component of this intent
is set, the package field will just be ignored. So if we set the
component to any activity we like and set package to the app's
package, it will pass the assertSafeToStartCustomActivity check
and now we can launch anywhere.
Bug: 223578534
Test: robotest and manual verify
Change-Id: I40496105bae313fe5cff2a36dfe329c1e2b5bbe4
(cherry picked from commit 90e095dbe3)
To improve security.
Bug: 181962311
Test: manual
Show an AlertDialog and observe if it will hide after below command.
adb shell am start -a android.intent.action.PICK_ACTIVITY -n com.android.settings/.ActivityPicker
Change-Id: I800f0f39a469a95eb36eeaaeb2aa60a39fd916d3
Merged-In: I800f0f39a469a95eb36eeaaeb2aa60a39fd916d3
To improve security.
Bug: 181962311
Test: manual
Show an AlertDialog and observe if it will hide after below command.
adb shell am start -a android.intent.action.PICK_ACTIVITY -n com.android.settings/.ActivityPicker
Change-Id: I800f0f39a469a95eb36eeaaeb2aa60a39fd916d3
Merged-In: I800f0f39a469a95eb36eeaaeb2aa60a39fd916d3
To improve security.
Bug: 181962311
Test: manual
Show an AlertDialog and observe if it will hide after below command.
adb shell am start -a android.intent.action.PICK_ACTIVITY -n com.android.settings/.ActivityPicker
Change-Id: I800f0f39a469a95eb36eeaaeb2aa60a39fd916d3
Merged-In: I800f0f39a469a95eb36eeaaeb2aa60a39fd916d3
Hide private DNS settings UI in Guest mode to prevent guest
users modifying global private DNS settings.
Bug: 206987762
Test: 1. make RunSettingsRoboTests \
ROBOTEST_FILTER=PrivateDnsPreferenceControllerTest
2. Switch to Guest user and check if the private DNS UI is
hidden or not.
Change-Id: Iebfb8684da3be32110decd9e8447dd07b1c40387
This is a backport of ag/17005706.
This adds mitigations to prevent system files being exfiltrated
via the settings content provider when a content URI is provided
as a chosen user image.
The mitigations are:
1) Copy the image to a new URI rather than the existing takePictureUri
prior to cropping.
2) Only allow a system handler to respond to the CROP intent.
Bug: 187702830
Test: build and check functionality
Change-Id: Ia6314b6810afb5efa0329f3eeaee9ccfff791966
Merged-In: I15e15ad88b768a5b679de32c5429d921d850a3cb
* Only the Settings app can reset credentials
via com.android.credentials.RESET.
* com.android.credentials.INSTALL should still be
callable by CertInstaller.
Manual testing steps:
* Install certificate via Settings
* Verify unable to reset certificates via test app
provided in the bug (app-debug.apk)
* Verify able to reset certificates via Settings
* Verify com.android.credentials.INSTALL isn't changed
Bug: 200164168
Test: manual
Change-Id: I9dfde586616d004befbee529f2ae842d22795065
(cherry picked from commit 4c1272a921)
Merged-In: I9dfde586616d004befbee529f2ae842d22795065
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
In onReceive of AppRestrictionsFragment.java, there is a possible way to
start a phone call without permissions due to a confused deputy.
This could lead to local escalation of privilege with no additional
execution privileges needed.
We should not allow the restrictionsIntent to startActivity simply
because it resolves to multiple activities.
Instead, we should call resolveActivity and check the result's package
name is same as current package name, then it is safe to startActivity.
Bug: 200688991
Test: manual verify
Change-Id: Iaa2d3a9497c3266babe0789961befc9776a4db7a
Merged-In: Iaa2d3a9497c3266babe0789961befc9776a4db7a
(cherry picked from commit 359512cd95)
* Only the Settings app can reset credentials
via com.android.credentials.RESET.
* com.android.credentials.INSTALL should still be
callable by CertInstaller.
Manual testing steps:
* Install certificate via Settings
* Verify unable to reset certificates via test app
provided in the bug (app-debug.apk)
* Verify able to reset certificates via Settings
* Verify com.android.credentials.INSTALL isn't changed
Bug: 200164168
Test: manual
Change-Id: I9dfde586616d004befbee529f2ae842d22795065
(cherry picked from commit 4c1272a921)
Merged-In: I9dfde586616d004befbee529f2ae842d22795065
