mac: Perform Developer ID certificate reauthorization
The code signing certificate is changing!
Previously, Chrome was signed with a designated requirement binding it
to a specific Developer ID certificate. The designated requirement was
used as the basis for the access control list that protected the Chrome
Safe Storage item in the user's Keychain. Every 5 years, as those
certificates expired and were renewed, these Keychain items needed to be
"reauthorized" to ensure that newer versions of Chrome, signed with the
new certificate, would continue to have access. These projects were
previously conducted under bug 629906 and bug 116210.
Recently, Chrome started being signed with a designated requirement
binding it more traditionally for Developer ID code signing. Rather than
using a specific signing certificate, the requirement is now summarized
as "Apple issued a Developer ID Application certificate to Google
(indicated by team ID)". Provided the team ID doesn't change (it hasn't
since the inception of the Developer ID program), the new requirement
should spell the end of periodic reauthorization projects.
Except for this one. For (hopefully) one last time, the Safe Storage
items in users' Keychains need to be reauthorized according to the new
requirement.
The strategy is quite similar to previous reauthorization projects. In
fact, most of this round was developed on fairly clean reverts of
2c29863d6049 and f54c4ad6c92f, which removed the code used for the
previous reauthorization. Reauthorization can be performed by any
process that has access to Safe Storage items that only allow access to
"old-signed" Chrome. Initially, this includes the browser process (see
REAUTHORIZE_IN_APP) but that will cease to be true when the code signing
certificate changes. To allow reauthorizations to be performed even
after that date, the reauthorization stub executable is introduced. It's
a helper executable that's signed as though it were Chrome, and thus has
the necessary access to old Safe Storage item. Like other Chrome
helpers, the stub loads the framework and jumps to a well-known entry
point. The code signing mechanism (in particular, the "library" option
for library validation, and the "runtime" option for the hardened
runtime) prevent abuse. The stub can be launched by Chrome even after
Chrome's own code signing certificate changes.
In this change, the stub executable is built and signed. Once a signed
stub is available, it will be "frozen" and embedded as a binary
component, signed using the old certificate, and maintaining its
validity because it was signed before that certificate expired. Since
the stub contains no code other than that necessary to load and jump to
the framework, it is anticipated that it will not be a problem for it to
exist as a binary component for the duration of the reauthorization
project.
Another follow-up change will switch REAUTHORIZE_IN_APP to 0 in
anticipation of the certificate change for Chrome code. This will cause
all reauthorizations to be performed by the stub.
In addition to performing reauthorization when Chrome is started, it is
also done at update time when updating from a user ticket (as this is
only possible when the updater is running as the user that runs Chrome)
by launching the stub.
Bug: 1263152
Change-Id: Id26437419cfa9bbd0176430ce65be120aee7fe10
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3445684
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#969436}
NOKEYCHECK=True
GitOrigin-RevId: b4e1bfc7a9489c4cc4cb01cbb672cba8ac949cc8
4 files changed
