Firstly, without discussing the merits, is it currently possible using UC20, secured grade, to set grub password such that it protects the grub config from being edited at boot time ?
Secondly, onto the merits
When using secured grade images, and protecting the Firmware/BIOS settings with a password, are there are real advantages to setting a grub pass ? It seems like the only thing that it would protect is running another signed executable [ which may we may or may not care about ]. Is there anything else, like can the kernel commandline be altered maliciously to gain access to the system at runtime ?
the grub config is hard coded in snapd and you can only override it from a file in the gadget snap … grub itself should be protected via secure boot by a TPM key after first boot …
Seems there was a slight misunderstanding on my part. I thought you could still add arbitrary options to the kernel commandline at boot time, like snapd.debug=1 etc, so you could potentially specify another kernel executable and boot another signed thing from a USB device for instance, and therefor use the hardware to run an unintended OS. But you’re saying that’s not possible ?
AFAIK this won’t work out of the box because setting up grub with a username password would require changing grub config in such a way that snapd wouldn’t be able to measure it (unless I’m missing something about how grub password is enabled) for full disk encryption. So there is indeed a potential “vulnerability” today in that someone could take your FDE system and put their own properly signed boot assets on a USB drive and boot them using the grub menu/cfg on ubuntu-seed, but note that even if they did this since we measure the boot assets into the TPM policy, they would still not be able to decrypt the encrypted partitions since the TPM measurements would not match.
