[arch-releng] Secure Boot support (FS#53864)

[Jonas Witschel]

On the bug tracker there was a question regarding the access to the
secret key and the reproducibility of packages containing signed
binaries. This concerns the second approach I suggested, i.e.

> Using a signed shimx64.efi built by Arch Linux
> ----------------------------------------------
> It is possible to build shim yourself and get it signed by Microsoft.
> [...]
> [I]t is possible to embed the public key of a certificate into the shim binary [...].> This certificate can be used to sign the boot loader and kernel so
that Secure Boot works
> completely automated out of the box, without having to enrol hashes.
I think the best solution here is to use detached signatures and a
separate package for the signed binaries, which builds the unsigned
binary as usual, then attaches the signature (which can be distributed
publicly, unlike the secret key) and checks whether this results in a
valid signed binary.

Example
-------
Consider the systemd-boot boot loader: the systemd package would stay
unmodified and is used to build the unsigned EFI binary
"systemd-bootx64.efi". To distribute a signed binary
"systemd-bootx64.efi.signed", a person holding the secret key to the
signing certificate would extract the binary and sign it by using a
script along the following lines:

tar -s '|.*/||' -xf systemd-*-x86_64.pkg.tar.xz \
  usr/lib/systemd/boot/efi/systemd-bootx64.efi
sbsign --cert pub.crt --key priv.key --detached systemd-bootx64.efi

This creates a signature file "systemd-bootx64.efi.pk7", which isn't
very useful on its own, but can be used to build a package
"systemd-boot-signed" that contains a complete signed binary:
The PKGBUILD of this new package is mostly the same as the existing
systemd package, except for the following modifications: the public part
of the signing certificate "pub.crt" and the signature
"systemd-bootx64.efi.pk7" are added to the sources array (and to the
public repository), and the build functions are adjusted as follows:

build(){
  # [...] usual build function here
  # sign the binary with the provided signature
  sbattach --attach "$srcdir/systemd-bootx64.efi.pk7" \
    build/src/boot/efi/systemd-bootx64.efi
}

check() {
  # [...] usual check function here
  # verify that the signature is valid
  sbverify --cert pub.crt build/src/boot/efi/systemd-bootx64.efi
}

package() {
  # distribute only the signed binary
  install -Dm755 build/src/boot/efi/systemd-bootx64.efi \
    "$pkgdir/usr/lib/boot/efi/systemd-bootx64.efi.signed"
}

Evaluation
----------
This has the following advantages:
+ Since the original package is not modified, users wanting to use the
unsigned binaries (e.g. because they rebuild the package with local
modifications) aren't affected at all.
+ Building the main and the signed package can be split between
different developers/TUs, i.e. the maintainer of the original package
does not necessarily need to have access to the signing key.
+ The amount of purely binary content (i.e. the signature) is kept to
the absolutely necessary minimum.
+ It is possible for anybody to independently build and verify the
signed package, check() will fail if the signature does not match the
built binary.

Disadvantage:
- The PKGBUILD code is duplicated between the two packages. (Obviously,
it would be easy to script the necessary changes to the signed package
to minimise human error.)

Alternatives
------------
Alternatives to this approach are:
- Directly generating a signed binary by removing the "--detached"
option from sbsign and distributing it as a binary package
"systemd-boot-signed-bin". Avoids the PKGBUILD duplication, but makes it
harder to verify that the signed binary is indeed the one built from
source (but still doable by removing the signature with "sbattach
--remove" and comparing the unsigned binaries).
- Incorporating the assembly of the signature into the original
PKGBUILD, e.g. by adding a makepkg option "--no-efi-sign" that skips all
the signature stuff. You would then first build the unsigned binaries
using this option, then you create the detached signature, add it to the
sources and rerun with a normal "makepkg". This avoids the code
duplication, but would probably require changes to makepkg because the
currently available options don't seem to be a good match for this scenario.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-releng/attachments/20190123/83772f1b/attachment.asc>