This CL makes the following modifcations:
1. Add LockPatternUtils.StrongAuthTracker to monitor
the lockdown mode status of the phone.
2. Call mListeners.notifyRemovedLocked with all the
notifications in the mNotificationList when entering
the lockdown mode.
3. Call mListeners.notifyPostedLocked with all the
notifications in the mNotificationList when exiting
the lockdown mode.
4. Dismiss the function calls of notifyPostedLocked,
notifyRemovedLocked, and notifyRankingUpdateLocked
during the lockdown mode.
The CL also adds corresponding tests.
Bug: 173721373
Test: atest NotificationManagerServiceTest
Test: atest NotificationListenersTest
Test: manually verify the paired device cannot receive
notifications when the host phone is in lockdown mode.
Ignore-AOSP-First: pending fix for a security issue.
Change-Id: I7e83544863eeadf8272b6ff8a9bb8136d6466203
Merged-In: I7e83544863eeadf8272b6ff8a9bb8136d6466203
(cherry picked from commit 3cb6842a05)
* changes:
[RESTRICT AUTOMERGE] Log to EventLog on prepareUserStorage failure
[RESTRICT AUTOMERGE] Ignore errors preparing user storage for existing users
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery for system user only
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery if preparing user storage fails
[RESTRICT AUTOMERGE] StorageManagerService: don't ignore failures to prepare user storage
Check user unlocked before write to /data/system_ce/0/snapshots
NPE happens when there is an orphaned session which we've
tried to prevent in all cases.
Log an error message if this situation happens.
Bug: 227342978
Test: atest CtsRootPackageInstallerHostTestCases
Change-Id: Ia21323926bd9db1a6f05461904deb45b4c3dd0bc
(cherry picked from commit 07e31dfb1e)
Merged-In: Ia21323926bd9db1a6f05461904deb45b4c3dd0bc
This addresses a security issue where the guest user can remove updates
for system apps.
With this CL, attempts to uninstall/downgrade system apps will fail if
attempted by a non-admin user.
This is a backport of ag/17352264.
Bug: 170646036
Test: manual, try uninstalling system app update as guest
Change-Id: I5bbaaf83d035c500bfc02ff4b9b0e7fb1e7c2feb
Merged-In: I4e959e296cca9bbdfc8fccc5e5e0e654ca524165
Unfortunately we can't rule out the existence of devices where the user
storage wasn't properly prepared, due to StorageManagerService
previously ignoring errors from mVold.prepareUserStorage, combined with
OEMs potentially creating files in per-user directories too early. And
forcing these broken devices to be factory reset upon taking an OTA is
not currently considered to be acceptable.
One option is to only check for prepareUserStorage errors on devices
that launched with T or later. However, this is a serious issue and it
would be strongly preferable to do more than that.
Therefore, this CL makes it so that errors are checked for all new
users, rather than all new devices. A field ignorePrepareStorageErrors
is added to the user record; it is only ever set to true implicitly,
when reading a user record from disk that lacks this field. This field
is used by StorageManagerService to decide whether to check for errors.
Bug: 164488924
Bug: 224585613
Test: Intentionally made a device affected by this issue by reverting
the CLs that introduced the error checks, and changing vold to
inject an error into prepareUserStorage. Then, flashed a build
with this CL without wiping userdata. The device still boots, as
expected, and the log shows that the error was intentionally
ignored. Tested that if a second user is added, the error is
*not* ignored and the second user's storage is destroyed before it
can be used. Finally, wiped the device and verified that it won't
boot up anymore, as expected since error checking is enabled for
the system user in that case.
Change-Id: I9bdd1a4bf5b14542adb901f264a91d489115c89b
(cherry picked from commit 60d8318c47)
Merged-In: I9bdd1a4bf5b14542adb901f264a91d489115c89b
With the next CL, old devices might contain a combination of old users
with prepareUserStorage error checking disabled and new users with
prepareUserStorage error checking enabled. Factory resetting the whole
device when any user fails to prepare may be too aggressive. Also,
UserDataPreparer already destroys the affected user's storage when it
fails to prepare, which seems to be fairly effective at breaking things
for that user (absent proper error handling by upper layers).
Therefore, let's only factory reset the device if the failing user is
the system user.
Bug: 164488924
Bug: 224585613
Change-Id: Ia1db01ab4ec6b3b17d725f391c3500d92aa00f97
(cherry picked from commit 4c76da76c9)
Merged-In: Ia1db01ab4ec6b3b17d725f391c3500d92aa00f97
StorageManager.prepareUserStorage() can throw an exception if a
directory cannot be encrypted, for example due to already being
nonempty. In this case, usage of the directory must not be allowed to
proceed. UserDataPreparer currently handles this by deleting the user's
directories, but the error is still ultimately suppressed and starting
the user is still allowed to proceed.
The correct behavior in this case is to reboot into recovery to ask the
user to factory reset the device. This is already what happens when
'init' fails to encrypt a directory with the system DE policy. However,
this was overlooked for the user directories. Start doing this.
Bug: 164488924
Bug: 224585613
Change-Id: Ib5e91d2510b25780d7a161b91b5cee2f6f7a2e54
(cherry picked from commit 5256365e65)
Merged-In: Ib5e91d2510b25780d7a161b91b5cee2f6f7a2e54
We must never leave directories unencrypted.
Bug: 164488924
Bug: 224585613
Change-Id: I9a38ab5cca1ae9c9ebff81fca04615fd83ebe4b2
(cherry picked from commit 50946dd15f)
Merged-In: I9a38ab5cca1ae9c9ebff81fca04615fd83ebe4b2
Currently SliceManagerService#checkSlicePermission does not verify the
caller's identity. This leads to a security vulnerability because
checkSlicePermission does more than checking the permission as opposed
to simply return a boolean value -- it additionally grants slice access
under a certain condition. A malicious app can spoof the calling package
to acquire slice access.
This CL verifies the caller before granting slice access.
Bug: 208232850, 179699767
Test: manual
Change-Id: I2539c9ff5ea977c91bb58185c95280b4d533a520
Merged-In: I2539c9ff5ea977c91bb58185c95280b4d533a520
(cherry picked from commit 5bd2196c53)
The top-focusable activity resides in the RESUMED state while the app
process is newly created and attached. The behavior may enable UI
hijacking attacks against apps implementing authentication.
This CL disallows the system to resume the activity for the case if it
is not visible or is occluded by other translucent tasks.
Bug: 211481342
Test: atest CtsWindowManagerDeviceTestCases:ActivityLifecycleTests
Change-Id: I7903494cf928b5b5613700262b7c5fff10f3c5a0
setBlocked is a hidden API, so apps should not be calling
the method, but fix up the data in case they do
Test: PreferencesHelperTest; manual with ApiDemos FGS
Bug: 209966086
Change-Id: Icc709a6b0d0a8c5f2d9243959992f1b6764354db
Merged-In: I8a27853c7ed05d9dfd38a3142fbbe185946c3992
Currently, when we abandon a staged session we mark it as destroyed and
then immediately clean it up. Cleaning up a staged session immediately
causes racing condition with pre-reboot verification.
In order to avoid the racing condition, we want to delay cleanup of
staged session until it is safe to do so. This means, the system will
be carrying around destroyed staged sessions internally.
Since there is now a gap between when a session is destroyed and when it
is cleaned up, the user can reboot in this window. As such, we need to
persist the mDestroyed field of session so that we know session is
destroyed after reboot and act accordingly.
Also, once a session is destroyed, theoretically it doesn't exist.
Carrying it around internally is an implementation details which
shouldn't be exposed externally. As such, we filter out destroyed
sessions before surfacing them to users.
Bug: 145925842
Bug: 67862680
Test: atest PackageInstallerSessionTest
Test: atest StagedInstallTest
Change-Id: I4ede6b7a4b5d861e5c73f13884c7aa86cf7633a2
Merged-In: I4ede6b7a4b5d861e5c73f13884c7aa86cf7633a2
(cherry picked from commit 731bd965fb)
Before allowing the group to be deleted, by updating
the current check to the method that populates the channel
list
Test: NotificationManagerServiceTest
Bug: 209965481
Change-Id: I9db781c300e96e9c80bd5d21585b8be9b4db08c8
Merged-In: I9db781c300e96e9c80bd5d21585b8be9b4db08c8
It will throw if abandon() is called on a child session.
Bug: 211944991
Bug: 67862680
Test: to be added
Change-Id: Ib0ba9f3786dda2d3174f3ea8c65d1061a3fcb586
Merged-In: Ib0ba9f3786dda2d3174f3ea8c65d1061a3fcb586
(cherry picked from commit 8b67e7db79)
Any malicious application could hijack tasks by
android:relinquishTaskIdentity. This vulnerability can perform UI
spoofing or spy on user’s activities.
This CL limit the usage which only allow system and same app to apply
relinquishTaskIdentity
Bug: 185810717
Test: atest IntentTests
atest ActivityStarterTests
Change-Id: I55fe8938cd9a0dd7c0268e1cfec89d4e95eee049
migrateExtraStreamToClipData() will only offer to promote Uri values
if a ClipData isn't already defined, so we ensure that a ClipData
value is always defined. This blocks later promotion and granting.
Bug: 200683077
Bug: 123700107
Test: manual
Change-Id: I99c1411e8b4eb01eb27ac4306e3bf6cc88cb4273
(cherry picked from commit 6ebf410b81)
This reverts commit b45ebca772.
Reason for revert: adding the fix for system to abandon sessions
BUG: 67862680
Test: manual
Change-Id: I2b735e4860dce6eb6d5d8ddc158e8b3165910dc7
Merged-In: I91170ba399b3a596320b3bd9c8188912e5c4f1be
This reverts commit b45ebca772.
Reason for revert: adding the fix for system to abandon sessions
BUG: 67862680
Test: manual
Change-Id: Ia798eb776eb1d05347514a238a6dd75e7c89e872
Merged-In: I91170ba399b3a596320b3bd9c8188912e5c4f1be
See comment here for the discussion on solution
https://b.corp.google.com/issues/169762606#comment14
Change-Id: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
Bug: 169762606
(cherry picked from commit 11053c17b3)
Change-Id: I424e098dd70ae31bbbc7cb2f3eccd1ccc287064b
Merged-In: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
See comment here for the discussion on solution
https://b.corp.google.com/issues/169762606#comment14
Change-Id: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
Bug: 169762606
(cherry picked from commit 11053c17b3)
Change-Id: I6494366a5695daedc3f4f0046da9e130a5363f5f
Merged-In: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
In case the broadcast intents "com.android.server.net.action.SNOOZE_WARNING"
or "com.android.server.net.action.SNOOZE_RAPID" are dispatched to apps,
then add a SafetyNet log.
Bug: 177931370
Test: manual
Change-Id: I65b2e96ff1230b2051dd1e5bd9c21e5ba3e1146a
Merged-In: I65b2e96ff1230b2051dd1e5bd9c21e5ba3e1146a
(cherry picked from commit a22e341ac2)
In case the broadcast intents "com.android.server.net.action.SNOOZE_WARNING"
or "com.android.server.net.action.SNOOZE_RAPID" are dispatched to apps,
then add a SafetyNet log.
Bug: 177931370
Test: manual
Change-Id: I65b2e96ff1230b2051dd1e5bd9c21e5ba3e1146a
Merged-In: I65b2e96ff1230b2051dd1e5bd9c21e5ba3e1146a
(cherry picked from commit a22e341ac2)
