* 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
* 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)
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
- If WiFi configuration is not allowed, the WiFi QR code intent is
ignored.
- Add SafetyNet Logging to b/202017876.
Bug: 202017876
Test: manual test
make RunSettingsRoboTests ROBOTEST_FILTER=WifiDppEnrolleeActivityTest
Change-Id: I147d2f4f4fabe2e24d5d3eaaad701b81059e8eee
