Ubuntu secure-boot support is broken
If you install Ubuntu on a computer with secure-boot enabled, then it will probably boot. And maybe that’s all you want.
If so, you probably won’t be concerned about what I am describing here.
However, secure-boot is supposed to verify many of the steps in the boot path. And that’s where I see Ubuntu as broken.
I’m basing this on tests that I have done on Ubuntu-17.04 and Ubuntu-gnome-17.04.
First a brief summary of the problems that I am seeing:
- Ubuntu will boot without checking a signature on the kernel.
- Under some circumstances, Ubuntu will complain about a bad signature, and refuse to boot, even though secure-boot has been disabled.
The first of those problems means that most of what secure-boot is supposed to check, can be bypassed. The second problem is quite bizarre. Disabling secure-boot should mean no checks. That it is still checking signatures suggests a coding problem somewhere.
First a little background on booting. Ubuntu uses “grub” (sometimes called “grub2”). The configuration file that “grub” uses is “/boot/grub/grub.cfg” (or “/boot/grub2/grub.cfg on some systems). It is a text file. But it is somewhat complex to read. Fortunately, it is easy to get to the nub. In normal use, the grub command
linux kernel-name parameters
loads the kernel into memory, while the command
loads the initial ram disk that is sometimes used for booting. From that point on, the kernel takes over and completes the boot operation. Most of the rest of what is in “grub.cfg” has to do with finding the directory with the kernel, formatting the menu, and similar.
In place of the grub commands “linux” and “initrd”, it is possible to use “linuxefi” and “initrdefi”. Those are modified versions of the commands intended to be used in UEFI systems. In normal use of grub-efi (the efi version of grub), the kernel signature is only checked when “linuxefi” and “initrdefi” are used for the booting configuration.
I am used to seeing “linuxefi” and “initrdefi” in “grub.cfg”, because I use openSUSE, where those commands are normally used on UEFI boxes. Back when I was running openSUSE 12.3, I found that I could edit “grub.cfg”, and change “linuxefi” to “linux” and “initrdefi” to “initrd” if I wanted to bypass signature checking. However, versions of opensuse starting with 13.1 no longer allow that. The grub commands “linux” and “initrd” no longer work if secure-boot is enabled. Only the “efi” versions of those commands work.
Ubuntu problem 1
In looking at “grub.cfg” on Ubuntu, I noticed that it was using “linux” and “initrd” rather than “linuxefi” and “initrdefi”. This suggested that it is not checking kernel signatures.
I could not actually be sure of that. The Ubuntu developers might have changed the “grub” code so that it still checks the signatures with those “grub” commands.
So I tested. Ubuntu 17.04 came with two kernels. One of them is “vmlinuz-4.10.0-19-generic”, which is unsigned. I’ll refer to that as the “generic kernel”. The other is “vmlinuz-4.10.0-19-generic.efi.signed”, which does have a digital signature.
I should note here, that I made backups of both kernels before I did anything. That way, I could easily restore to the original installed state.
I now copied the generic kernel to replace the signed kernel. After that copy, both installed kernels were identical and unsigned. I then attempted to boot Ubuntu. And it booted without any difficulty. This showed that, with secure-boot enabled, Ubuntu could boot without checking a kernel signature.
Next, I edited “grub.cfg”, and changed the relevant “linux” to “linuxefi” and “initrd” to “initrdefi”. And I again tried to boot. This time, it would not boot, and instead reported a bad signature. Finally, I copied back the original signed kernel, so that it now really was signed. And that booted without a problem (using “linuxefi” and “initrdefi”).
Before I get to the next problem, I’ll describe how I normally use this computer. I’m an openSUSE person. So I prefer to use the boot menu installed by openSUSE. If I want to use the Ubuntu boot menu, I can hit F12 during boot, and the BIOS allows me to select “ubuntu” instead of the default “opensuse-secureboot”. But normally, I want to use the openSUSE menu.
In order to boot Ubuntu and other systems with the openSUSE menu, I have created a Machine Owner Key, and installed that (with MokManager). So, to boot Ubuntu with the openSUSE menu, I used my key to sign the generic kernel. Then, using the file “40_custom” in “/etc/grub.d”, I added commands to boot Ubuntu with that kernel. I used the “linuxefi” and “initrdefi” commands for that booting. I’ll note that this works fine. And I’ll also note that Ubuntu sees my Machine Owner Key (as shown my “mokutil -l”). So Ubuntu should recognize my key for signing kernels.
I originally installed Ubuntu. I then backed up the Ubuntu boot data in the EFI partition. When I later installed Ubuntu-Gnome, it overwrote that boot data. So I also backed up the boot data for Ubuntu-Gnome, and then restored the boot data for the original Ubuntu install.
I wanted to be able to boot either using the installed Ubuntu booting menu. So I added an entry to boot Ubuntu-Gnome using that 40_custom file. I used pretty much the same code there as I had used in openSUSE, so it still used “linuxefi” and “initrdefi” and specified the generic kernel, which now had my signature.
This actually worked well in tests. Presumably the Ubuntu grub was checking signatures, and accepted the signature on the generic kernel that I had added with my Machine Owner Key. Using the Ubuntu boot menu, I could select the line to boot Ubuntu-Gnome, and it worked.
Then I turned off secure-boot. I turned it off for a completely unrelated test. And when I now tried to boot Ubuntu-Gnome, using the Ubuntu boot menu, it complained about an invalid signature and refused to boot.
So Ubuntu secure boot support is broken. What are the risks? Personally, I don’t think they are particularly worrying. If a hacker has sufficient access to your machine to use this problem to break in, then he probably has sufficient access to break in anyway. So if you are stuck with a Ubuntu system with this problem, I don’t think you have to be particularly concerned.
What could be a problem, is that Microsoft might decide not to sign the Ubuntu “shim” if they conclude that the Ubuntu folk are not being careful enough with secure-boot. That’s probably also only a small risk.