questions about UEFI-Secure Boot
Hi,
I have some questions about UEFI-Secure Boot; some are very general
questions how this works and what it provides, some are about the
proposed implementation (like how long signing takes).
I'm trying to understand what the requirements are and what we are
trying to provide to be able to come up with a solution that also
works well for ftp-master.
What do we want?
----------------
Is this just about being able to boot on hardware that has UEFI-Secure
Boot with Microsoft keys enabled by default? Or are there any further
benefits?
What are the minimal requirements?
----------------------------------
What is the minimal effort? As far as I understand Microsoft will sign
shim; shim will boot stuff signed by Debian's key (grub, kernel); grub
is allowed to boot a signed kernel and unsigned kernels if
ExitBootServices() is called before control is handed over.
So the minimal effort is to just have grub signed by Debian? Or could
even shim call ExitBootServices and just continue loading grub like on
systems without UEFI-Secure Boot enabled?
It was mentioned that the kernel might want to run quirks before calling
ExitBootServices (and so the kernel has to be signed). Can these run
before modules are loaded? Or are they included in modules? What
happens if they are not run (as for an unsigned kernel)?
Can the kernel apply the quirks when UEFI-Secure Boot is not enabled?
In the default configuration (where anything MS signed will be booted),
nothing stops an attacker from replacing shim + grub2 with a version
booting an unsigned kernel. So there is no security benefit in having
the kernel signed?
How many packages are we talking about?
---------------------------------------
So far I think shim, grub2, linux, in signed and unsigned versions were
mentioned. Or do more packages provide binaries that need signatures?
What architectures are we talking about?
----------------------------------------
Just amd64? But doesn't arm* have UEFI-Secure Boot too (but MS will not
sign stuff with their arm key or so)?
How long does signing take?
---------------------------
Using a YubiKey as proposed, how long does signing all binaries take for
the different packages?
What happens when UEFI-Secure Boot can be bypassed?
---------------------------------------------------
The requirements from Microsoft state that no unauthenticated code must
be executed before ExitBootServices is called and may revoke submissions
that allow this to happen.
What happens when root can get the Linux kernel or grub to do so (for
example by exploiting a bug)? Might Microsoft revoke the shim
signature?
Who can upload files to be signed?
----------------------------------
It was proposed that not all DDs should be able to upload binaries that
will be signed. Why?
Who can update shim?
--------------------
Who can update shim(-signed)?
src:shim-signed includes pre-built binary
-----------------------------------------
src:shim-signed contains a binary without source (the source is in
shim). Could it only contain the detached signature (sbattach --detach)
in the source package and combine it with the binary from shim at build
time? Plus a hash to make sure the result is what it should be.
The package currently does the inverse: it removes the signature and
checks that the signed-binary-with-signature-removed is identical to the
unsigned binary.
(The shim-signed binary package uses Built-Using, but there is no
equivalent for source packages. dak might keep the shim-signed source
package around without the corresponding binary package; nothing would
keep in the shim source package via Built-Using.)
My wishlist
-----------
This is my wishlist for the integration into Debian's infrastructure.
Is there anything else we need to keep in mind?
- Automate as much as possible:
- Don't require ftpmaster to manually process uploads.
- Ideally maintainer should just have to upload unsigned package as
usual, everything else happens automatically.
- Security uploads should work.
This includes automatically syncing the package to ftp-master after
publication; the sync should not cause ftp-master to sign the binaries
again.
Alternatively, only sign binaries once they reach ftp-master. If only
grub needs to be signed, it's probably not too large of a problem to
have updates for UEFI-Secure Boot enabled systems delayed a bit more.
- Try to keep as much reproducible as possible.
Obviously generating the signature itself cannot be reproducible.
- Buildds should not require network access for builds.
- Transparency: sign only binaries that will be published.
Possible exception: security uploads that were never published. We
need the signature before publication can happen.
- Don't add new BYHAND scripts to dak.
- Please clarify expected future obligations.
The expectation that ftp-master should review every upload in the
future came as a late surprise to me.
Possible implementations
------------------------
The first and forth option are from [1]. The second and third options
are modifications of the first one I thought a bit about. The last one
is just included for completeness.
[1]: https://wiki.debian.org/SecureBoot
- "byhand (a)":
Builds include BYHAND tarball with binaries to sign; dak signs them
and publishes a tarball of signed binaries somewhere; someone uses
the output to upload -signed source.
- "byhand (b)":
Instead of publishing a tarball, have dak generate src:...-signed and
upload it
- "trigger":
A variant of "byhand (*)", but instead of a BYHAND tarball, teach dak
to trigger an action (possibly run only later) after a certain source
package was uploaded. Then have dak extract the binaries to be signed
from the unsigned *.deb packages.
The trigger could also run elsewhere (even without dak involved at
all) as long as the system has access to the archive (including the
private buildd archive for security uploads).
- "dh_sign":
Build invokes dh_sign on buildd which sign binaries (via some
communication); signed binaries are uploaded to the archive.
- "manual":
Create the signed versions manually.
I think this will be the case for shim either way.
Ansgar
Reply to: