MOK management and remote administration

English Install/Boot/Login
#1

Up to now, I have only ended up in the MOK management interface after upgrading from one version of LEAP to another, but recently I was dropped into it after a kernel update. Like many people these days, I work a lot from home, as do my users, and we only travel into the office occasionally. We access our workstations (running openSUSE LEAP) using ssh and X2Go. This has made me wonder whether MOK management might interfere with remote administration of openSUSE.

I generally advise users to apply updates when prompted, rebooting if necessary. However, if MOK management is needed at boot time, this is only visible at the system console. Are there any strategies for dealing with this situation? The recent kernel update marked a key for deletion, so I guess that nothing will actually break if it isn’t deleted, but what happens if a new key needs enrolling? Or can I be certain that this won’t happen except when upgrading (which I would normally do from the console using a USB drive).

I would like to avoid the heavyweight possibilities that I have read about, for example:

  • installing KVM-over-IP kit
  • setting up IPMI (if our workstation hardware even supports it)
  • deploying ASUS Control Center (and not all of our workstation motherboards are ASUS anyway)

OTOH, if SLED offers anything that openSUSE doesn’t for this kind of situation, I would certainly consider paying for that. For a small outfit like us it wouldn’t be a huge financial outlay.

I have looked through the documentation without finding any answer to this. IIUC mokutil doesn’t allow a key to be auto-enrolled during boot, but maybe I’m wrong? (I’m not an expert in this area.)

I guess that the last resort is to disable secure boot, but that smells like admitting defeat to me. :wink:

#2

How recent it was and exactly was updated and to which versions?

but what happens if a new key needs enrolling?

MOK keys are needed for

  1. Verification of the kernel image (or in general any EFI binary) when loading it. This normally is not needed as long as shim is used as first level loader and both shim and kernel come from the same vendor. It is needed if you multiboot and shim comes from different vendor. In Leap 15.3 both shim and kernel come from SLE.
  2. Verification of the module signature. Again, if modules come from the same vendor as kernel and are signed by the same key most likely MOK certificate is not needed. In case of Leap 15.3 modules are signed by two keys - SUSE and openSUSE, so you actually need to enroll openSUSE certificate if you are using any of openSUSE modules (like VirtualBox). And if you are using third-party modules (nVidia?) you need to enroll additional keys.

Or can I be certain that this won’t happen except when upgrading

Not really. Keys could be revoked due to security issues, to make sure old binaries cannot be loaded. Keys expire (although existing keys have enough lifetime before Leap 15.3 goes out of support).

if SLED offers anything that openSUSE doesn’t for this kind of situation, I would certainly consider paying for that

The primary difference is that everything in SLED comes from the same vendor and is signed by the same key. Otherwise MOK management by design requires physical presence - simply because Secure Boot keys are not accessible when operating system is booted, so you must do management during boot phase.

#3

I’ve looked through /var/log/zypp/history and I think I have some insight into what happened now. (Thanks for the prompt to look at the logs ;)). I upgraded this machine from 15.2 to 15.3 on 2021-09-21 (late I know, but this was the last machine that I manage that was still on 15.2). Three days later, I installed this patch:

2021-09-24 09:52:30|patch  |openSUSE-SLE-15.3-2021-3205|1|noarch|repo-sle-update|important|security|needed|applied|

which installed kernel-default 5.3.18-59.24.1, then also removed an older kernel:

2021-09-24 10:59:04|command|root@pakpad|'/usr/bin/zypper' '-n' 'purge-kernels'|
2021-09-24 10:59:07|remove |kernel-default-optional|5.3.18-57.3|x86_64||
2021-09-24 10:59:08|remove |kernel-default-extra|5.3.18-57.3|x86_64||
2021-09-24 10:59:11|remove |kernel-default|5.3.18-57.3|x86_64|root@pakpad|

I guess that this older kernel was installed from 15.2, and this is where the revoked key came from. Sure enough, this machine has

multiversion.kernels = latest,latest-1,running

in /etc/zypp/zypp.conf

IIUC then:

  • letting this particular key hang around until someone reboots from the physical console and removes it is harmless
  • the way to avoid this specific problem is to comment out multiversion in /etc/zypp/zypp.conf before upgrading from one version of LEAP to the next, then re-enable it afterwards.

MOK keys are needed for

  1. Verification of the kernel image (or in general any EFI binary) when loading it. This normally is not needed as long as shim is used as first level loader and both shim and kernel come from the same vendor. It is needed if you multiboot and shim comes from different vendor. In Leap 15.3 both shim and kernel come from SLE.
  2. Verification of the module signature. Again, if modules come from the same vendor as kernel and are signed by the same key most likely MOK certificate is not needed. In case of Leap 15.3 modules are signed by two keys - SUSE and openSUSE, so you actually need to enroll openSUSE certificate if you are using any of openSUSE modules (like VirtualBox). And if you are using third-party modules (nVidia?) you need to enroll additional keys.

Thanks for the useful summary

Keys could be revoked due to security issues, to make sure old binaries cannot be loaded. Keys expire (although existing keys have enough lifetime before Leap 15.3 goes out of support).

The primary difference is that everything in SLED comes from the same vendor and is signed by the same key. Otherwise MOK management by design requires physical presence - simply because Secure Boot keys are not accessible when operating system is booted, so you must do management during boot phase.

This is what I had thought, but without being sure. I am reassured that I can carry on managing these machines in the way that I have been, and the risk of something breaking because of this is low. Some of them use the NVIDIA graphics drivers, but my standing advice has always been to only update those when physically present.

I suppose that one implication of this is that managing Tumbleweed without being able to interact with the boot process is risky.