[{bionic, focal, groovy}:linux 3/4] UBUNTU: [Config] add Canonical Livepatch Service key to SYSTEM_TRUSTED_KEYS

[Seth Forshee]

On Fri, Feb 19, 2021 at 07:54:05AM -0700, Tim Gardner wrote:
> 
> 
> On 2/19/21 7:38 AM, Seth Forshee wrote:
> > On Thu, Feb 18, 2021 at 12:12:46PM -0700, Tim Gardner wrote:
> > > The way that kernels are signed in the deep, dark recesses of the private
> > > kernel PPA has always been a bit of black magic to me. Given my ignorance,
> > > exposing keys like this in source code seems like a bad idea. Can you
> > > explain how they are being used ? Will they ever expire or change ?
> > 
> > Effectively both are module signing keys. The keys are not "exposed."
> > The public key will be baked into the kernel while the private key
> > remains secret. The ephemeral build-time module signing key also has the
> > public key statically built into the kernel keyring; only the private
> > key is discarded.
> > 
> > When these need to be rotated it's just a matter of putting the new keys
> > in the next upload, at least on the kernel side.
> > 
> > There probably is a small security cost to using these keys. At minimum
> > a compromise of one of the keys affects more kernels. But this is also
> > the case for the secure boot signing keys, so imo the impact is pretty
> > marginal.
> > 
> > Seth
> > 
> 
> I think I understand. I had not considered that the signing process is now
> using a static key pair instead of the kernel build time ephemeral key.

We do still use the build-time ephemeral key for the modules in the
linux-modules packages, that will not change. I'm assuming we currently
use a static key for livepatch, I don't actually know for sure. The
signing of the kernel images themselves does not use an ephemeral key
though.

> We
> could dispense with the ephemeral key altogether and achieve the same
> result. For instance, it might be useful for signing DKMS modules as well.
> Wouldn't that reduce some of the current build and packaging complexity for
> out of tree modules supported by Ubuntu ?

Remember that we'd have to build new dkms modules for each new kernel
version we upload, across all the kernels we support. We certainly
wouldn't want to do that for a bunch of individial dkms packages. We
could build them alongside the kernel like we do with zfs, but that
comes with its own pain points (which is at least part of the impetus
behind the module signing key). So another l-r-m style package would be
the least bad option for prebuilt dkms modules. It wouldn't reduce
packaging complexity as we'd likely build the modules from the dkms
packages like we do for l-r-m. The real benefit would be for users who
wouldn't have to build the modules locally and enrol a MOK.

Seth