tree ba4cd327711071d7f48e931c746dc7fdc595e8b3
parent c20fcfeeffd75bf4ccfb06527ef529d2630b2203
author Michael Groover <mpgroover@google.com> 1589594748 -0700
committer Michael Groover <mpgroover@google.com> 1590191452 +0000

Address edge cases for signing certificate lineages in sharedUids

Currently when a package is installed / updated in a sharedUid the
signatures for the sharedUid are not updated unless the new package
adds a new signer to the lineage; in this case the new lineage is
assigned to the sharedUid without consideration for the existing
lineage. This leads to the following problems:

1. If the current sharedUid lineage is A -> B and the new package has
lineage B -> C then this is used for the sharedUid and A is lost from
the lineage.
2. If the new lineage revokes one or more capabilities from a previous
signer in the lineage these updated capabilities are ignored unless the
lineage added a new signer as well.
3. If the new lineage revokes the sharedUid capability from a previous
signing key in the lineage and another app is installed as part of the
sharedUid and signed with that key the new app's installation is allowed
to proceed.
4. If only a single app is installed as part of a sharedUid, and that
app is updated with a rotated key and a lineage that revokes the
previous signing key's sharedUid capability the update is blocked.
5. If an app is installed as part of the sharedUid and has a diverged
signer in the lineage (ie sharedUid lineage is Y -> A -> B and new app
lineage is Z -> A -> B -> C) the installation is allowed and Y is lost
from the lineage.

Problems 1 and 2 are addressed with the new SigningDetails
mergeLineageWith method that merges common signers between two lineages
and also updates their capabilities to the most restrictive between
the two lineages (capabilities are anded together). Problems 3 is
addressed by checking the signatures of each of the packages in the
sharedUid for any signed with an ancestor for which the sharedUid
capability may have been revoked. Problem 4 is addressed by checking
if the package being updated is the only one in the sharedUid; if so
the update to the new lineage is allowed to proceed. Problem 5 is
addressed by verifying the new app's lineage is the same, a subset, or
a superset of the other.

Bug: 152046935
Test: atest PkgInstallSignatureVerificationTest
Test: atest SigningDetailsTest
Test: atest PackageManagerTests
Test: atest PackageManagerTest
Change-Id: I420c309f522bb47b65ca40ee848024c85cd5804d