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
signature.asc
Description: This is a digitally signed message part
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
