MOK-enrolled Secure Boot keys are not saved on the installed system when doing an OEM installation

[Aaron Rainbolt]

Steps to reproduce:

1: Enable Secure Boot.
2: Install the latest Ubuntu Kinetic ISO using the OEM installation option. Make sure to allow the installation of proprietary drivers and choose to configure Secure Boot.
3: Reboot and do the key enrollment with mokutil.
4: Reboot again, open a terminal, and run "ls /var/lib/shim-signed/mok". Then prepare the system for the end user (double-clicking the shortcut on the desktop).
5: Reboot again, then finish setup.
6: Run "ls /var/lib/shim-signed/moK" again.

Expected result: The files "MOK.priv" and "MOK.der" should be shown with each "ls" command.

Actual result: The listed directory is empty both times.

Notes:

This did NOT happen to me on a non-OEM installation. I noticed it attempting to manually sign a driver while grappling with bug 1991725. It probably will interfere with the use of DKMS modules even if they get installed and signed properly the first time.

For some reason "ubuntu-bug shim-signed" thought that shim-signed wasn't an official Ubuntu package, so I'm reporting this without using ubuntu-bug. I can provide any desired log files from the test system upon request.

[Aaron Rainbolt (arraybolt3)]

This bug does **not** occur if you install Ubuntu normally. It only appears to strike OEM installs.

[Steve Langasek (vorlon)]

Files being preserved or not in OEM mode is ubiquity, not shim; reassigning.

However, I'm not sure we WANT mok keys to be kept in OEM mode. Part of the intent of OEM mode is that the resulting disk image could then be copied between multiple systems. You would certainly not want all customer systems to have access to a single private key that can be used to sign kernel modules for all other customer systems. If anything, I think the bug here is probably that OEM lets you enroll a MOK key at all rather than blocking this (and saving an additional reboot).

[Aaron Rainbolt (arraybolt3)]

Makes sense, and as Erich pointed out, the MOK is the machine *owner* key, so having an OEM automatically enroll it is invasive and, as you point out, dangerous. However, at the same time, it looks to me like OEM installations aren't compatible with Secure Boot, so figuring out some way to fix that may be helpful. Perhaps it would be possible to make the generation and enrollment of the MOK key happen after the user turns the system on and sets it up for the first time?

[Steve Langasek (vorlon)]

Yes, there could be integration with OEM mode so that MOK generation and enrollment happens as part of the user first-boot experience. Canonical is unlikely to invest in the work to make this happen in oem-config/ubiquity as it's not a requirement from any of our commercial OEM partners, but community code contributions should be fine here.