UEFI Secure Boot and Ubuntu - implementation

[Jamie Strandboge]

On Sat, 2012-06-23 at 04:21 +0100, Matthew Garrett wrote:
> > Therefore, we will only be requiring authentication of boot loader
> > binaries.  Ubuntu will not require signed kernel images or kernel
> > modules.
> 
> How are you going to prevent your bootloader from being used to launch a 
> trojaned Fedora kernel, for instance? This is the kind of decision that 
> doesn't just affect Ubuntu, it has ramifications for the security model 
> that other distributions use. This makes it impossible to implement any 
> kind of signed userspace unless the user explicitly revokes the Ubuntu 
> bootloader first or uses their own trust chain.

Our reading of the UEFI specification and the Windows 8 logo
requirements is that Secure Boot is designed to protect early boot only.
Protecting the code before ExitBootServices is a worthwhile protection
in and of itself and, from a security point of view, something that
Secure Boot can solve well.

You are right to point out that Ubuntu's current plan is not enough if
someone wants a signed userspace. However, extending Secure Boot
concepts to perform a fully or partially attested boot is not something
that Ubuntu currently wants to pursue. Why? From a security perspective
signing the kernel doesn't actually do enough[1] and signing large
portions of userspace to solve that deficiency is not an attractive
option for many reasons, not least of which is that it reduces the
utility of the distribution.

As you know, Secure Boot is a very thorny issue and things get
complicated quickly. Consider if all FLOSS distributions that want to
support secure boot use Fedora's method:

 * MS signs the 1st stage shim for each distro
 * the 1st stage verifies the 2nd stage loader (distro-signed)
 * the 2nd stage verifies the kernel (distro-signed)
 * the kernel verifies the modules and on up the stack

At this point, because all the OS' stage 1 bootloaders (FLOSS and
non-FLOSS) are signed by the same authority, we are all are affected by
the others. It is clear that if there is a problem with DistroX's boot
loader, malware authors will just use DistroX's vulnerable boot loader
to attack DistroY and any other systems that don't yet have an update to
dbx (including DistroX itself). Obviously this is the purpose of dbx,
but dbx is only useful if the individual or OS vendor has a key in KEK
such that dbx can be updated.

Optimistically speaking, since there isn't a ton of early boot code, in
time I expect the bootloader vulnerabilities/bypasses should diminish
and people will be looking at the other parts of the system to attack.
For example, if there is a problem in DistroY's kernel that affects
secure boot (eg, module verification), then a malware author could use
DistroY's kernel and bootloader to attack DistroZ and any systems that
don't yet have an update to dbx for DistroY's stage 1 bootloader
(including DistroY itself). The attack places the old stage 1, old stage
2 and vulnerable kernel and/or modules in place and on reboot, it all
verifies. So we need to update the stage 1 bootloader to embed a CSR for
every kernel upgrade, get the updated bootloader signed, install the new
bootloader and kernel, and update dbx to revoke the old bootloader. The
new bootloader can then use the embedded CSR to see if the stage 2 was
revoked, and the stage 2 can use an embedded CSR to see if the kernel
was revoked (having two stages when you control dbx is not strictly
required). This is all doable when the individual/OS vendor controls the
key in KEK, but really painful when going through a 3rd party signing
authority. It would be a shame if Free Software users had to wait on a
3rd party to sign security updates for their distribution's kernel
(indeed, imagine a public critical kernel security update that has to
wait days/weeks to be signed before rolling out to users).

For these reasons, it seems clear to me that extending Secure Boot to
include a partially or fully attested boot by signing the kernel and
modules just doesn't seem to work well enough to justify the significant
inconvenience to the individual/OS vendor when the individual/OS vendor
doesn't have a key in KEK to control dbx.

http://lists.fedoraproject.org/pipermail/users/2012-June/419026.html

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120625/8ea425f0/attachment.pgp>