search

SUSE / suse-migration-services

GNU General Public License v3.0
7 stars 11 forks source link

- In the not too distant future all our cloud partners will support s… #227

Closed rjschwei closed 3 years ago

rjschwei commented 3 years ago

…ecure boot

set the migration image up such it works in this environment.

schaefi commented 3 years ago

Some wise man recently said, when was the world ever that easy? :)

Unfortunately this change will not bring the benefit you are after. Remember the DMS system boots in two ways

  1. via kexec (no bootloader involved, no secure boot because no firmware to secure)
  2. via the grub loopback method

In the second form via the grub loopback method and on EFI systems a grub entry of the following form is created:

menuentry ... {
    search --no-floppy --fs-uuid --set=root MIGRATION_IMAGE_ROOT_UUID"
    set isofile=MIGRATION_IMAGE.iso
    set linux=linuxefi
    set initrd=initrdefi
    loopback loop ($root)$isofile
    $linux ... iso-scan/filename=$isofile ...
    $initrd ...
}

I have tested this setup in KVM with the ovmf MS signed firmware binary (/usr/share/qemu/ovmf-x86_64-ms.bin) and the image (ISO) built with the secure boot (shim signed) EFI binaries. A direct boot of the ISO file in secure boot mode works as expected but a loopback boot like in the example above did not work.

From my perspective grub does not support the signature checking when using loopback. I have to admit that I didn't dig deeper into this issue because I don't know enough about grub and how the signature via shim gets verified but there was also another reason why I think that secure boot is not so important in the scope of the DMS.

secure boot secures bootloaders, roms, kernels by verifying their signature against the trusted key(s) in the firmware. The DMS system embeds an immutable live system created from a trusted party, SUSE. It also creates a bootloader entry from code delivered from migration activation package which was also build and signed from a trusted party. I do not see a way to abuse the loopback entry in the grub config to do anything unexpected with the DMS live image. Thus from my perspective this was "secure enough" and the reason why I stick with the simple efi image approach

In general the loopback method opens an opportunity to boot a different system. This in itself is a security issue but can only be used with root permissions. In the cloud and with sudo rights everywhere the security to your own systems is basically controlled by the ssh key assigned to the instance. Which in the end moves the security aspects to accounts of the users in the cloud framework.

Long story short I had a reason to go with efi instead of uefi

We can make this change but it will not improve the situation imho. The live image build with uefi will continue to boot in non secure boot mode but I'm pretty sure it will not with secure boot enabled. Thus if we enable it now someone should also test/fix the secure boot mode for all the clouds the DMS is expected to work.

Thoughts ?

rjschwei commented 3 years ago

Right thanks for the reminder on the loopmount and secure boot topic. We've been down that road, but it was painful so I blocked it out.